On Fri, 22 Apr 2011 07:59:54 -0400, Steve Schveighoffer
<[email protected]> wrote:
From: Robert Jacques <[email protected]>
To: Discuss the phobos library for D <[email protected]>
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
<[email protected]> 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(){})
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
