A Late Entry
向雅
fyaoxy at gmail.com
Sat Aug 15 17:38:01 PDT 2009
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