On 09/05/2011 03:29 PM, Andrei Alexandrescu wrote:
On 9/5/11 8:38 AM, Timon Gehr wrote:
On 09/04/2011 05:46 AM, Andrei Alexandrescu wrote:
On 9/3/11 4:40 PM, Timon Gehr wrote:
On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote:
On 9/3/11 5:41 AM, Christophe wrote:
1. provide an alias void delegate(const(char)[]) Sink; This should
be in std.conv; or std.format;, because nobody wants to add it to
every single module and if there is a standard way to handle
it, no
maintenance programmer will be confused by alias.
it needs to go into object.di, because Object needs it.
Object could, in theory, just use delegate(const(char)[]). But I
agree
that putting it in object.di would be the cleanest solution.
I disagree. void delegate(const(char)[]) means something, whereas
Sink
is rather obscure.
Providing the alias in the library seems fine, but
providing it in the langage is too much IMO.
Even in the library "Sink" is too vague to be useful as a top-level
symbol.
Andrei
I am quite sure that useful is the same as short/too vague in this
case.
Are you suggesting not to add an alias at all?
There are vastly better names than Sink. TextSink, TextWriter,
StringWriter, StringSink (heh), StringStreamer, ...
Andrei
'string' is quite obscure/vague too, if you don't know what it is. The
'string' alias in object.di should probably be renamed to
TailImmutableDynamicCharArray. :o)
I strongly disagree. In many programming languages, "string" denotes the
default abstraction for text representation. "Sink" has nowhere near
that brand power.
Sure, but that was not a valid argument when the term was introduced.
BTW: http://www.google.com/search?channel=fs&q=string&um=1&tbm=isch
imho better = shorter, because that is the whole point of providing an
alias. 'Sink' stops being vague as soon as people know what it is. That
should be quite early.
Again I completely disagree with all these three statements, sorry.
Why would you want to have an alias if not to relieve people from
writing cumbersome boilerplate?
