tag:blogger.com,1999:blog-741750605858169835.post8373435539496671052..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: More detail on Property Literals / Property ObjectsStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-741750605858169835.post-28757325485561058922007-01-12T22:29:32.000+00:002007-01-12T22:29:32.000+00:00I don't have a whole lot to add to the worldwi...I don't have a whole lot to add to the worldwide property discussion; I am interested in the concept of Property, and more importantly, MetaProperty objects as an obvious complement to the existing reflection packages. However I can't see any reason to force developers to manually code Property objects when syntax sugar would do. Leave the internal implementations as close to "current" as possible and let the (augmented) compiler generate as much as possible. Not breaking new ground, but ATM my ideal syntax is:<br /><br />private String property(:(read|write)only)? foo;<br /><br />This keeps the existing means of scoping access to "foo". It is fairly pleasant semantically. I have seen some examples like:<br /><br />public property private String foo;<br /><br />But I think we can make a blanket statement that a property's getters and setters, if applicable, are public, especially during any POC phase. Otherwise Property wouldn't have access to delegate to the appropriate methods without VM support or tricky reflection (changing accessibility of methods at runtime). The net effect of this decision is that a single access modifier, that of the actual member variable, is the only one necessary. I suppose there is no reason the type and property need appear in that order in case it is visually more pleasing to some the other way:<br /><br />private property(:(read|write)only)? String foo;<br /><br />Finally, while it might be something to be discouraged, it might be acceptable to make static properties available as well. Probably the Property object for a static property would simply ignore the bean parameter on its setter and getter. This would be consistent with the reflection API IMO.<br /><br /> To keep the class defs clean, one might define things such that there was not direct API access to the Property instance. i.e. bean->someProperty would evaluate to bean.getClass().getMetaProperty("someProperty").get(bean) or the like.<br /><br />As for Jesse's "extensible properties" idea, I can see what you're after here, but this seems to amount to Property decorators. So perhaps any language support of properties might just be designed in such a way that setting up decorators via injection or AOP would be trivial. Obviously this would require more thought.<br /><br />$0.02,<br />MattMatt Bensonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-39313086249881120932007-01-12T17:22:48.000+00:002007-01-12T17:22:48.000+00:00You're right, Meta-property vs. Property is a ...You're right, Meta-property vs. Property is a good distinction. <br /><br />In most cases I think I prefer MetaProperty. But for areas like ORM, Properties could have additional fields to store instance-specific metadata on a field such as 'isDirty' or 'originalValue'.Jesse Wilsonhttp://publicobject.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-37648384889396123142007-01-12T10:09:47.000+00:002007-01-12T10:09:47.000+00:00@Jesse, This is a third option for compilation, ho...@Jesse, This is a third option for compilation, however its actually very close to the first option I described - use reflection. BTW, in the naming scheming I'm using, you are creating a meta-property, not a property. Thus your classes are ObservableMetaProperty and so on. In my naming, the real property holds both the meta-property and the bean it is active for. See javadoc at http://joda-beans.sf.netStephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-92194530645389301552007-01-12T04:18:20.000+00:002007-01-12T04:18:20.000+00:00... and the value of the property objects being st...... and the value of the property objects being static is that they don't consume additional memory* per instance.Jesse Wilsonhttp://publicobject.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-10650080804233133122007-01-12T04:15:04.000+00:002007-01-12T04:15:04.000+00:00The property object does not need a reference to t...The property object does not need a reference to <i>this</i>, which means it can be static. For example, this:<br />class Foo {<br /> @Property String bar;<br />}<br />...could be 'compiled' into:<br />class Foo {<br /> public static Property $Property_bar = new java.lang.Property {<br /> public void set(Foo base, String value) { base.bar = value; }<br /> public String get(Foo base) { return base.bar; }<br /> }<br /> String bar;<br />}<br /><br />Which would work just fine for bindings. <br /><br />It would also be fabulous if at developers could provide different implementations for $Property_Bar:<br /> @Property{NotNullProperty.class} String bar;<br /> @Property{ObservableProperty.class} String baz;<br />... or my personal favourite, where you can chain properties to do things like this:<br /> String @Property{ObservableProperty.class, NotNullProperty.class} baz;<br /><br />I describe a potential API for 'extensible properties' here:<br />http://publicobject.com/2007/01/extensible-properties-for-java-language.htmlJesse Wilsonhttp://publicobject.com/noreply@blogger.com