<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div>BTW, I didn't mean to take this private, but when a message is sent to
both the list and me, the list doesn't send me an email, so I end up
replying to the person directly.<br>
<br>
Sorry.<br>
</div><div><font face="Arial" size="2"><b><span style="font-weight: bold;"><br></span></b></font></div><div><font face="Arial" size="2"><b><span style="font-weight: bold;">From:</span></b> David Simcha <dsimcha@gmail.com><br><b><span style="font-weight: bold;">To:</span></b> Steve Schveighoffer <schveiguy@yahoo.com><br><b><span style="font-weight: bold;">Sent:</span></b> Friday, April 22, 2011 9:49 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [phobos] Time to get ready for the next release<br></font><br>
</div><div id="yiv784285841">
On 4/22/2011 9:40 AM, Steve Schveighoffer wrote:
<blockquote type="cite">
<pre><br><br>----- Original Message -----<br></pre>
<blockquote type="cite">
<pre>From: David Simcha <a rel="nofollow" class="yiv784285841moz-txt-link-rfc2396E" target="_blank" href="mailto:dsimcha@gmail.com"><dsimcha@gmail.com></a><br>To: Steve Schveighoffer <a rel="nofollow" class="yiv784285841moz-txt-link-rfc2396E" target="_blank" href="mailto:schveiguy@yahoo.com"><schveiguy@yahoo.com></a>; Discuss the phobos library for D <a rel="nofollow" class="yiv784285841moz-txt-link-rfc2396E" target="_blank" href="mailto:phobos@puremagic.com"><phobos@puremagic.com></a><br>Cc: <br>Sent: Friday, April 22, 2011 9:09 AM<br>Subject: Re: [phobos] Time to get ready for the next release<br><br>On 4/22/2011 8:43 AM, Steve Schveighoffer wrote:<br></pre>
<blockquote type="cite">
<pre> There are a couple problems with this.<br><br> First, there is the WTF factor when you want to set multiple colors with <br></pre>
</blockquote>
<pre>the same value:<br></pre>
<blockquote type="cite">
<pre> hist1.barColor = hist2.barColor = getColor(255, 0, 0);<br><br> WTF? this is an error? But this works (enjoy the clarity of this):<br><br> hist1.barColor = (hist2.barColor = getColor(255.0, 0)).barColor;<br></pre>
</blockquote>
<pre>Yeah, it would be nice if the first one worked, but in a plotting library the <br>second is more useful in practice. When it comes to minor details like this, <br>IMHO convenience is more important than consistency. Maybe if strict semantics <br>are implemented, this could be solved by allowing property to be overloaded <br>against non-property and defining a fluent mixin to define both in a single line <br>of code. Defining both manually is anti-DRY and not even worth considering. <br>IMHO they should have the same name because it's less crap to remember.<br></pre>
</blockquote>
<pre>I think it would be enough to generate the setX version by giving it X. I.e.:<br><br>@property int x(int newval) { return _x = newval;}<br><br>mixin(fluent!"x"); => typeof(this) setX(int newval) { x = newval; return this;}<br><br>I don't agree that the name of the fluent setter and the property should be identical. IMO, it's only this way because it's a cute trick, one which has ambiguity issues in the general case. In other words, if you didn't have functions-as-properties in the D language, would you feel it is the "right thing"? I have never seen anyone want this kind of stuff in languages that have strict properties. They code along happily without complaint :)<br></pre>
</blockquote>
<br><div>
One difference is that I've already written the code, it works well
and I don't want it to break now that D is "stable". The other is
that people in other languages have never been exposed to the D way
and don't know any better. The third is that, other than enforcing
your vision of "correct" API design and making D more of a
bondage-and-discipline language, I can't see what strict semantics
accomplishes over loose semantics that would justify breaking
anything that already exists and is even remotely useful. Loose
semantics solve the ambiguity problem that @property was meant to
solve. Strict semantics create problems like breaking certain API
designs (whether these are "good" designs is subjective <b>and
should be decided by the library designer, not the language
designer</b>) and don't solve any additional ones.<br></div>
</div><br>---------<br><br><div>In this case, it's not actually the
library designer, but the user of the library that is deciding the
semantics. Big difference, and my huge problem with D's properties.</div>
<div><br>
</div>
<div>With strict properties, the power is to the library designer to
decide on semantics. With loose properties, it's to the user. You can
think you are creating a usable API, but it's still possible to abuse
it.</div>
<div><br>
</div>
<div>In other words, loose properties prevents *my* designs, even if it
makes *your* usage possible. Note that it's your usage, *not* your design
that you are enforcing. The API is beyond your control since the user
is free to call however he/she wants.</div>
<div><br>
</div>
<div>So I think the language shouldn't hinder the library author's designs in favor of the caller abusing usage.<br>
</div>
<div><br>
</div>
<div>-Steve<br></div>
</div></body></html>