[phobos] Time to get ready for the next release

[Robert Jacques]

On Fri, 22 Apr 2011 07:59:54 -0400, Steve Schveighoffer  
<schveiguy at yahoo.com> wrote:
>> From: Robert Jacques <sandford at jhu.edu>
>> To: Discuss the phobos library for D <phobos at puremagic.com>
>> Sent: Thursday, April 21, 2011 4:05 PM
>> Subject: Re: [phobos] Time to get ready for the next release
>>
>> On Thu, 21 Apr 2011 15:57:57 -0400, Jonathan M Davis  
>> <jmdavisProg at gmx.com> wrote:
>>
>>>> How about the amount of existing code it breaks?  How about the fact  
>>>> that
>>>> it breaks using the same function for both method chaining and with
>>>> property syntax?
>>>
>>> Something like
>>>
>>> auto b = a.prop1.prop2.prop3;
>>>
>>> should work. I doesn't at present, but it should. There's a bug report  
>>> on it.
>>
>> What about auto b = a.prop1(5).prop2(6).prop3(7); ?
>
> Looks like a poor design.  If a setter property returns anything, it  
> should return the value set.  Otherwise:
> auto b = a.prop1 = 5; // I would expect b == 5

I both David and I have responded in depth to this in other threads. In  
short, trying to decide the goodness of an API design using an abstracted,  
out of context, reduced code snippet designed to highlight the syntactic  
constructs it uses is fallacious.

> my solution:
>
> define a setProp1, setProp2, and setProp3 without property semantics.   
> It also reads better:
>
> auto b = a.setProp1(5).setProp2(6).setProp3(7);

However, in the real API, setProp is a strictly inferior design. In point  
of fact, your proposed solution suffers from several issues:

1) It isn't DRY (Don't Repeat Yourself). Not only do you have simple code  
duplication, but you also have to maintain equality of implementation, not  
just bug updates.
2) You've increased the radius of comprehension of your library. Users  
have to remember that both functions do the same thing and have to assign  
two different names to the action in their head and then use them  
appropriately in there code, based on the syntax they wish to use.
3) If setProp actually read better in real life, we'd use it. But it  
doesn't, so we aren't. By the way, I would hazard that setX/getX are one  
of the most famous/infamous pieces of API design out there and that  
everyone can/does consider it.

>>> As for breaking existing code, _of course_ it's going to. That's to be
>>> expected, and I would have thought that that was expected when  
>>> @property was
>>> introduced in the first place.
>>
>> Actually, no it wasn't expected. @property was introduced with loose  
>> semantics, not strict semantics. And, by the way, it was judged worth  
>> while with only loose semantics.
>
> I don't know what messages you read, but strict properties were what was  
> approved.  There have been numerous discussions on the NG regarding  
> properties, some pro-strict, some pro-loose, but the one which got the  
> deal done was pro-strict.

I've been following/part of the 'property' discussions from day 1. My  
memory was that @property was 'accepted' inside a pro-strict thread, but  
wasn't pro-strict itself, and that there was a follow-up confirmation of  
loose-ness. But, alas, I've deleted my own local newsgroup history and my  
search-fu is weak. So I can't even find any kind of 'acceptance' post let  
alone it's context and follow-up. About the best I could find, one way or  
the other, is a bunch of circumstantial posts indicating the desire to  
patch a hole, as opposed to replacing the ship. But that could just have  
been earlier in the decision process. Anyways, my searching did turn up  
some apropos comments from Andrei:

"
To clarify: if there was any extra checking by the compiler, any
guarantee that the feature would provide at all, I'd be glad to pay the
price of thinking more when putting together a design. But you want to
define a language feature that allows people to require "()" or not as
they please, and that's all. It's a frivolous detail to be spending time
on when designing an API. I simply don't believe that's good language
design.

Andrei
"
"
The problem is that it's all loss, no gain: the callee must make the
decision whether the call must be with or without parens, and the caller
must obey that decision. There is no guarantee gained, only effort.
"

> The loose semantics were introduced to serve as a translation period,  
> where you could migrate property code to using @property.  From what I  
> remember, Walter tried to turn on strict properties, but found too many  
> errors in Phobos to deal with.  So it has been back-burnered.

I don't remember that ever being posted to the newsgroup. And since, the  
critics of strict 'properties', included myself, would have discussed  
this, and I can search for myself just fine, I going to trust my memory.

> Without strict properties, the author of the code cannot enforce usage  
> semantics, and therefore, will lead to ambiguities.  The only exception  
> I can see is calling a function with no arguments which returns void  
> without the parentheses.  It cannot be mistaken for a property getter,  
> because it can't be used as a getter.

Could you please present an example of an ambiguity in the general case?  
(i.e. excluding assignment to const/immutable/(static pure) functions and  
the delegate() foo(){})