On 2009-08-01 11:56:23 -0400, Jarrett Billingsley
<[email protected]> 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
[email protected]
http://michelf.com/
