Annotations for language features (was: Re: A Late Entry)
Ted Neward
ted at tedneward.com
Sat Aug 15 22:58:28 PDT 2009
I think I missed a few steps here.
> okay, but, lets say I have some old code that uses property as an
> identifier for a class. Yes, it breaks the camelcase rule, but its
> valid java. I'm going to be a little more evil, and I'm going to name
> this field 'String', again breaking the camelcase rule, but its still
> legal. That would look like:
>
> private final property String;
>
> Can we make the parser sort this out?
>
How about even if we can't, we just say that because you named a field after a class name (and a popular one at that), you're an idiot and your code breaks until you fix being an idiot? In this case, it consists of a single refactoring. Problem solved, for that idiot, anyway.
Seriously, I think we've been tiptoeing around the "Java language code will break" issue for far too long. The .class files are compatible (and even where they're not, they're tagged with a version number so at least we can know what version they target, *and* the JDK is reasonably easy to obtain and upgrade), so let's just bring Java into the 21st century and make them fully-fledged members of the keyword society.
Yes, I remember how the community howled when Java 1.4 "broke" JUnit. But the community howls no matter what you do, so screw 'em. Do what's right, not what's popular. Instead of playing games that create more edge cases than useful features, let's just rev the language, call it "Java 2.0", and go from there. The .class file format doesn't have to change for most of these, so I fail to see what the major issues are here.
My $.02 worth, anyway.
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
> -----Original Message-----
> From: coin-dev-bounces at openjdk.java.net [mailto:coin-dev-
> bounces at openjdk.java.net] On Behalf Of Reinier Zwitserloot
> Sent: Saturday, August 15, 2009 7:51 PM
> To: coin-dev at openjdk.java.net
> Subject: Annotations for language features (was: Re: A Late Entry)
>
> http://projectlombok.org/ is a prototype that lets you play around
> with what happens when you use annotations for language features.
>
> So far, the sky has not fallen down. On the contrary; they are
> namespaced and serve as document pointers, so they've been quite nice.
>
>
> Sure, it may not 'feel' right, but the sheer amount of backwards
> compatibility angst suggests to me that it's a shortcut worth thinking
> about - even when you are careful with the keyword string you pick and
> the keyword is made context sensitive, the impact is larger than an
> annotation. I'd certainly not presume that all, or even most, of the
> features discussed on coindev ought to be implemented with an
> annotation, but for a select few (including properties!) it makes
> sense to me.
>
> Consider for example making 'property' a context sensitive keyword.
>
> private final property String x;
>
> okay, but, lets say I have some old code that uses property as an
> identifier for a class. Yes, it breaks the camelcase rule, but its
> valid java. I'm going to be a little more evil, and I'm going to name
> this field 'String', again breaking the camelcase rule, but its still
> legal. That would look like:
>
> private final property String;
>
> Can we make the parser sort this out?
>
>
>
>
> --Reinier Zwitserloot
> Like it? Tip it!
> http://tipit.to
>
>
>
> On 2009/16/08, at 02:38, 向雅 wrote:
>
> > Hi,
> >
> > 2009/8/16 Ted Neward <ted at tedneward.com>:
> >> Oh, but come on, Neal, everybody's doing it.... *cough* JSR 308
> >> *cough*
> >>
> >> I'll be 100% honest: I'm really worried that 308 is going to open
> >> up a whole
> >> can of worms and people are going to do exactly that: create their
> >> own
> >> customized flavors of Java by using annotations to replace
> >> keywords. But
> >> that's for a different mailing list, I suppose.
> >
> > Agreed, but I not think it worth worried. Everyone have own flavors,
> > IMO tools author should not force others flavor. Of cause the code
> > with all flavors should work with each other, that just ok.
> >
> > back to the topic.
> > 1,Property annotation maybe no the best alternative. I agreed with
> > context-sensitive, through I'm fair even ten years after it still be
> a
> > future.
> > 2,The property proposal from based on field, I called it
> > B(ottom)2T(op) style. I talk a T2B style with Adam: property can be
> > focused on method and/or field, the field not must. some kind same as
> > JavaBean properties. most important, which is interface style.
> >
> >> Ted Neward
> >> Java, .NET, XML Services
> >> Consulting, Teaching, Speaking, Writing
> >> http://www.tedneward.com
> >>
> >>> -----Original Message-----
> >>> From: coin-dev-bounces at openjdk.java.net [mailto:coin-dev-
> >>> bounces at openjdk.java.net] On Behalf Of Neal Gafter
> >>> Sent: Sunday, August 09, 2009 11:22 AM
> >>> To: Greg Zoller
> >>> Cc: coin-dev at openjdk.java.net
> >>> Subject: Re: A Late Entry
> >>>
> >>> Annotations are not an appropriate "back door" for adding syntax
> >>> to the
> >>> Java
> >>> programming language. I suggest you instead consider context-
> >>> sensitive
> >>> keywords.
> >>>
> >>> On Sun, Aug 9, 2009 at 9:24 AM, Greg Zoller <gzoller at hotmail.com>
> >>> wrote:
> >>>
> >>>>
> >>>> Members of coin-dev... I'm writing to submit a late proposal for
> >>>> the
> >>> Java
> >>>> language, if not for initial Java 7 release (probably too late)
> but
> >>> perhaps
> >>>> for a later release. Below is the proposal form. Plain text
> >>>> editor
> >>>> formatting is pretty inconsistent, so apologies if it looks poorly
> >>> formatted
> >>>> when you see it.
> >>>>
> >>>>
> >>>> Project Coin
> >>>>
> >>>> Late Submission: Hiding Accessors at Compile Time
> >>>>
> >>>> AUTHOR: Greg Zoller
> >>>> gzoller(atsign)hotmail.com
> >>>>
> >>>> OVERVIEW:
> >>>>
> >>>> Feature Summary:
> >>>> De-clutter classes littered with accessors by having the
> >>>> compiler auto-generate trivial accessors for data members
> >>>> denoted with a @property annotation.
> >>>>
> >>>> Major Advantage:
> >>>> Would eliminate lots (and lots) of messy get/set code
> >>>> without losing the benefits of having an accessor for the
> >>>> times you really need them. The proposed approach should
> >>>> not break any existing code not written to take advantage
> >>>> of the new capability.
> >>>>
> >>>> Major Benefit:
> >>>> Less cluttered code! Removes (or more specifically hides
> >>>> behind the compiler) the clumsy construct of accessors
> >>>> without losing the purpose and benfits of their existence.
> >>>> In other words, I want property accessor capability--I
> >>>> just don't want to see them!
> >>>>
> >>>> Major Disadvantage:
> >>>> None that come to mind--I'm sure someone will contribute a
> >>>> disadvantage.
> >>>>
> >>>> Alternatives:
> >>>> Leave things the way they are.
> >>>>
> >>>> EXAMPLES:
> >>>>
> >>>> /* Today */
> >>>> public class Foo {
> >>>> private String name; // no accessors for name
> >>>> private int age;
> >>>> private double balance;
> >>>> private String comment;
> >>>>
> >>>> public int getAge() { return this.age; }
> >>>> public void setAge(int age) { this.age = age; }
> >>>> public double getBalance() { return this.balance; }
> >>>> public void setComment(String comment) {
> >>>> this.comment = comment; }
> >>>> }
> >>>>
> >>>> /* Proposed */
> >>>> public class Foo {
> >>>> private String name; // no accessors generated
> >>>> @property private int age; // both get/set generated
> >>>> @property(GET) private double balance; // getter
> generated,
> >>> no
> >>>> setter
> >>>> @property(SET) private String comment; // setter
> generated,
> >>> no
> >>>> getter
> >>>> }
> >>>>
> >>>> // Code would use these properties via their generated
> >>>> // accessors as they do now:
> >>>> foo.setAge(foo.getAge() + 10);
> >>>>
> >>>> // EVEN BETTER... the compiler can try to resolve data member
> >>>> // access according to a scope/visibility hierarchy:
> >>>> // public member, protected member, private member,
> >>>> // inserted getter/setter call
> >>>>
> >>>> // If this can be done in the compiler then old code can still
> >>>> // call the accessors like always while new code could simply
> >>>> // have:
> >>>>
> >>>> foo.age += 10;
> >>>> System.out.println("Age: "+foo.age);
> >>>>
> >>>> // This looks as clean as direct data member access but age
> >>>> // remains private with all the benefits of having accessor
> >>>> // protection. In the example above assuming no public,
> >>>> // protected, or private visibility for age exists the compiler
> >>>> // will insert a call to foo.getAge() for the programmer if age
> >>>> // is a @property field (otherwise its a compile error).
> >>>>
> >>>> // NOTE: The compiler won't auto-generate a getter or setter
> if
> >>>> // one already has been specified by the programmer, allowing
> >>>> // full control like we have now:
> >>>>
> >>>> public class Foo {
> >>>> @property private int age; // only a trivial getter
> >>>> generated--setter exists
> >>>> public void setAge(int age) {
> >>>> msg.notify("Someone's tampering with age!");
> >>>> this.age = age;
> >>>> }
> >>>> }
> >>>>
> >>>> // The compiler would exercise precedence logic in deciding
> >>>> // whether to insert a call to the accessors or not
> >>>>
> >>>> package A;
> >>>> public class Foo {
> >>>> @property private int age; // only setter generated--
> getter
> >>> exists
> >>>> public int getAge() {
> >>>> System.out.println("Getter called!");
> >>>> return this.age;
> >>>> }
> >>>> public void something() {
> >>>> int anotherAge = this.age;
> >>>> // private visibility is valid--no compiler-inserted
> >>>> // call to this.getAge() here
> >>>>
> >>>> int oneMoreAge = this.getAge();
> >>>> // explicit call to getter ok--just like today
> >>>> }
> >>>> }
> >>>>
> >>>> package B;
> >>>> public class Bar {
> >>>> public void blah(Foo foo) {
> >>>> System.out.println(foo.age);
> >>>> // Compiler can't resolve public, protected, or
> >>>> // private visibility to foo.age so a call to the
> >>>> // generated foo.getAge() accessor is inserted
> >>>> }
> >>>> }
> >>>>
> >>>> DETAILS
> >>>>
> >>>> Specification:
> >>>> Add the FIELD-targeted @property annotation to the
> >>>> language. Without parameters this will cause the
> >>>> generation of both a getter and setter unless one is
> >>>> already given by the programmer.
> >>>>
> >>>> Optional parameters GET or SET (@property(GET) or
> >>>> @property(SET)) would only attempt to generate the getter
> >>>> or setter respectively. I don't think Java grammar would
> >>>> be affected (?).
> >>>>
> >>>> Compilation:
> >>>> Out of my depth here. The auto-generation feature *should*
> >>>> be very straightforward as I would hope all the needed info
> >>>> to create the getters/setters is available at compile-time.
> >>>> I'm less clear on whether the compiler would be able to do
> >>>> the auto-resolution so you could just use foo.age and
> >>>> wouldn't be forced to call foo.getAge()/foo.setAge(), but
> >>>> I'm hopeful this is also possible, as it would be a great
> >>>> feature.
> >>>>
> >>>> This logic would have to support a hierarchy of resolution
> >>>> so that if 'age' was a public data member then public
> >>>> access would take precedence over trying to call the
> >>>> accessor method. Likewise protected and private access
> >>>> would take precedence over the getter if normal
> >>>> visibility rules allowed this mode of access.
> >>>>
> >>>> Testing:
> >>>> Hmm...
> >>>>
> >>>> Library Support:
> >>>> Shouldn't require any library support
> >>>>
> >>>> Reflective APIs:
> >>>> Existing APIs should be fine. The generated
> >>>> getters/setters would be reflectively accessible since once
> >>>> they are generated by the compiler they are no different
> >>>> than if the programmer had written them.
> >>>>
> >>>> Other Changes:
> >>>> None come to mine.
> >>>>
> >>>> Migration:
> >>>> No conversion necessary. Normal getter/setter code in
> >>>> common use today would still work and could live seamlessly
> >>>> in parallel with code using the new features.
> >>>>
> >>>> COMPATIBILITY:
> >>>>
> >>>> Breaking Changes:
> >>>> No code should break due to the changes proposed
> >>>>
> >>>> Existing Programs:
> >>>> Existing code should live seamlessly in parallel to these
> >>>> changes. If the compiler access precidence feature is
> >>>> implemented then newly written code can take advantage of
> >>>> this ability when calling existing unmodified code. For
> >>>> example:
> >>>>
> >>>> // Existing code
> >>>> public class Foo {
> >>>> private int age;
> >>>> public int getAge() { return this.age; }
> >>>> public void setAge(int age) { this.age = age; }
> >>>> }
> >>>>
> >>>> // New code
> >>>> foo.age = 10;
> >>>>
> >>>> // compiler would first see if a public/protected/private
> >>>> // visible age data member existed, and since there is none
> >>>> // a call to getAge() would be inserted during compile time
> >>>> // thus using the new feature to seamlessly interact with
> >>>> // legacy code without altering semantics
> >>>>
> >>>> REFERENCES:
> >>>> N/A
> >>>>
> >>>>
> >>>> _________________________________________________________________
> >>>> Get free photo software from Windows Live
> >>>>
> >>>>
> >>>
> http://www.windowslive.com/online/photos?ocid=PID23393::T:WLMTAGL:ON:WL
> >>> :en-US:SI_PH_software:082009
> >>>>
> >>>>
> >>
> >>
> >>
> >
> >
> >
> > --
> > 致敬
> > 向雅
> >
>
More information about the coin-dev
mailing list