property / getProperty() / setProperty()

[Michel Fortin]

On 2009-08-01 11:56:23 -0400, Jarrett Billingsley 
<jarrett.billingsley at gmail.com> said:

> It's been mentioned before, and I'll mention it again: a simple
> 'property' attribute that can be applied to any function.  No new
> syntax, no get/set/value 'magic' keywords, just 'property.'  Applying
> it to a function makes the compiler enforce the property syntax when
> using the functions.  Any function that doesn't have the property
> attribute - which should be most functions - can't be treated as one.
> It doesn't require any special support from the compiler beyond what
> it currently does.  It doesn't require any 'magic'.  It doesn't
> require any verbose syntax.  It solves pretty much all the problems.

That wasn't addressed to me, but since I started this thread, I feel I 
should answer.

What problems does your proposal solve that aren't solved by a naming 
convention and the compiler following that convention to enable the 
property syntax?

>From what I see, you prefer adding a property keyword over a naming 
convention. That's fine, but I think otherwise. Let's compare them on a 
technical level using your checklist:

> 1. You can no longer call functions as properties that were never
> intended to be (writeln = 4; goes away).

Same as with a get/set prefix, except that you can now explicitly call 
getSomething()/setSomething() if you want (a minor advantage in my 
opinion).

> 2. The "obj.prop(args)" ambiguity goes away.  *Either* obj.prop is a
> normal method function and (args) are passed to it, *or* obj.prop has
> the "property" attribute, and (args) are passed to its result.  Stuff
> like "obj.prop[i]" is the same way.

Either obj.prop binds to a real function, or it isn't really there and 
the compiler maps it to getProp/setProp as needed. Same thing for 
"obj.prop[i]", which would be equivalent to "obj.getProp()[i]" if there 
is no "prop" member in "obj".

So both proposals are as good in this respect.

> 3. There is no naming ambiguity.

A set/get prefix removes pretty much all ambiguity too.

I mean, the current syntax is "T transform()" and you can't know if 
transform is a noun or a verb. With my prefix it's "T getTransform()" 
which makes it pretty clear what it does. With yours it's "property T 
transform()" and it's pretty clear too.

> 4. There are no case issues.

Indeed. +1 for your proposal.

> 5. It provides useful semantic information to tools, IDEs, and reflection.

With a get/set prefix too you can get useful information about what you 
can set and get too. Sure you assume that get means get and set means 
set, just like you assume that everything using the property keyword is 
really meant to be a property with your proposal. (Both systems can be 
abused as easily, that's my point.)

> 6. It's nonintrusive and self-documenting.

I'm not sure if you'd find a get/set prefix non-intrusive or not (I 
don't), but I find it as self-documenting as a property keyword.

And to compensate that +1 for you above, I'd point out that there is an 
alternative with no case issue (get_thing/set_thing) and that your 
proposal requires a keyword.

I have nothing against your proposal. I prefer the aestetics of mine 
and I believe they're both pretty equal on technical ground.

> The *only* technical issue I can come up with is if you had "property
> ref X foo()", where foo returned a reference to some value type.  Then
> you do "&obj.foo" - what does this get the address of?  To that end, I
> suggest that &obj.foo always gets the address of the member or method
> 'foo' from object 'obj', and &(obj.foo) would get the address of the
> return value of obj.foo.  The extra parens in there say "really, I
> want you to evaluate the thing inside *first*".

Interesting. That's a problem that doesn't exist with with the naming 
convention proposal.

About your idea, I find it confusing that (&something) and &(something) 
may not have the same meaning.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/