Revised RFC on range design for D2

[Bill Baxter]

On Thu, Oct 2, 2008 at 1:22 PM, Michel Fortin <michel.fortin at michelf.com> wrote:
> 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.

Interesting post.  My first thought is what is the formal definition
for what should be a struct and what should be a class.  That's not a
cut-and-dried clear decision either.  Either one will generally work.
I may think X should be a struct and my users may think it should have
been a class.  We can both be right.  Seems a pretty similar
situation.

--bb