Scala Programming Language
  1. Scala Programming Language
  2. SI-5736

Public API should auto-strip local suffixes from names

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Scala 2.10.0-M3
    • Fix Version/s: None
    • Component/s: Reflection
    • Labels:
      None

      Description

      In order to disambiguate getters and underlying fields we mangle the latter by appending LOCAL_SUFFIX_STRING (a single whitespace) to their names. That worked fine before we exposed it to the entire world by introducing macros and runtime reflection. Now it's utterly confusing.

        Issue Links

          Activity

          Hide
          Paul Phillips added a comment -

          You should elaborate on your description if you want people to know what you are talking about. (Or maybe it was intended as meta-commentary about this ticket.)

          Show
          Paul Phillips added a comment - You should elaborate on your description if you want people to know what you are talking about. (Or maybe it was intended as meta-commentary about this ticket.)
          Hide
          Eugene Burmako added a comment -

          On a reflection meeting we decided to do away with the suffix and for every val/var have the underlying field and the corresponding getter named identically. This warrants some changes to the typer, but according to Martin seems a good idea. I'll prototype this idea soon.

          Show
          Eugene Burmako added a comment - On a reflection meeting we decided to do away with the suffix and for every val/var have the underlying field and the corresponding getter named identically. This warrants some changes to the typer, but according to Martin seems a good idea. I'll prototype this idea soon.
          Hide
          Paul Phillips added a comment -

          So they will both be members, with the same name? If I "foo member bar" I get an overloaded symbol with both the field and the getter? I do not think that will end well; at the least it will require changing a ton of code to consider alternatives or add a suchThat in order to filter out the field.

          scala> res0.info.member("field": TermName)
          res5: $r.intp.global.Symbol = method field
          
          scala> res0.info.member("field ": TermName)
          res6: $r.intp.global.Symbol = variable field
          
          Show
          Paul Phillips added a comment - So they will both be members, with the same name? If I "foo member bar" I get an overloaded symbol with both the field and the getter? I do not think that will end well; at the least it will require changing a ton of code to consider alternatives or add a suchThat in order to filter out the field. scala> res0.info.member("field": TermName) res5: $r.intp.global.Symbol = method field scala> res0.info.member("field ": TermName) res6: $r.intp.global.Symbol = variable field
          Hide
          Eugene Burmako added a comment -

          Yeah, with the same name. Martin said this is doable, so I'm giving it a try. So far I've found only three places to deal with ambiguity: ClassfileParse, ICodeReader and Infer.makeAccessible (to help typer typecheck references to vals/vars inside a class; outside the class the private member is not visible, so we're fine). Quick still crashes during compilation, but I'm getting somewhere.

          Show
          Eugene Burmako added a comment - Yeah, with the same name. Martin said this is doable, so I'm giving it a try. So far I've found only three places to deal with ambiguity: ClassfileParse, ICodeReader and Infer.makeAccessible (to help typer typecheck references to vals/vars inside a class; outside the class the private member is not visible, so we're fine). Quick still crashes during compilation, but I'm getting somewhere.
          Hide
          Paul Phillips added a comment -

          If it works, great - that space has always given me chills.

          Show
          Paul Phillips added a comment - If it works, great - that space has always given me chills.
          Hide
          Eugene Burmako added a comment -

          Deemed to risky, demoted to 2.10.x or 2.11

          Show
          Eugene Burmako added a comment - Deemed to risky, demoted to 2.10.x or 2.11
          Hide
          Paul Phillips added a comment -

          For future reference: it is tempting to consider a different kind of Name rather than overloading the same TermName. That is, we could make TermNames abstract with subclasses MemberName and VarName or whatever. This makes sense to me because it is very rare that you want to deal with both kinds at once: either you are modeling the language level, in which case the "VarNames" should be invisible, or you are performing compiler-internal manipulations, in which case you can and should be explicit that you are working with the field.

          Show
          Paul Phillips added a comment - For future reference: it is tempting to consider a different kind of Name rather than overloading the same TermName. That is, we could make TermNames abstract with subclasses MemberName and VarName or whatever. This makes sense to me because it is very rare that you want to deal with both kinds at once: either you are modeling the language level, in which case the "VarNames" should be invisible, or you are performing compiler-internal manipulations, in which case you can and should be explicit that you are working with the field.
          Hide
          Paul Phillips added a comment -

          That makes me notice we could solve a lot of our name problems by giving different types of names more meaningful types. If a mangled name knew why it was mangled, it would be a lot easier to prevent its being further mangled in incompatible ways.

          Show
          Paul Phillips added a comment - That makes me notice we could solve a lot of our name problems by giving different types of names more meaningful types. If a mangled name knew why it was mangled, it would be a lot easier to prevent its being further mangled in incompatible ways.

            People

            • Assignee:
              Eugene Burmako
              Reporter:
              Eugene Burmako
            • Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:

                Development