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.
Sorry. From: David Simcha <[email protected]> To: Steve Schveighoffer <[email protected]> Sent: Friday, April 22, 2011 9:49 AM Subject: Re: [phobos] Time to get ready for the next release On 4/22/2011 9:40 AM, Steve Schveighoffer wrote: > >----- Original Message ----- > >From: David Simcha <[email protected]> >>To: Steve Schveighoffer <[email protected]>; Discuss the phobos library for >>D <[email protected]> >>Cc: >>Sent: Friday, April 22, 2011 9:09 AM >>Subject: Re: [phobos] Time to get ready for the next release >> >>On 4/22/2011 8:43 AM, Steve Schveighoffer wrote: >> >>There are a couple problems with this. >>> >>>First, there is the WTF factor when you want to set multiple colors with >>> >>the same value: >> >>hist1.barColor = hist2.barColor = getColor(255, 0, 0); >>> >>>WTF? this is an error? But this works (enjoy the clarity of this): >>> >>>hist1.barColor = (hist2.barColor = getColor(255.0, 0)).barColor; >>> >>Yeah, it would be nice if the first one worked, but in a plotting library the >>second is more useful in practice. When it comes to minor details like this, >>IMHO convenience is more important than consistency. Maybe if strict >>semantics >>are implemented, this could be solved by allowing property to be overloaded >>against non-property and defining a fluent mixin to define both in a single >>line >>of code. Defining both manually is anti-DRY and not even worth considering. >>IMHO they should have the same name because it's less crap to remember. >> >I think it would be enough to generate the setX version by giving it X. I.e.: > >@property int x(int newval) { return _x = newval;} > >mixin(fluent!"x"); => typeof(this) setX(int newval) { x = newval; return >this;} > >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 :) > 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 and should be decided by the library designer, not the language designer) and don't solve any additional ones. --------- 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. 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. 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. So I think the language shouldn't hinder the library author's designs in favor of the caller abusing usage. -Steve
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
