tag:blogger.com,1999:blog-741750605858169835.post2259022082320829019..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Beans and propertiesStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-741750605858169835.post-17961343062833294302014-04-27T10:17:46.184+01:002014-04-27T10:17:46.184+01:00Hello, it is very interesting article. Maybe will ...Hello, it is very interesting article. Maybe will attract you a solution with a similar approach, where they are used static Keys on the place of the Property class. The basic features are described on the article: <br />http://ujorm.org/sample/key-value.htmlPonechttps://www.blogger.com/profile/08356229927918860793noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-76033186227173346502014-04-09T06:12:26.855+01:002014-04-09T06:12:26.855+01:00I know this is a very late follow-up, but Lombok s...I know this is a very late follow-up, but Lombok seems to be fairly mature at this point and in my experience "just works," at least from my Maven builds. The IDE plugin is pretty transparent. When I can't use Groovy, it's a great tool to have around.<br /><br />They don't seem to generate the Property calls you have in your example, but otherwise the @Data annotation covers my (server-side-only) needs. (When I can't use @Value.) Adding an @Bean annotation to fill in the gap should be feasible.Anonymoushttps://www.blogger.com/profile/08220880215329923555noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-4976709066200201142012-04-13T13:17:42.494+01:002012-04-13T13:17:42.494+01:00I can't say I've ever used xjc. Happy to h...I can't say I've ever used xjc. Happy to have github forks and pull requests though...Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-28168171971714036462012-04-12T18:00:17.476+01:002012-04-12T18:00:17.476+01:00Hi Stephen, interesting project. Have you conside...Hi Stephen, interesting project. Have you considered integrating with other bean generation tools like xjc? This would make a very interesting extension.Damian ONeillhttps://www.blogger.com/profile/18232408163481534251noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-46850725657900622122011-06-27T07:39:06.000+01:002011-06-27T07:39:06.000+01:00@Carsten, Thanks for the detailed feedback. The Ty...@Carsten, Thanks for the detailed feedback. The TypedKey concept is interesting and I will take a further look. However, at first glance it looks similar to the Joda-Beans meta-bean property object (points 1 and 3). For the Person.surname() property, you can also get access to Person.meta().surname(), which is a MetaProperty. That can be used to access data directly without going back to a map, ie. metaProperty.get(bean), rather than bean.get(metaProperty) as with TypedKeyMap.<br /><br />A string key is useful to allow interaction with other framework/reflective systems that use a string as a key.<br /><br />The use of inner classes to access the data is possible, however it bloats the binary file size. It would remove the need for the string switch however and could be a generation option. That said, the right way for this code to go is to update it to Java 7 and method handles. With method handles, there will be no need for the string switch or the inner class. (I'd welcome a patch to add method handle support as an optional code generation)<br /><br />I am aware of Project Lombok, and perhaps this can be used by them at some point. Technically, they simply generate the simple getters and setters dynamically in the IDE.<br /><br />Finally, the DirectBean hash code and equals is now generated by code generation, so the superclass implementation isn't relevant any more. I think it was done that way originally to match the algorithm of a Set.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-89855280015896285152011-06-18T18:29:30.000+01:002011-06-18T18:29:30.000+01:00A kind of "Generic Beans" is something I...A kind of "Generic Beans" is something I'm interested in for some time now. <br />The JPA-Typesafe stuff is ugly how they did it but has one special feature which caught my attention. We use what i call a TypedKey approach to get some kind of type safety when storing mixed data in a Map (mostly for "tunneling" data through some generic code).<br /><br />public class TypedKey {...}<br />static final TypedKey KEY_MY_INT1 = TypedKey.of("myint1");<br /><br />TypedKeyMap tkm = ...<br />...<br />tkm.put(KEY_MY_INT1, 1234);<br />...<br />Integer myint1 = tkm.get(KEY_MY_INT1);<br /><br />The point here is that the KEY carries the data type of the value as JPA does it.<br />I took a look at the Person example.<br />1. I wonder why you don't make use of typed keys? You "objectified" the value as a Property, why not take this a step further and use the generated meta constants as objectified keys?<br /><br />2. Avoiding 2 switches<br />The generated meta code has direct access to the properties. So some kind of<br /><br />new Accessor() {<br /> String get() {<br /> return surname;<br /> }<br /> void set(String v) {<br /> surname = v;<br /> }<br />} <br /><br />as part of the Metadata-Generation would provide direct access to the field without reflection.<br />Using the meta data constants instead of Strings-Names would reduce the switches in propertyGet and propertySet to a delegate to the key.<br />3. Make typed keys public<br />I would also think about making the meta constants public for direct reference in other code. This way they could be used as keys to the property map providing some value type safety to avoid the " T get()" approach.<br /><br />Opinions?<br /><br />P.S.1<br />Are you aware of lombok? (http://projectlombok.org/index.html) <br />I didn't had the time to take a detailed look HOW they did it but sounds interesting generating getter/setter stuff on the fly using annotations.<br /><br /><br />P.S.2<br />Short note at DirectBean: I wonder why you just add the hashcodes instead of the "classical" 31 * oldHash + newHash leading to better distribution IMHO.Carsten Heylnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-42870661311585875392011-06-05T23:24:12.000+01:002011-06-05T23:24:12.000+01:00Yeah, the "name : Type" convention takes...Yeah, the "name : Type" convention takes a bit to get used to. There are advantages to it, though. For example, generic functions can be declared and invoked much more naturally, since the return type appears after the method name, rather than before. <br /><br />It took me a while, but I switch between gosu and java quite a bit and don't notice it anymore. FWIW, it seems like most new statically typed languages are going with this convention.Carson Grosshttp://calbear.orgnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-25983264153081861592011-06-05T22:20:54.000+01:002011-06-05T22:20:54.000+01:00@Richard, I do think that method handles and lambd...@Richard, I do think that method handles and lambdas will offer new options, I just find it frustrating trying to add a core feature outside the language.<br /><br />@Carson, thanks for writing about Gosu. The feature literal element looks good, and fits my view of how such things should work with # for the meta level. Unfortunately, Gosu declares variables as name : type, which makes it rather unappealing to me. Fix that, and I might take a real look at the language...Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-34300442097471856672011-06-05T20:53:30.000+01:002011-06-05T20:53:30.000+01:00OK, threw together a blog post here: http://guidew...OK, threw together a blog post here: http://guidewiredevelopment.wordpress.com/2011/06/05/feature-literals-enhancements-blocks-win/Carson Grosshttp://calbear.orgnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-30309986126282609882011-06-05T16:25:25.000+01:002011-06-05T16:25:25.000+01:00@CoolSteph:
Gosu has a short hand syntax for expo...@CoolSteph:<br /><br />Gosu has a short hand syntax for exposing a field as a property:<br /><br /> var _field1 as Field1<br /> var _field2 as readonly Field2<br /><br />@Stephen Colebourne:<br /><br />Totally agree that properties are a must have for a programming language, particularly for UI data-binding. Feature literals answer the reference vs. evaluation problem: you use the dot syntax to evaluate and the sharp syntax to reference. With respect to a first class listener implementation for feature literals, that is not supported because feature literals apply to any type and, therefore, every type would have to provide the needed listener infrastructure.<br /><br />*However* using enhancements and the implicit parameterization of feature literals, you could implement a listener infrastructure yourself, for your own classes.<br /><br />I'll put a post up on how to do that over at the guidewire dev blog later today.Carson Grosshttp://www.calbear.org/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-31057858150762614972011-06-01T23:17:09.000+01:002011-06-01T23:17:09.000+01:00Actually, our implementation is currently using st...Actually, our implementation is currently using stateful properties, but it doesn't have to. Our property objects are getting "bean" and "name" properties, which means we could go to a GC-heavy stateless approach in the future, primarily when reflection is no longer needed (and we can use lambdas to do the job).Richard Bairhttp://fxexperience.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-61381654371563298862011-05-31T18:46:39.000+01:002011-05-31T18:46:39.000+01:00Followup - I just read @Stephen's comment on G...Followup - I just read @Stephen's comment on Gosu. It looks like its feature literals are basically the same thing as member expressions. It's good to see others appreciate the value of such a thing.Jonathannoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-63537663335800863232011-05-31T18:37:24.000+01:002011-05-31T18:37:24.000+01:00I agree that Java needs properties, badly. Additio...I agree that Java needs properties, badly. Additionally, it needs member expressions (ala C#), so that APIs that perform configuration based on properties don't need to use string references to property names but instead can use actual references to the members themselves. This would be huge.Jonathannoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-45699282150526954892011-05-30T20:23:06.000+01:002011-05-30T20:23:06.000+01:00@James, I agree that code generation can make the ...@James, I agree that code generation can make the hashCode approach more robust. If that was a big deal stopping use of JodaBeans, then I'd accept a github pull request to fix it!<br /><br />@CoolSteph, There are many ways to add properties to the language, and annotations are one. But its probably not the one I'd use.<br /><br />@Stephen, bindgen looks interesting, thanks for the link. I understand the nested properties point. As a language change goal it seems reasonable, but your approach may be the only possible way in libraries (and its not something I can ever remember needing).Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-10227992664464099452011-05-30T17:04:36.000+01:002011-05-30T17:04:36.000+01:00I agree; properties are really important. Property...I agree; properties are really important. Property objects are great, but unfortunately limit use/navigation to just 1-level, e.g.:<br /><br /> bind(someUi, myEmployee.name);<br /><br />And don't allow:<br /><br /> bind(someUi, myEmployee.employer.name);<br /><br />I think for the property problem to be "solved", especially if rolled in as a first-class language feature, I think the 2nd line needs to be supported just as much as the 1st.<br /><br />There are two ways I know of to do something like this, one is my bindgen (http://www.bindgen.org) project (which is an ugly but unfortunately necessary/functional hack for accomplishing its goals):<br /><br /> bind(someUi, new EmployeeBinding(myEmployee).employer().name());<br /><br />Or Gosu's feature literals:<br /><br /> bind(someUi, myEmployee#employer#name);<br /><br />http://guidewiredevelopment.wordpress.com/2011/03/03/feature-literals/<br /><br />Gosu, IMO, did their approach exactly right (for example, they support both stateful and stateless literals). Anyone looking to support properties as a first-class language concern (whether in Java or elsewhere), should heavily crib off Gosu's approach as I think how client code can access/bind the properties is just as important as the implementation code for the properties themselves.<br /><br />Note that technically Gosu's feature literals give you basic (listener-less) data binding without any property objects, so should be pretty light weight (you can think of it as just syntax sugar for caller-side inner classes). I'm not sure how their caller-side approach would integrate with callee-side stateful properties that supported listeners; it would be something to think about it.Stephennoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-66682702860917841522011-05-30T14:32:43.000+01:002011-05-30T14:32:43.000+01:00Hello,
Not being an expert in terms of languages ...Hello,<br /><br />Not being an expert in terms of languages an compilers, could someone explain why the following would be a bad idea: the use of annotations:<br /><br />@ReadOnly<br />String nino;<br /><br />The compiler would generate the getter only<br /><br />@ReadWrite<br />etc<br /><br />Or it could be<br /><br />@Property(Prop.ReadOnly)<br /><br />If the code already has the getter and setter it does nothing, or could raise an error if one declares the property as read only and a setter is found...<br /><br />etcCool Stephnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-14168035272168508202011-05-29T22:56:22.000+01:002011-05-29T22:56:22.000+01:00Since Dirk raised the initial concern, I mostly wa...Since Dirk raised the initial concern, I mostly wanted to point out that there were two cases, and point out that the more directly harmful case could be fixed at the time of code-generation.<br /><br />So if you include an equality check on the string iff the bean includes two property strings with the same hash code, you'll reduce the problem profile to isolated erroneous responses to non-existent property strings. You would pay a cost in the readability of the generated code only if there would otherwise be a problem.<br /><br />Looking at your code, since propertyGet is a protected method mostly called by equals, hashCode, and toString, this change might handle all of your expected behavior (though perhaps a brief warning in the protected method's javadoc would be merited).<br /><br />Anyway, the tradeoffs are naturally yours to make.<br /><br />On a separate note, I agree that Properties are a major item missing from the Java language spec, though I disagree that they're a bigger deal than generics (on closures, I must reserve judgement).jamesGnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-80999817938842510802011-05-29T16:34:03.000+01:002011-05-29T16:34:03.000+01:00@Osvaldo, the original Joda project had stateful p...@Osvaldo, the original Joda project had stateful properties not suited to serialization. However, the new Joda-Beans project only has lightweight properties which are semi-stateless. Thus there is no great need to serialize the Joda-Bean property (all the data is on the bean itself, so that serializes as per any other bean). That said, it would be perfectly possible to serialize the Joda-Bean property, as it would simply be a pointer to the "surname" on the "Person" of type "String".<br /><br />I should note that the new Joda-Beans project has no support for listeners ATM, as I have no need for that. If it were to be added, I might encourage it to hold its state completely separate from the bean, such as in a centralised manager.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-32744037386970301552011-05-29T16:24:47.000+01:002011-05-29T16:24:47.000+01:00What is your take on serialization? JavaFX's p...What is your take on serialization? JavaFX's properties are not Serializable, and I guess this is purposeful because bindings and event listeners hooked into GUI components would often mean that an attempt to serialize your Person bean carries together the entire application model and UI tree into the stream... Joda-Beans looks similar too. We can argue that serialization (as done by Java) is an evil and failed idea, but at least EJB session beans and most web frameworks (for session data) are still very relevant and heavily dependent on serialization.Osvaldo Pinali Doederleinhttp://weblogs.java.net/blogs/opinali/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-50827219885746733602011-05-29T15:44:31.000+01:002011-05-29T15:44:31.000+01:00@Dirk/James, yes I'm aware of the hashCode swi...@Dirk/James, yes I'm aware of the hashCode switch limitation. It hasn't caused a problem in about 8 years of using the approach, so its definitely a low probability issue, but strictly speaking it is a potential bug. With JDK 7, it can be changed to a string switch which works "correctly", but at lower performance.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-62827251947040644052011-05-29T15:21:43.000+01:002011-05-29T15:21:43.000+01:00The dependence on hashCode can cause problems, as ...The dependence on hashCode can cause problems, as Dirk suggested.<br /><br />1) Two property names may have the same hashCode. Perhaps this is a special case in your code generation, however; if you have two properties that possess the same hashCode, add an equality check as well.<br />2) Non-existent properties (on this particular object) may respond with values.<br /><br />Problem #1 is potentially fatal, but ameliorated with a backing equality check.<br /><br />Problem #2 is *probably* more of a curiosity than anything else, though good luck to anyone debugging who encounters it.<br /><br />I imagine these problems have already been considered, and would like to hear the reasoning.jamesGnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-7433364909340296272011-05-29T13:39:19.000+01:002011-05-29T13:39:19.000+01:00Steve,
JavaFX 2.0 properties are created lazily on...Steve,<br />JavaFX 2.0 properties are created lazily on demand.<br /><br />And I think your hashCode approach in version 3 is broken, because two property names may have the same hashCode.<br /><br />Dirk.Dirk Möbiusnoreply@blogger.com