Revised RFC on range design for D2

[Michel Fortin]

On 2008-09-30 09:42:43 -0400, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> "Michel Fortin" wrote
>> On 2008-09-29 12:55:18 -0400, "Steven Schveighoffer" said:
>> 
>>> Stdout.newline.formatln("Hi there {}", var);
>>> 
>>> Is newline a property of Stdout, on which I'm calling formatln, or is
>>> newline a function that I'm calling, and then using the result of that
>>> function to call formatln?  Compare with:
>>> 
>>> Stdout.newline().formatln("Hi there {}", var);
>>> 
>>> There is no ambiguity.  newline is clearly a function, not a property.
>> 
>> Interesting. To me both of these things have exactly the same meaning.
>> Perhaps it's because I'm used to D, but I think it's more because I can't
>> count how many times I've seen this pattern in C++:
>> 
>> SomeSimgleton::Instance().doSomething();
>> 
>> where Instance() is simply an accessor.
> 
> Yes, that is a workaround for not having property constructs available.  The
> intuitive label of 'property' comes from the name of the getter 'Instance'.
> It screams that you are getting the instance of the class, and it's well
> accepted as a property.  What has happened is that instead of relying on the
> compiler to enforce what is a property and what is not, you are relying on
> the interpretation of English words.

But one problem is that the distinction between a accessor (of a 
property) and a function is often matter to interpretation. In the case 
above, most likely the Instance() function will create the singleton 
object if it doesn't exist yet; seen that way it isn't a simple 
accessor. If you ask if Instance() should be a property or not, you're 
likely to get different answers from different people.

Arguably, there are cases even more ambiguous than this one. The issue 
I want to bring is that without having a formal definition of what is a 
property and what is not -- one the compiler can enforce -- people will 
make different choices, not always coherent with each others, and you 
may very well find yourself having to call Instance() with parenthesis 
in one D lib and without parenthesis in another.


> But in a language like C#, you would define Instance as a property, not a
> function.  So it would never look like that.

I could, but should I?

I'm very interested in your criterions about why Instance would qualify 
to be a property and not as a function in this case.

It's not just me. Just as an example, this article's author doesn't 
want to decide if Instance() should be a property or not:
<http://www.yoda.arachsys.com/csharp/singleton.html>
"Note that all of these implementations also use a public static 
property Instance as the means of accessing the instance. In all cases, 
the property could easily be converted to a method, with no impact on 
thread-safety or performance."


> In D, properties are equivalent to functions, so you have a choice as to
> whether to use the parentheses or not.  But that isn't the problem, the
> problem is really that you can call functions as properties.

But what is the difference between a property and a function (beside 
the syntax?). I can find countless discussions on the net about this; 
interesting discussions but with no definitive answer. In the end, it 
all boils down to the author's feeling about his function/property, 
which may be the opposite from its user's.

I'd like very much to quote Bruce Wood from this discussion:
<http://bytes.com/forum/thread478064.html>

(feel free to comment the quote)

"""
You see, it's not always so cut-and-dried.

On the one hand, if you make something a property, you are implying
that getting the information will be quick. So, if getting the
information is slow, that is a hint that it shouldn't be a property.

On the other hand, you don't want to determine what is a property or
not based upon implementation details. By doing so you're letting the
internal guts of how your class works leak out into its interface with
the outside world. That's bad style. So, something should be a property
if it makes sense that it be a property.

Certainly, anything that affects the state of the object in a manner
more sophisticated than just "set this to that" should be a method.
That's painfully obvious.

Similarly, an aspect of your class that can be read and set, even if
setting it does more than just set a variable, should probably be a
property. Reasonably straightfoward.

However, sometimes the two design goals above-properties that return
results quickly and not letting implementation determine
interface-are at odds with each other, and you have to make a
judgement call.

In the case of my system, I had things that logically should be
properties (from an interface point of view) but the object held only
keys, not references to the objects themselves, so the "get" on the
property has to fetch the object in question from the database. It was
an open question whether to code:

Supplier theSupplier = stockItem.Supplier;

or

Supplier theSupplier = stockItem.GetSupplier();

I chose the former, preferring to hide the implementation (holding
supplier UID, not supplier itself) rather than let it leak out that
getting the supplier was actually a lot of work. In our case it's no
problem, because we're a very small shop. In a different situation I
might have gone for door #2.
"""

With the current approach in D, you just don't need to choose, just 
document what your function/property is doing and be done with it... 
well you may still have to choose about the name :-), so in a way the 
argument is still there, but what I mean is that I don't think we 
really need a black and a white syntax for one concept that may take 
many shades of gray.


>> In my opinion, "newline" isn't a good function name for what it does
>> because it has no verb. Having no verb makes it look like an accessor much
>> more than the absence or presence of parenthesis.
> 
> So newline() seems like a property to you more than 'start a new line'?  I
> suppose I can see that, but consider if you were used to a system where
> properties *prohibited* parentheses, and functions *required* them.  It
> becomes less about interpretation of English vocabulary and more about
> compiler-enforced interface.  I like that system better.

But I'm still puzzled by what being a property means in opposition as 
if it was a function.

The thing is that the compiler just can't guaranty anything about 
properties: it's really just another syntax for calling a function, a 
function the author has classified as a property by some subjective 
standard, a standard which will often differ between authors. 
Properties are often touted as an indicator for low-cost functions -- 
whatever "low-cost" means --, but even this fuzzy standard somewhat 
hinder the often seeked goal of separating interface and implementation.

Without aggreement on a formal definition for properties and compiler 
enforcability, I find it very difficult to justify a formal syntax for 
properties.

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