[phobos] Time to get ready for the next release

[Robert Jacques]

On Fri, 22 Apr 2011 00:26:40 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:
>> > Allowing for @property functions to be called with parens or
>> > non- at 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'?