tag:blogger.com,1999:blog-8678405.post3851835025261319116..comments2023-09-02T15:54:52.482+01:00Comments on Ricky's technical blog: Ricky's Properties for JavaRicky Clarksonhttp://www.blogger.com/profile/13845104548520132930noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-8678405.post-65757501732785541812007-02-22T01:15:00.000+00:002007-02-22T01:15:00.000+00:00Excellent proposal! It does away with a lot of con...Excellent proposal! It does away with a lot of confusion that still exists, even in the Java API: one sometimes has getName(), sometimes name(). With your kind of first-class properties, things are a lot clearer and we'd get some of the elegance that Self has had for decades. Gilad Bracha's <A HREF="http://gbracha.blogspot.com/2007/01/representation-independent-code.html" REL="nofollow">blog entry</A> applies here, as well.<BR/><BR/>Note: Property change events are important to consider, too. Having the listener handling etc. generated is a big plus for GUI programming (data binding!).<BR/><BR/>All these new features are backwards compatible, easy to understand and not syntactically awkward. I wish closures could be as elegantly done (well, maybe if they were only syntactic sugar for single-method implementations plus runtime exceptions for return, break and continue).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8678405.post-68571038728851050532007-02-21T11:30:00.000+00:002007-02-21T11:30:00.000+00:00why not just use some annotation and bytecodegener...why not just use some annotation and bytecodegeneration via cglib or something else?<BR/><BR/>so everyone can choose to do it. and we don't break old code which may happen. This is illustrated by the for loop example.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8678405.post-60905537001147519352007-02-21T08:42:00.000+00:002007-02-21T08:42:00.000+00:00Well Sproket,The for loop is basically designed to...Well Sproket,<BR/><BR/>The for loop is basically designed to test the condition at each iteration, so neither count(as property) nor getCount() would hold the "performance gains" you describe in the third example, and they shouldn't.<BR/><BR/>The performance gain is when using the for condition in a finite expression. Remember that the coung property may change its value during the code we iterate over. Hence to hold the "true" number at the beginning of the iteration can be a good thing<BR/><BR/>As to the price of method accessing property value, I think that encapsulation is a good idea and both forms yields little or no overhead in the simple getter.Niels Bech Nielsenhttps://www.blogger.com/profile/00036467164500469290noreply@blogger.comtag:blogger.com,1999:blog-8678405.post-67747035623254879312007-02-21T02:05:00.000+00:002007-02-21T02:05:00.000+00:00"Properties remove the readability price that we c..."Properties remove the readability price that we currently pay for using accessors instead of public fields."<BR/><BR/>You mean like:<BR/><B><BR/>for (int j; j < count; j++) {<BR/>//---<BR/>}<BR/></B><BR/><BR/>as opposed to :<BR/><B><BR/>for (int j; j < getCount(); j++) {<BR/>//---<BR/>}<BR/></B><BR/><BR/>OOPS! I shouldn't have a getter in a loop! <BR/><BR/>Maybe it should be<BR/><B><BR/>int count = getCount();<BR/>for (int j; j < count; j++) {<BR/>//---<BR/>}<BR/></B><BR/><BR/>See how properties REDUCE readability AND can introduce performance problems in code?<BR/><BR/>"Properties remove the code duplication price that we currently pay for getters and setters. That price is better measured in time to read code than keypresses."<BR/><BR/>In IntelliJ I press alt-insert and then chose the fields and press enter. Yeah, lots of keystrokes. Additionally I can view the structure of the class which quickly indicates fields vs properties.<BR/><BR/>Try a little harder.Dan Howardhttps://www.blogger.com/profile/11454093132962945782noreply@blogger.com