On Fri, 22 Apr 2011 00:26:40 -0400, Jonathan M Davis <[email protected]>
wrote:
> Allowing for @property functions to be called with parens or
> non-@property
> functions to be called without parens leads to major inconsistencies
in
> usage
> of functions, and generally makes @property pointless. Even if you
make
> it so
> that @property functions can't be called with parens while allowing
non-
> @property functions to be called without them, then that leads to
> inconsistent
> syntax for function calls and makes it harder to know whether
something
> is
> actually a property function or not.
Why is this a benefit? Since your concept of a 'property' differs from
mine, @property can only muddy the waters (unless we're both writing
code
using the same standards document). Being able to switch between call
styles, allows me to self document my own (or my company's) guide-lines
into the code. Besides, why should I care if something is a 'property'
function or a regular function? or even a field, for that matter?
There's
field syntax and there's method syntax, but why should the library care
how I choose to access their code? They don't have to read/review it. I
(and my team/managers, etc) do.
One of the points of properties that I've seen commonly discussed in
languages
in general is the fact that you can more or less seemlessly switch
between
something being a public member variable and a property function.
Actually, seamlessly switching between field and field-like methods isn't
a design goal of 'properties'. The actual design goal is to allow the
promotion of a field into a member function. Once that occurs, you can
never go back, due to method overloading. In fact, OOP concerns were one
of the major driving forces behind 'properties' in the first place.
As soon as
you're loose about enforcing property syntax that doesn't work.
Actually, since you're not actually suppose to ever downgrade a 'property
function', this isn't that big of a deal. And at a more formal level,
Methods-as-Fields is a subset of the Uniform access principle. And UAP is
capable of downgrading any function, not just 'property function's, to a
field, so long as inheritance isn't an issue.
And the fact
that D is loose about it is incredibly bizarre.It's the only language
that I
know of that works that way.
Both Ruby and Eiffel do similar things.
Typically, property syntax is strictly enforced
for property functions and completely disallowed for non-property
functions.
C# definitely works that way.
Property functions are part of the API of a library. The fact that they
are
property functions is part of that API, just like the names of functions
and
how many parameters they have is part of the API. So, making it so that
@property is strictly enforced such that it strictly defines the syntax
for
calling a function isn't really any different from requiring that you
use a
specific name when calling a function.
So 'properties' should be strict because ()s are part of the API, but ()'s
are only part of the API if 'properties' are strict. (circular logical is
circular)
Making it loose instead is actually the
sort of thing that is extremely uncommon in programming. Programming
syntax is
generally very exact.
I do not think that word means what you think it does. Yes, programming
languages need to be unambiguous/exact simply to compile. However, they
very often include multiple ways of doing the same thing; infix operator
overloading and functions, fields and methods, objects and structs,
if/for/foreach/do/while/goto/break/continue, with(...), etc. The option of
using ()'s or no-()'s can be view similarly. Note that all those examples
have sparked various debates, spawned languages and list wars over the
years. D is a multi-paradigm language and should allow you to express
'property' based design as well as non-'property' based design.
What it sounds to me like is that you just don't like the idea of
property
functions and don't want to have to ever use them as property functions.
I'm sorry for that impression. I believe it's party due to the nature of
this thread. It began as a response to your assertion that there were zero
problems with strict property enforcement. I hope this discussion has at
least raised your awareness of some of the issues that exist with strict
'property' enforcement and that you have given some thought to their
importance relative to the benefits of strict 'properties'.
I whether I like or dislike 'property functions' is really dependent on
your definition of what they are. I've used different "properties" before,
read up on their history, usage and conceptual evolution in other
languages and academia. C# style 'properties' are, quite literally, a copy
of the first 'quick hack' to solve several key software engineering
problems. This isn't actually a criticism; the extreme power of C++'s
templates, as I understand it, was something of an accidental discovery
followed by an evolutionary process. And, in other languages, the original
concept of 'properties' has evolved as well. I'd put D as about halfway in
the evolutionary process (as currently defined) today. The mixing of field
and method notation is still a fairly new concept as programming languages
go, and I don't believe the concept has been fully explored and put to
rest yet. So yes, the trail isn't as broken in as we may have liked, but I
don't believe that is a reason to head back, as it were. As we run into
issues, we should evaluate them, dissect the root problem and then
brainstorm multiple possible solutions and ways to go forward.
Personally, I think that it is _way_ better than the incredibly lax way
that
property syntax has been handled in the past. And it seems perfectly
normal to
me that they'd be just as much a part of the API as the function's name.
Except that it isn't normal, historically speaking. Pre-'properties', no
one would consider ()'s as part of a function's API. And in
post-'property' languages, no one considers ()'s as part of the API. That
'properties' even gave designers control over ()'s in the first place, is
more an artifact of implementation then active, intended design.
If
@property isn't enforced, then I don't see much point in ever having
added it
in the first place. The only advantage that I can see with having
@property
and lax enforcement over no @property at all is the incredibly rare
ambiguity
with delegates, and I honestly don't think that that problem merits
adding
@property. Strictly enforcing @property, on the other hand, and making
the
syntax consistent _is_ well worth it.
What do you mean by 'consistent'?
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
