Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Public API should auto-strip local suffixes from names #5736

Closed
scabug opened this issue May 3, 2012 · 10 comments
Closed

Public API should auto-strip local suffixes from names #5736

scabug opened this issue May 3, 2012 · 10 comments
Labels

Comments

@scabug
Copy link

@scabug scabug commented May 3, 2012

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.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented May 3, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5736?orig=1
Reporter: @xeno-by
Affected Versions: 2.10.0-M3

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented May 3, 2012

@paulp said:
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.)

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jul 25, 2012

@xeno-by said:
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.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jul 25, 2012

@paulp said:
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
@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jul 25, 2012

@xeno-by said:
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.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jul 25, 2012

@paulp said:
If it works, great - that space has always given me chills.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jul 26, 2012

@xeno-by said:
Deemed to risky, demoted to 2.10.x or 2.11

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jul 26, 2012

@paulp said:
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.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jul 26, 2012

@paulp said:
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.

@SethTisue

This comment has been minimized.

Copy link
Member

@SethTisue SethTisue commented Mar 2, 2018

seems unlikely to progress, scala.reflect doesn't change much anymore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.