foo.bar and foo.bar() mean the same thing, Jess. Find member and do the obvious thing with it. There is absolutely no overlap in spirit or implementation between properties and dynamic resolution, other than the feeling that you're getting something. Also, pointing at something that's already in the JVM can not be used as an excuse to make a new mistake.
Not that I consider .bar and .bar() a mistake (though I do consider it a mistake that you can have both a field and a method of the same name. Not worth it.) - but that's because they do mostly the same thing. They may smack a little bit of "OuterClass.this.field" because they look similar, but that's where the similarities end for me. First off, OuterClass.this.field isn't actually avoidably ugly - co-opting your lexical scope is just difficult. Its either annoying or impossible in every language. Secondly, there's no OuterClass.this involved in getting your hands on the raw field, unless you already needed to do this anyway (regardless of using ->foo / .foo vs .foo / .foo.field syntax). And that's where the similarities end, no? The biggest difference now would be that you can no longer tell, from "foo.bar", if this is a cheap field access, or a relatively expensive virtual lookup into a method of an anonymous inner subclass. However, I think the days where the programmer is supposed to care about this kind of optimization is loooong gone, and is in fact actively stupid, because the JIT compiler works in very mysterious ways to your average java programmer - any attempt to hint at the programmer that something is 'more efficient' by a few CPU cycles with syntax is IMO a serious mistake. On Feb 9, 3:51 am, Jess Holle <[email protected]> wrote: > Reinier Zwitserloot wrote: > > having foo->bar mean something -entirely- different from foo->bar() > > would be extremely bad. > > foo.bar means something entirely different than foo.bar(), unless you > consider fields and methods to be the same thing. > > That said using "->" for both properties and dynamic methods might not > be a good idea. > > > If -> syntax is used for properties, we must accept that -> is 'taken' > > and can not be coopted for something else (unless that something is so > > close in spirit to properties that it would be allright). So, the > > question becomes, for anyone that proposes adding -> for property > > reference: Is there another acceptable syntax for dynamic member > > resolution, and if not, is this proposal so much cooler than dynamic > > member resolution, that its acceptable that they are mutually > > exclusive? > > > A -great- example of why tossing new syntax at a language 'because > > there are no downsides' is faulty thinking. There's always a downside. > > > Properties win, by the way, from dynamic member resolution. hands > > down. But perhaps -> isn't the right syntax. I'd be just as happy with > > just using the ., but forcing explicit declaration of 'property > > nature' on the part of the field declaration. writing to/reading from > > "this.foo" would always run the getter and setter, no exceptions. If > > you want to skip them and read the raw field, the property, which is > > really an anonymous inner subclass of the "Property" class, has a > > (package?) private field, so, you'd go: "this.foo.field" to read it. > > This would only work from the same class (or perhaps from others, if > > package private makes more sense). Just throwing it out htere. > > Yes, I'd thought of such approaches. They remind me of the ugliest bits > introduced with Java 1.1 (e.g. OuterClass.this.field). > > -- > Jess Holle --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
