tag:blogger.com,1999:blog-741750605858169835.post3824502223691783832..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Java 7 - Property objectsStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-741750605858169835.post-81894019879232625382007-01-16T18:37:11.000+00:002007-01-16T18:37:11.000+00:00@Stephen, first, you're welcome. Secondly, I&#...@Stephen, first, you're welcome. Secondly, I'll go read the other thread now :)Doron Baraknoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-20942978644764640622007-01-16T18:27:27.000+00:002007-01-16T18:27:27.000+00:00@Doron, My latest post - http://jroller.com/page/s...@Doron, My latest post - http://jroller.com/page/scolebourne?entry=property_access_is_it_an - covers expression languages as one way to meet your requirements (which I've just understood on re-reading!). I think I agree that property access via get/set alone isn't enough of a change to be justified. List/Map access is also needed. Thanks for the good example ;-)Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-20334643045201179092007-01-16T16:30:17.000+00:002007-01-16T16:30:17.000+00:00@Stephen, I was trying to describe Properties as t...@Stephen, I was trying to describe Properties as they should be (imo) implemented in Java and Delphi (imo) does it very well. Java supports Properties by way of Get/Set methods and so does Delphi, there is no reason why Java syntax should no evolve to include good patterns from other languages/technologies.<br /><br />About accessing the Property Metadata information or the Property Object itself, you're absolutely right, I didn't focus on those things because I didn't have anything to add to what was already said.Doron Baraknoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-56992868559425107992007-01-10T16:31:40.000+00:002007-01-10T16:31:40.000+00:00@Doron, your definition of properties might be app...@Doron, your definition of properties might be appropriate for Delphi, but it doesn't fit Java. Like it or not, Java does this using get and set methods, and so those will have to be supported.<br /><br />In addition, this blog/proposal is about accessing the property _object_ and meta property information, neither of which are addressed in your example.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-16876920430135805732007-01-10T14:02:39.000+00:002007-01-10T14:02:39.000+00:00Having worked with Properties in Delphi, all I can...Having worked with Properties in Delphi, all I can say is that if the following syntax doesn't exist, then the whole thing is just sugar-coating:<br /><br />public class Person {<br /> // pseudo code to define the property..<br /> property String FirstName;<br /> property String LastName;<br /> property Person[] FamilyMembers;<br />}<br /><br />public class Tester {<br /> Person p0 = new Person();<br /> p0.FirstName = "Penny"; <br /> p0.LastName = "Blonde";<br /> Person p1 = new Person();<br /> p1.FirstName = "James"; <br /> p1.LastName = "Bond";<br /> p1.FamilyMembers[0] = p0;<br /> p0.FamilyMembers[0] = p1;<br />}<br /><br />The idea is that the language should enable indexed-properties and access-syntax that does not have to directly rely on the set/get methods.<br /><br />Clearly indexed-properties present a problem if you do not have to define the size of the array and expect it to grow, but I'm sure code-generation under the hood can solve this issue as well.<br /><br />To sum up my point, if your properties are still accessed with get/set methods and not throw the property name alone, this isn't really any different than what we already have.Doron Baraknoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-5459301753646220852007-01-09T14:46:10.000+00:002007-01-09T14:46:10.000+00:00@Evan, Yes, a JTable does consist of a MetaPropert...@Evan, Yes, a JTable does consist of a MetaProperty per column and a Bean per row. The advantage of using Property when doing the evaluation of each cell is that the code is already written and encapsulated, and might not even point to a 'normal' JavaBean (direct database wrappers anyone?)<br /><br />You ask if an application would call property.get() or property.set(value) directly. The answer is probably not in the main body of the code, but you could easily write a method:<br /><br />public boolean validateMandatory(Property[String] property) {<br /> String str = property.get();<br /> return (str != null && str.length() > 0);<br />}Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-77919032721539313172007-01-09T10:43:06.000+00:002007-01-09T10:43:06.000+00:00Stephen, looks great. i posted this at javalobby -...Stephen, looks great. i posted this at javalobby - excuse me pasting it in here. <br /><br />Hiya Stephen,<br /><br />i like the "property objects" approach for "beans binding" and have presented this approach in a coupla articles (listed on "Gooey Beans"). i see my QProperty object is like your MetaProperty object. i haven't had a need for a Bean/Property object which binds a meta property/bean to a specific bean instance, although it does seem complete to do this, eg. your Bean, and maybe a BeanCollection, eg. for a JTable.<br /><br />In the case of the JTable for example, one would have a List of beans, and a single BeanInfo class with a Map of (Meta)Property objects. The TableModel invokes property.set(bean, value) and property.get(bean), where it references a Property object per column, and the bean for a given row in the table.<br /><br />What is your use case for exposing bound Property objects to the application, and invoking property.set(value) and get(), in the application code, rather than invoking setter on the bean?<br /><br />thanks<br />evanevan summershttp://aptframework.dev.java.netnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-21693713564816814072007-01-09T03:52:21.000+00:002007-01-09T03:52:21.000+00:00Here are some advantages to Property objects:
- I...Here are some advantages to Property objects:<br /><br />- If Property has listener support methods, you can turn run-time errors into compile-time errors<br />- Multiple Property implementations mean the large number of different property implementation options doesn't pose a problem. See this blog for the problem being addressed:<br />http://weblogs.java.net/blog/forax/archive/2007/01/property_and_be.html<br />- Easy typesafe compile-time access to property metadata. Granted this is of much more interest to frameworks than "ordinary" code, but ordinary application developers sometimes have to do these things and/or spend time debugging frameworks.Curt Coxnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-55810294359885888462007-01-09T01:49:53.000+00:002007-01-09T01:49:53.000+00:00The new sourceforge website for property objects i...The new sourceforge website for property objects is now up and running - http://joda-beans.sourceforge.netStephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-563965961198207192007-01-08T23:31:06.000+00:002007-01-08T23:31:06.000+00:00The principal reason for Property is that its just...The principal reason for Property is that its just good OO design. You encapsulate the knowledge of the bean and property together in one object. We do it, because otherwise every other framework has to write a Property class that does the same task.<br /><br />A second reason is that it provides much better type safety and exception wrapping over calling invoke() on Method.<br /><br />Finally, there is no reason why the Property, MetaProperty, Bean and MetaBean interfaces have to be implemented by a normal JavaBean at all. They could be implemented using a HashMap to store the properties, or to front end a JDBC result set. This isn't a completely new area - Commons BeanUtis DynaBeans cover similar ground.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-75097557764665980902007-01-08T22:21:35.000+00:002007-01-08T22:21:35.000+00:00Stephen,
Could you go into a little more detail a...Stephen,<br /><br />Could you go into a little more detail as to why you'd want the Property interface? Wouldn't PropertyDescriptor be enough? Who needs Property? Just frameworks?<br /><br />There's no doubting that foo->bar.get() would be better than foo->bar.getWriteMethod().invoke(foo). :-). I don't doubt it's better (even subjectively), but whether it is really necessary. I guess I've not yet bumped into it, so it isn't really essential to me, whereas you've no doubt bumped into it so it is necessary :-)<br /><br />I don't see the connection between the Property interface, and static connections to properties (such as binder.bind(foo->bar). Given a PropertyDescriptor, binding.bind() could do it's work).Richard Bairnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-7861415246183597752007-01-08T21:47:46.000+00:002007-01-08T21:47:46.000+00:00I've applied for a new sf project to host the ...I've applied for a new sf project to host the updated Joda-Beans code so everyone can get a really good look, with proper documentation.<br /><br />@Richard, as Curt said, PropertyDescriptor maps to MetaProperty in my proposal. In fact, the standard implementation of MetaProperty uses a PD internally. Although having the reference to the bean in a Property object doesn't seem like much, it actually turns out to make the whole system a lot more OO and usable.<br /><br />@Sacrin, this post is about property objects. I don't care that much about the details of the syntax to get from your m_surname to propertySurname() except that it happens. Of course I'm not proposing propertyM_Surname(). Perhaps you'd care to blog about the language change you'd like instead?Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-53849778745275988162007-01-08T19:56:38.000+00:002007-01-08T19:56:38.000+00:00Richard, I don't think Property is analogous t...Richard, I don't think Property is analogous to java.beans.PropertyDescriptor. PropertyDescriptor is more like MetaProperty, not Property.<br /><br />I've also implemented something reasonably similar to Stephen's proposal in order to get increased type safety. My solution is driven by reflection, rather than code generation, which eliminates a compile step, but catches fewer errors at compile time.Curt Coxnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-60153796568898798092007-01-08T18:53:20.000+00:002007-01-08T18:53:20.000+00:00One concern I have about the -> syntax is that ...One concern I have about the -> syntax is that it has a different meaning in C++, which could be confusing to people. I noticed that Cay Horstmann was using the @ symbol as an operator of sorts, though I'm not sold on that particular choice (shows up in some other languages as the attribute in an XML document).<br /><br />I'm not sold that we need to have a Property interface, because we already have the java.beans.PropertyDescriptor. If necessary, we could augment the PropertyDescriptor. True, PD doesn't have a reference to the instance.<br /><br />Your example code would become:<br /><br />binder.bind(person, Person->surname);<br /><br />Or some such thing. I'm using the -> even though I'm not particularly fond of it, just for consistency with the rest of your post.<br /><br />I've only vaguely thought about this problem so far. I'm hoping this might stimulate something in the conversation.Richard Bairnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-15501648809572918562007-01-08T18:24:00.000+00:002007-01-08T18:24:00.000+00:00My company requires that member variables start wi...My company requires that member variables start with m_. I can just see it now.<br /><br /><br />public void setM_Name(String m_Name) { this.m_Name = m_Name; }<br /><br />lovely. <br /><br />Get a life. add something of value to the language if you need to get your jollies.Sacrinnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-44403631290051855952007-01-08T16:51:35.000+00:002007-01-08T16:51:35.000+00:00@Ricky, I believe that a special syntax for access...@Ricky, I believe that a special syntax for accessing a property object might well make sense. But I see that as an addition to the base proposal. The most obvious choice is ironically the arrow pointer.<br /><br />binder.bind( person->surname );<br /><br />If you don't have the syntax, then users can simply call new SimpleProperty themselves and be no worse off than now.<br /><br />@Laurent, the property objects I'm proposing here are compiler checked, and auto-generated by the new property generation.<br /><br />I don't see compiled method references as the answer to this particular problem, as you need at a minimum a get and set method reference plus the bean to be invoked in order to create a full property.<br /><br />@Dobby, Glad you enjoyed the Javapolis whiteboards!Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-51276018670972293532007-01-08T14:58:38.000+00:002007-01-08T14:58:38.000+00:00I totally agree that referring to method through S...I totally agree that referring to method through Strings doesn't scale on a serious project. But as we're talking about JDK7, the solution I think will come with a manner to reference a method in a static, compiler-checked way.<br /><br />Meanwhile defining properties as dedicated objects sounds the best to me. When I used the excellent Joda-time library (just noticed you're the author, congratulations) I felt very comfortable with its property system. Though I guess it means a lot of boring implementation code.<br /><br />I don't know if you heard about Scala, a fonctional / object-oriented language with strong Java bindings. As functions are first-class objects it's easy to implement properties without adding keywords. This is what the guys do propose:<br />http://scala.epfl.ch/examples/files/properties.htmlLaurent Caillettehttp://jroller.com/page/softmotionnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-5103368292763992812007-01-08T12:53:01.000+00:002007-01-08T12:53:01.000+00:00If properties are added to the language and this f...If properties are added to the language and this feature is not possible I would call it syntax sugar. But being able to do "binder.bind( person.propertySurname() );" is just very necessary. A college and I made a comment on these features on the javapolis white boards (topic Properties) http://www.javapolis.com/confluence/display/JP06/Whiteboard+results+-+General+ideas.Dobbynoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-90085203702255710962007-01-08T10:14:28.000+00:002007-01-08T10:14:28.000+00:00Nice, I like it! I can see this would seriously cl...Nice, I like it! I can see this would seriously clean up some of my code.<br /><br />Ricky: I don't think that really has to be a barrier to entry on this. If you have old beans which you cannot / do not want to recompile, you simply do not have the above features available. <br /><br />Just like Generics - if you are using old non-generic code where definitions of generics might be helpful, then your just as stuck. (okay, okay, that wouldn't be a simple recompile, but that's not my point).Kieron Wilkinsonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-6433715144953277652007-01-08T01:14:42.000+00:002007-01-08T01:14:42.000+00:00propertySurname wouldn't exist for old code wi...propertySurname wouldn't exist for old code without recompiling (not always practical). I disagree that it needs to exist at all, though.<br /><br />binding.bind(property object.surname);<br /><br />is unambiguous, and can be inferred from existing getSurname and setSurname methods.<br /><br />In short, any property proposal that treats old <b>bytecode</b> as a 2nd-class citizen needs improving.Ricky Clarksonhttp://cime.net/~ricky/noreply@blogger.com