<< Property Accessors | Home | CastMapR >> | Conferences & TechTalks Calendar | Legal Notice | Google+ Profile | Twitter Page | My Profile Page

Property Accessors - 2

The first discussion results

Here's a short update:

At the moment there's not much to tell but I'd found at lot of interest in properties support in Java and I'm glad to see people like the general idea.

The first discussion started mostly about how the syntax should look like and why defining a new one if there are already languages with properties syntax out there.

I collected some of the current available syntax examples and there seems to be no clear, short and standard syntax out there. Everyone defined something on his own and the most impressive realization is that the syntax of JavaScript is more similar to C# than to ActionScript although those both languages are related (ECMAscript).

Here are some examples I collected:

public function get color():int { ... }
public function set color(value:int):void { ... }

private int color;
public int color {
get {
set {

attr_accessor :color

Well no real kind of property but could be
emulated using operator overloading

MS C++:
_declspec(property(get = getprop, put = putprop)) int the_prop;

private int m_color;
@property public int color() { ... }
@property public int color(int value) { ... }

Delphi had some way but I don't remeber it (thanks to
god I finally forgot about Delphi).

color: {
get: function() { ... },
set: function(value) { ... }

@property int *color;
@synthesize color;

function __get($property) { ... }
function __set($property, $value) { ... }

 So what do you guys think would be a nice syntax to be implemented?

The second point of the discussion is about introducing some new keywords and the explanation about how hard it was to add the enum keyword in Java 5.

So I suggested to to extend the field syntax of public / protected members the same way my proposal did with the new property keyword. To auto-generate getters / setters there needs to be found a solution. One possibility could be an annotation @java.lang.Property (see below) or similar but that would mean that old code can not automatically benefit because it's not annotated.

So about the annotation itself it could look similar to the following example:br/>

public @interface Property {
boolean writable() default true;
boolean readable() default true;


So far about the state of the discussion.

Related Posts
The Hazelcast Incubator
snowcast - Hazelcast Client and the snowcast logo
snowcast - Migration and Failover

Add a comment Send a TrackBack