[phobos] Time to get ready for the next release

[Steve Schveighoffer]

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>