Comments on: Proper Properties http://www.blog.dannynet.net/archives/81 Pondering Programming and Poetry Thu, 28 Aug 2008 23:07:05 +0000 http://wordpress.org/?v=2.6 By: Erik van Oosten http://www.blog.dannynet.net/archives/81#comment-24346 Erik van Oosten Wed, 28 Mar 2007 19:39:33 +0000 http://www.blog.dannynet.net/archives/81#comment-24346 Okay, its here. Someone has really done it: https://bean-properties.dev.java.net/ Okay, its here. Someone has really done it:
https://bean-properties.dev.java.net/

]]> By: Danny http://www.blog.dannynet.net/archives/81#comment-13850 Danny Tue, 06 Feb 2007 09:04:56 +0000 http://www.blog.dannynet.net/archives/81#comment-13850 @Ricky: okay, have it your way then: we make the switch work the other way around. So the compiler would by default generate accessor methods. Only if you use the switch, it won't generate them. If individual files need non-default behaviour, use the class-level annotation (instead of using different compiler switches for those files). This is hardly a first for Java; see assertions. Still no need for extra keywords or a confusing dot syntax. @Ricky: okay, have it your way then: we make the switch work the other way around. So the compiler would by default generate accessor methods. Only if you use the switch, it won’t generate them. If individual files need non-default behaviour, use the class-level annotation (instead of using different compiler switches for those files). This is hardly a first for Java; see assertions.

Still no need for extra keywords or a confusing dot syntax.

]]> By: Ricky Clarkson http://www.blog.dannynet.net/archives/81#comment-13790 Ricky Clarkson Mon, 05 Feb 2007 19:26:28 +0000 http://www.blog.dannynet.net/archives/81#comment-13790 Having to set command line options just makes using Java harder. You'd have to have separate compiles for separate files (assuming two files in the same codebase want different options). I'd much prefer doing this in the language. A 'property' keyword would be fine, and would only need to be a contextual keyword, i.e., in existing code, 'property' is already not allowed in the position it would be placed. In this way, no existing code is broken, and there's no need for compile options. Also, one of the awkward things about properties as they stand is the syntax for access; there's nothing wrong with using a dot for property access instead of get/set methods. Having to set command line options just makes using Java harder. You’d have to have separate compiles for separate files (assuming two files in the same codebase want different options).

I’d much prefer doing this in the language. A ‘property’ keyword would be fine, and would only need to be a contextual keyword, i.e., in existing code, ‘property’ is already not allowed in the position it would be placed. In this way, no existing code is broken, and there’s no need for compile options.

Also, one of the awkward things about properties as they stand is the syntax for access; there’s nothing wrong with using a dot for property access instead of get/set methods.

]]> By: Danny http://www.blog.dannynet.net/archives/81#comment-11479 Danny Tue, 23 Jan 2007 14:44:18 +0000 http://www.blog.dannynet.net/archives/81#comment-11479 @Erik: it's so obvious I can't imagine I'm the first to think of it... <p> My idea is that you would have to explicitly set a command line compiler option to enable method generation. So if you don't set that option, nothing will be generated. So your existing code base would compile as is, without any side effects.</p> @Erik: it’s so obvious I can’t imagine I’m the first to think of it…

My idea is that you would have to explicitly set a command line compiler option to enable method generation. So if you don’t set that option, nothing will be generated. So your existing code base would compile as is, without any side effects.

]]> By: Remco van 't Veer http://www.blog.dannynet.net/archives/81#comment-11474 Remco van 't Veer Tue, 23 Jan 2007 14:24:06 +0000 http://www.blog.dannynet.net/archives/81#comment-11474 This is way too obvious! You are hurting the Java community! FieldReader, FieldWriter and FieldAccess are probably already claimed by a annotation squatter deep down in the labs of Sun. Or.. "annotations should not be used like this" and some lengthy discussion about compile time annotations being evil. ;) This is way too obvious! You are hurting the Java community! FieldReader, FieldWriter and FieldAccess are probably already claimed by a annotation squatter deep down in the labs of Sun. Or.. “annotations should not be used like this” and some lengthy discussion about compile time annotations being evil. ;)

]]> By: Erik van Oosten http://www.blog.dannynet.net/archives/81#comment-11470 Erik van Oosten Tue, 23 Jan 2007 13:58:34 +0000 http://www.blog.dannynet.net/archives/81#comment-11470 Hi Danny, Spot on! Actually, I was thinking along the same lines already. Guess its kind of obvious :) Just a small thing: having a private member get a setter/getter by default seems a bit dangerous because it makes existing code non portable. A big no-no for Sun. A third member annotation, and/or a class annotation could alleviate this easily. Erik. Hi Danny,

Spot on! Actually, I was thinking along the same lines already. Guess its kind of obvious :)

Just a small thing: having a private member get a setter/getter by default seems a bit dangerous because it makes existing code non portable. A big no-no for Sun. A third member annotation, and/or a class annotation could alleviate this easily.

Erik.

]]>