April 22, 2011
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.

// CTFE function that returns both property and fluent getters and setters,
// using the convention that the target variable is named _varName.
// Unfortunately this also requires overloading templates and non-templates,
// which needs to be fixed.
string fluent(string varName, string docString) {
     return "/**" ~ docString ~ "*/\nauto " ~ varName ~ "() @property {
return _" ~ varName ~ ";}\n" ~
                 "auto " ~ varName ~ "() { return _" ~ varName ~ ";}\n" ~
                 "typeof(this) " ~ varName ~ "(this This)(typeof(_" ~
varName ~ ") newVal) { \n " ~
                      " _" ~ varName ~ " = newVal;  return cast(This)
this; }\n"
                 "auto " ~ varName ~ "(typeof(_" ~ varName ~ ") newVal)
{ _" ~ varName ~ " = newVal;   return newVal; }"
}

> Second, it looks strange to have a function named barColor.  In an extreme interpretation, I could expect that with barColor, I am barring that color from the object ;)  Not that it would be a common interpretation, but the name looks more ambiguous than say, setBarColor.  There are certainly better cases that could demonstrate my point, as English is full of words that are both nouns or adjectives and also verbs.
>
In the context of a plotting library barColor makes perfect sense.  Lots of function names don't make sense when taken out of context, and requiring them to is a Draconian measure that would force all function names to be ridiculously long, like setHistogramBarColor().
April 22, 2011
Don Clugston wrote:
> It's now been two months since the last release, and there have been
> huge compiler improvements.
> Note also that there were a couple of very bad regressions in 2.052,
> so I think we really need a release ASAP.
> We've now achieved minimal stability again (all green on the auto-tester).
> 
> Here's the things which are blockers for the next release:
> 
> From the compiler side:
> * struct destruction of temporaries (seems like we have a chance of
> fixing this soon)
> * fixing the regressions from my CTFE/const folding changes (Fixes are
> here: https://github.com/D-Programming-Language/dmd/pull/37).
> * a few things haven't been backported to D1 yet
> druntime:
> * clean up Windows DLL support
> phobos:
> * nothing that I know of
> 
> Looks as though will be time to get std.parallelism in. But otherwise, if you have anything you'd like to get into the next release, please indicate so now.

Compiling the latest and greatest from github, I noticed a few things, most of them changes that broke existing code, good or bad.

- std.net.isemail does not seem to be compiled into the libary on windows. If it is, a debug compile fails because dmd stumbles over generating debug information for a string enum. Here's a patch that simply skips writing the enum fields, the type information is marked as incomplete anyway.

https://github.com/rainers/dmd/commit/9d69feb17f075757c9e6874f64b201fa2f40d5b0

- const string[] can no longer be passed to functions expecting string[] argument

This is correct, but very strict. The array pointer and length of the argument could be modifiable, but the data elements pointed to should not. unfortunately, there is no type to express that. (Would const(string[])ref do that?)

- variables of type string no longer implicitely cast to const(char)*

I'm fine with this change.

- const string values no longer accepted in switch-case, you have to use enum string.

I'm not so sure about this. You might want to use the same string elsewhere, too, so you will have to define it twice, once for switch statements with enum, and once for other runtime purposes e.g. taken the address of the string.

- struct initializers using {} are no longer evaluated at runtime? the compiler complains that the initializers do not evaluate at compile time.

I'm fine with replacing these with the Struct(args) syntax, but AFAIK it does not allow direct initializing of static arrays in the struct, you have to pass a dynamically created array literal. In my case I also needed to add an ugly cast(ubyte[]) to the argument, because [0,0] is interpreted as an array of integers.

- std.parallelism.atomicIncUint no longer compiles, because there seem to be stronger checks regarding shared. Seems good to me.

- the deprecation of octal numbers revealed an error in the Windows SDK header files (v6.0A, I haven't yet checked if it is fixed in newer versions).

With all these issues fixed, Visual D seems to compile and run fine. All changes are backward compatible, so I can still switch back to dmd 2.052.

Rainer
April 22, 2011
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 <dsimcha at gmail.com>
To: Steve Schveighoffer <schveiguy at yahoo.com>
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 <dsimcha at gmail.com>
>>To: Steve Schveighoffer <schveiguy at yahoo.com>; Discuss the phobos library for D <phobos at puremagic.com>
>>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/2df57f12/attachment.html>
April 22, 2011
On Fri, Apr 22, 2011 at 10:11 AM, Steve Schveighoffer

> 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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

If you look at it this way, then I fail to see the problem with a little abuse.  The library designer doesn't have to read the caller's code.  Why should he/she care if the API is being abused a little?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/8064ed5c/attachment-0001.html>
April 22, 2011
Bug reports.? People having stupid arguments just like this one on why you should change how the code works to fit their style ;)

Essentially, ambiguously named functions in the context of "I can call this as a property or a function" lead to people getting surprising behavior and then complaining about the surprise, when I can do nothing about it.

I've actually had this happen.? I had to change function names in Tango in order to avoid people complaining.? The example was, I had a bunch of generator functions in TimeSpan, like

// create a time spand that represents the given number of seconds

static TimeSpan seconds(int s)


which would be used like this:

auto s = TimeSpan.seconds(5);

But it could also be used as a property.? So this compiled and constructed a temporary time span and throw it away:

TimeSpan s;

s.seconds = 5;

So we had to change seconds to fromSeconds.? It still allows code like this:

s.fromSeconds = 5;

but instead of being disallowed, it just looks horrible, hopefully cluing the reader to go examine the documentation for TimeSpan.? That's the best we can do.? I have no power to enforce the usage.


-Steve




>________________________________
>From: David Simcha <dsimcha at gmail.com>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Friday, April 22, 2011 10:19 AM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>
>
>
>On Fri, Apr 22, 2011 at 10:11 AM, Steve Schveighoffer
>
>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
>>phobos at puremagic.com
>>http://lists.puremagic.com/mailman/listinfo/phobos
>>
>If you look at it this way, then I fail to see the problem with a little abuse.? The library designer doesn't have to read the caller's code.? Why should he/she care if the API is being abused a little?
>
>_______________________________________________
>phobos mailing list
>phobos at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/phobos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/9ac716aa/attachment.html>
April 22, 2011
On Fri, Apr 22, 2011 at 10:39 AM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

> Bug reports.  People having stupid arguments just like this one on why you should change how the code works to fit their style ;)
>
> Essentially, ambiguously named functions in the context of "I can call this as a property or a function" lead to people getting surprising behavior and then complaining about the surprise, when I can do nothing about it.
>
> I've actually had this happen.  I had to change function names in Tango in order to avoid people complaining.  The example was, I had a bunch of generator functions in TimeSpan, like
>
> // create a time spand that represents the given number of seconds
> static TimeSpan seconds(int s)
>
> which would be used like this:
>
> auto s = TimeSpan.seconds(5);
>
> But it could also be used as a property.  So this compiled and constructed a temporary time span and throw it away:
>
> TimeSpan s;
>
> s.seconds = 5;
>
> So we had to change seconds to fromSeconds.  It still allows code like this:
>
> s.fromSeconds = 5;
>
> but instead of being disallowed, it just looks horrible, hopefully cluing the reader to go examine the documentation for TimeSpan.  That's the best we can do.  I have no power to enforce the usage.
>
> -Steve
>
>
Nor should you.  People who are confused should RTFM.  BTW, what if you, as a library designer, *want* to express the notion that something can be called both ways?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/cf77c5e9/attachment.html>
April 22, 2011
The problem with RTFM is, they have a point.? s.seconds = 5 looks like it should work.? So that response looks like you don't care about usage.? D isn't a dynamic language.


If you *want* to express that a function can be called both ways, then we have to look into overloading properties and non-properties of the same name with the same arguments, or using an annotation.? But that's a separate enhancement.? We'd have to look at the merits of that separately, and I personally feel the ability to do that is not worth the trouble -- you can just as easily rename the function version, and it actually ends up reading clearer.? Yes, it's not always DRY, but DRY is never fully achievable, and is secondary to usage semantics IMO.


-Steve


>________________________________
>From: David Simcha <dsimcha at gmail.com>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Friday, April 22, 2011 10:42 AM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>
>
>
>On Fri, Apr 22, 2011 at 10:39 AM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>
>Bug reports.? People having stupid arguments just like this one on why you should change how the code works to fit their style ;)
>>
>>
>>Essentially, ambiguously named functions in the context of "I can call this as a property or a function" lead to people getting surprising behavior and then complaining about the surprise, when I can do nothing about it.
>>
>>
>>I've actually had this happen.? I had to change function names in Tango in order to avoid people complaining.? The example was, I had a bunch of generator functions in TimeSpan, like
>>
>>
>>// create a time spand that represents the given number of seconds
>>
>>static TimeSpan seconds(int s)
>>
>>
>>
>>which would be used like this:
>>
>>
>>auto s = TimeSpan.seconds(5);
>>
>>
>>But it could also be used as a property.? So this compiled and constructed a temporary time span and throw it away:
>>
>>
>>TimeSpan s;
>>
>>
>>s.seconds = 5;
>>
>>
>>So we had to change seconds to fromSeconds.? It still allows code like this:
>>
>>
>>s.fromSeconds = 5;
>>
>>
>>but instead of being disallowed, it just looks horrible, hopefully cluing the reader to go examine the documentation for TimeSpan.? That's the best we can do.? I have no power to enforce the usage.
>>
>>
>>
>>-Steve
>>
>>
>
>Nor should you.? People who are confused should RTFM.? BTW, what if you, as a library designer, want to express the notion that something can be called both ways?
>
>_______________________________________________
>phobos mailing list
>phobos at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/phobos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/7157bcbe/attachment-0001.html>
April 22, 2011
On Fri, Apr 22, 2011 at 11:05 AM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

> The problem with RTFM is, they have a point.  s.seconds = 5 looks like it should work.  So that response looks like you don't care about usage.  D isn't a dynamic language.
>

Right.  I'd rather a language be liberal and accept a few silly things than be conservative and reject a few reasonable things.  There will never be perfection with regard to this.


> If you *want* to express that a function can be called both ways, then we have to look into overloading properties and non-properties of the same name with the same arguments, or using an annotation.  But that's a separate enhancement.  We'd have to look at the merits of that separately, and I personally feel the ability to do that is not worth the trouble -- you can just as easily rename the function version, and it actually ends up reading clearer.  Yes, it's not always DRY, but DRY is never fully achievable, and is secondary to usage semantics IMO.
>

DRY is the whole point of using any language above ASM.  C prevents you from having to repeatedly specify calling conventions and stuff. C++ prevents you from having to repeatedly specify things like vtable layout, etc. etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/5a3aa006/attachment.html>
April 22, 2011
On Fri, 22 Apr 2011 10:39:02 -0400, Steve Schveighoffer <schveiguy at yahoo.com> wrote:

> Bug reports.  People having stupid arguments just like this one on why you should change how the code works to fit their style ;)
>
> Essentially, ambiguously named functions in the context of "I can call this as a property or a function" lead to people getting surprising behavior and then complaining about the surprise, when I can do nothing about it.
>
> I've actually had this happen.  I had to change function names in Tango in order to avoid people complaining.  The example was, I had a bunch of generator functions in TimeSpan, like
>
> // create a time spand that represents the given number of seconds
>
> static TimeSpan seconds(int s)
>
>
> which would be used like this:
>
> auto s = TimeSpan.seconds(5);
>
> But it could also be used as a property.  So this compiled and constructed a temporary time span and throw it away:
>
> TimeSpan s;
>
> s.seconds = 5;
>
> So we had to change seconds to fromSeconds.  It still allows code like this:
>
> s.fromSeconds = 5;
>
> but instead of being disallowed, it just looks horrible, hopefully cluing the reader to go examine the documentation for TimeSpan.  That's the best we can do.  I have no power to enforce the usage.

You know, the first thought I had when seeing this code was, "Why didn't you capitalize the name of your inner struct/class in the first place?". My second thought was, hmm..., I wonder if there would be a way to prevent accessing static members from instances? (There's a pretty serious loss of functionality bug regarding struct opCall being overloaded by ctors that's basically the same thing.) Third, came criticisms of naming a factory method 'seconds' in the first place (noun/verb distinctions, etc), and the associative criticisms of fixing a bad design via a proverbial sledgehammer. Forth, came the realization that in D2 'seconds' would probably be pure, which would cause s.seconds = 5 to be compiler error. Currently I'm pondering whether capitalized factory methods, in order to mimic ctor syntax, would be an acceptable design. I doubt anyone would every have tried s.Seconds = 5, and thanks to auto, I also doubt anyone would call TimeSpan.Seconds s. And unlike (an impure) s.seconds = 5, TimeSpan.Seconds s; simply doesn't compile. Plus, it self-documents the factory concept in the name.

Still, this feels like a valid point weakened by a poor (or at least debatable) example. You wouldn't have additional examples handy, would you? (links to bug reports, would be more than acceptable)
April 22, 2011


>________________________________
>From: Robert Jacques <sandford at jhu.edu>
>To: Steve Schveighoffer <schveiguy at yahoo.com>; Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Friday, April 22, 2011 12:09 PM
>Subject: Re: [phobos] Time to get ready for the next release
>
>On Fri, 22 Apr 2011 10:39:02 -0400, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>
>> Bug reports.? People having stupid arguments just like this one on why you should change how the code works to fit their style ;)
>> 
>> Essentially, ambiguously named functions in the context of "I can call this as a property or a function" lead to people getting surprising behavior and then complaining about the surprise, when I can do nothing about it.
>> 
>> I've actually had this happen.? I had to change function names in Tango in order to avoid people complaining.? The example was, I had a bunch of generator functions in TimeSpan, like
>> 
>> // create a time spand that represents the given number of seconds
>> 
>> static TimeSpan seconds(int s)
>> 
>> 
>> which would be used like this:
>> 
>> auto s = TimeSpan.seconds(5);
>> 
>> But it could also be used as a property.? So this compiled and constructed a temporary time span and throw it away:
>> 
>> TimeSpan s;
>> 
>> s.seconds = 5;
>> 
>> So we had to change seconds to fromSeconds.? It still allows code like this:
>> 
>> s.fromSeconds = 5;
>> 
>> but instead of being disallowed, it just looks horrible, hopefully cluing the reader to go examine the documentation for TimeSpan.? That's the best we can do.? I have no power to enforce the usage.
>
>You know, the first thought I had when seeing this code was, "Why didn't you capitalize the name of your inner struct/class in the first place?".

Obviously because it's not an inner struct :)? seconds is a factory method to create a time span from seconds.? It's akin to core.time's Duration:

dur!"seconds"(5)

> My second thought was, hmm..., I wonder if there would be a way to prevent accessing static members from instances? (There's a pretty serious loss of functionality bug regarding struct opCall being overloaded by ctors that's basically the same thing.)

This was also my wish to fix the problem originally, I kind of still don't like that static functions are not required to be called via the class/struct name (from outside the scope of course).


> Third, came criticisms of naming a factory method 'seconds' in the first place (noun/verb distinctions, etc), and the associative criticisms of fixing a bad design via a proverbial sledgehammer.

The goal was to have something short.? At the time, I was fighting for changing the time code in Tango, and one of the criticisms was that the factory method names were too long (don't remember what I originally had).? Code like Socket.select(5.0) was going to be replaced with Socket.select(TimeSpan.seconds(5)).? This was sort of a compromise.? Ironically, we had to change it to something more verbose because of this problem.


> Forth, came the realization that in D2 'seconds' would probably be pure, which would cause s.seconds = 5 to be compiler error.

No, it wouldn't be an error.? s.seconds(5) is exactly the same as TimeSpan.seconds(5), both would be callable as pure functions.? In other words, s isn't actually passed to the function, it's just used as a namespace.


> Currently I'm pondering whether capitalized factory methods, in order to mimic ctor syntax, would be an acceptable design. I doubt anyone would every have tried s.Seconds = 5, and thanks to auto, I also doubt anyone would call TimeSpan.Seconds s. And unlike (an impure) s.seconds = 5, TimeSpan.Seconds s; simply doesn't compile. Plus, it self-documents the factory concept in the name.

If you used C# regularly, where everything is capitalized, you might expect capitalized method names and properties.? But in any case, why is capitalization more of a distinguisher than parentheses or lack thereof?? Both are part of the name of the function.? It's a matter of taste, but the distinction between capitalization and D's current loose properties is that in the latter, the name is under the control of the *user*, not the author.


>Still, this feels like a valid point weakened by a poor (or at least debatable) example. You wouldn't have additional examples handy, would you? (links to bug reports, would be more than acceptable)


here is the bug report from Tango: http://www.dsource.org/projects/tango/ticket/1184 .? It's the only one that stands out in my memory as something I had to change because of a user complaint of usage.

So I don't have any personal experience with other examples.? Perhaps this is because I learned to be more explicit with method names?? I don't know.? Others may have better examples.


-Steve