www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Against deprecating aliases

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Another pull has been made right now which takes down more functions
and creates deprecated forwarding functions:
https://github.com/D-Programming-Language/phobos/pull/279

Honestly I don't understand the point of deprecating convenient
functions like that. It makes perfect sense to make a single toUTF(z)
template from an implementation point of view, but it doesn't make
sense to remove convenient toUTF8(z)/toUTF16(z) symbol names. Simple
aliases could be created that sit in Phobos.

Do the Phobos devs really expect people to use code like this:

    CopyFileW(std.utf.toUTFz!(const(wchar)*)(from),
std.utf.toUTFz!(const(wchar)*)(to), false)

instead of this?:

    CopyFileW(std.utf.toUTF16z(from), std.utf.toUTF16z(to), false)

I can understand that Mr. Verbosity likes to code like this, but I
certainly don't. Of course the answer to that is "write your own
aliases in your user code". Ok, but now I have to *manually* include
these aliases in all of my projects because I already rely on toUTF16z
being present:

    public alias toUTFz!(const(wchar)*, string)  toUTF16z;
    public alias toUTFz!(const(wchar)*, wstring) toUTF16z;
    public alias toUTFz!(const(wchar)*, dstring) toUTF16z;

Doing this in my projects and/or having to rewrite my build scripts is
a complete waste of my time. Deprecating convenient existing names
like toUTF16z, coupled with notices that don't even tell me which file
is importing the deprecated symbols is a cocktail of nonsense. Why
deprecate symbol names that users will inevitably introduce them in
their user-code again? The rule is: if it's widely used enough, it
should be in the standard library. An alias doesn't cost you a dime to
keep in the library.

Most of us D programmers work on *multiple* projects at once, and we
don't have any sophisticated tools like, say, Java devs do, so we have
to do almost everything manually when deprecation warnings kick in. I
really think we should keep aliases around which have an almost zero
maintenance cost in Phobos, while they have a huge cost for the
library *users* when they're removed.

I think we're only getting away with this because we have a small D
community. Take a look at QT, for example. They not only keep
source-level compatibility, but they also keep *binary-level*
compatibility between releases. OTOH we can't even have source-level
compatibility between releases..

TLDR: Don't make Phobos upgrades annoying.
Sep 28 2011
next sibling parent travert phare.normalesup.org (Christophe) writes:
Andrej Mitrovic , dans le message (digitalmars.D:145645), a écrit :

 Another pull has been made right now which takes down more functions
 and creates deprecated forwarding functions:
 https://github.com/D-Programming-Language/phobos/pull/279
 
 Honestly I don't understand the point of deprecating convenient
 functions like that. It makes perfect sense to make a single toUTF(z)
 template from an implementation point of view, but it doesn't make
 sense to remove convenient toUTF8(z)/toUTF16(z) symbol names. Simple
 aliases could be created that sit in Phobos.


I agree, as long as a function name don't pollute the namespace, there 
is no reason to remove it, especially when it is convenient.

I don't see what a function named toUTF8 could do except what it 
actually does, so why would you bother people using them ?

Deprecation should be used when there is a real cost to maintaining the 
function, or when the name was poorly chosen and could be reused for 
something else.

-- 
Christophe
Sep 29 2011
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wed, 28 Sep 2011 22:43:13 +0300, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 Do the Phobos devs really expect people to use code like this:

     CopyFileW(std.utf.toUTFz!(const(wchar)*)(from),
 std.utf.toUTFz!(const(wchar)*)(to), false)

 instead of this?:

     CopyFileW(std.utf.toUTF16z(from), std.utf.toUTF16z(to), false)


How about this?

     CopyFileW(std.utf.toUTFz!LPCWSTR(from), std.utf.toUTFz!LPCWSTR(to),  
false)

If there isn't already, support for this should be added to std.conv.to.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Sep 30 2011