www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - duck!

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I was talking to Walter about Kenji's adaptTo. We both think it's a very 
powerful enabler, but adaptTo is a bland name. After discussing a few 
marketing strategies, I proposed "duck". It's short, simple, and evokes 
"duck typing".

class C
{
     int draw(){ return 10; }
}
interface Drawable
{
     long draw();
}
...
auto c = new C;
auto d = duck!Drawable(c); // awes

Kenji, I'll be looking forward to your submission :o). Would be great to 
allow structs to duck, too!


Andrei
Oct 15 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i9ae2n$k9g$1 digitalmars.com...

I was talking to Walter about Kenji's adaptTo. We both think it's a very 
powerful enabler, but adaptTo is a bland name. After discussing a few 
marketing strategies, I proposed "duck". It's short, simple, and evokes 
"duck typing".

 class C
 {
     int draw(){ return 10; }
 }
 interface Drawable
 {
     long draw();
 }
 ...
 auto c = new C;
 auto d = duck!Drawable(c); // awes

 Kenji, I'll be looking forward to your submission :o). Would be great to 
 allow structs to duck, too!


Now that's one breed of duck I *can* get behind. Provides the duck benefits, 
but without accidentally conflating naming with semantics everywhere like 
the Ruby/Python ducks or even like Go's "spaghetti door" ducks ( 
http://www.reddit.com/r/programming/comments/dr6r4/talk_by_rob_pike_the_expressivene
s_of_go_pdf/c12bi4h ) 
. Cool stuff.
Oct 15 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/15/10 15:46 CDT, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i9ae2n$k9g$1 digitalmars.com...

 I was talking to Walter about Kenji's adaptTo. We both think it's a very
 powerful enabler, but adaptTo is a bland name. After discussing a few
 marketing strategies, I proposed "duck". It's short, simple, and evokes
 "duck typing".

 class C
 {
      int draw(){ return 10; }
 }
 interface Drawable
 {
      long draw();
 }
 ...
 auto c = new C;
 auto d = duck!Drawable(c); // awes

 Kenji, I'll be looking forward to your submission :o). Would be great to
 allow structs to duck, too!


 Now that's one breed of duck I *can* get behind. Provides the duck benefits,
 but without accidentally conflating naming with semantics everywhere like
 the Ruby/Python ducks or even like Go's "spaghetti door" ducks (
 http://www.reddit.com/r/programming/comments/dr6r4/talk_by_rob_pike_the_expressivene
s_of_go_pdf/c12bi4h )
 . Cool stuff.


My opinion: when properly generalized, duck will eat Go's lunch. You 
didn't hear it from me.

Andrei
Oct 15 2010
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
So what exactly does adaptTO/duck! do? For those not in the know-how..? :)

On 10/15/10, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 On 10/15/10 15:46 CDT, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i9ae2n$k9g$1 digitalmars.com...

 I was talking to Walter about Kenji's adaptTo. We both think it's a very
 powerful enabler, but adaptTo is a bland name. After discussing a few
 marketing strategies, I proposed "duck". It's short, simple, and evokes
 "duck typing".

 class C
 {
      int draw(){ return 10; }
 }
 interface Drawable
 {
      long draw();
 }
 ...
 auto c = new C;
 auto d = duck!Drawable(c); // awes

 Kenji, I'll be looking forward to your submission :o). Would be great to
 allow structs to duck, too!


 Now that's one breed of duck I *can* get behind. Provides the duck
 benefits,
 but without accidentally conflating naming with semantics everywhere like
 the Ruby/Python ducks or even like Go's "spaghetti door" ducks (
 http://www.reddit.com/r/programming/comments/dr6r4/talk_by_rob_pike_the_expressiveness_of_go_pdf/c12bi4h
 )
 . Cool stuff.


 My opinion: when properly generalized, duck will eat Go's lunch. You
 didn't hear it from me.

 Andrei
Oct 15 2010
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:


 I was talking to Walter about Kenji's adaptTo. We both think it's a very 
 powerful enabler, but adaptTo is a bland name. After discussing a few 
 marketing strategies, I proposed "duck". It's short, simple, and evokes 
 "duck typing".


1. adaptTo helped me to understand what it does, while duck!Drawable doesn't.
2. I don't think it's duck typing, I'm affraid "duck" name is misleading.
Oct 15 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/15/10 16:16 CDT, Kagamin wrote:

 Andrei Alexandrescu Wrote:


 I was talking to Walter about Kenji's adaptTo. We both think it's a very
 powerful enabler, but adaptTo is a bland name. After discussing a few
 marketing strategies, I proposed "duck". It's short, simple, and evokes
 "duck typing".


 1. adaptTo helped me to understand what it does, while duck!Drawable doesn't.
 2. I don't think it's duck typing, I'm affraid "duck" name is misleading.


It's duck typing all right. Membership to the target interface is 
assessed based on the existence of that interface's methods. If the 
object "quacks" like the interface, it belongs to the interface.

Andrei
Oct 15 2010
parent Justin Johansson <no spam.com> writes:
On 16/10/2010 9:33 AM, Andrei Alexandrescu wrote:

 On 10/15/10 16:16 CDT, Kagamin wrote:

 Andrei Alexandrescu Wrote:


 I was talking to Walter about Kenji's adaptTo. We both think it's a very
 powerful enabler, but adaptTo is a bland name. After discussing a few
 marketing strategies, I proposed "duck". It's short, simple, and evokes
 "duck typing".


 1. adaptTo helped me to understand what it does, while duck!Drawable
 doesn't.
 2. I don't think it's duck typing, I'm affraid "duck" name is misleading.


 It's duck typing all right. Membership to the target interface is
 assessed based on the existence of that interface's methods. If the
 object "quacks" like the interface, it belongs to the interface.

 Andrei


Since this is the D implementation of duck typing, how about
DDuck!

Walt :-)
Oct 15 2010
prev sibling next sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Kagamin, el 15 de octubre a las 17:16 me escribiste:

 Andrei Alexandrescu Wrote:
 

 I was talking to Walter about Kenji's adaptTo. We both think it's a very 
 powerful enabler, but adaptTo is a bland name. After discussing a few 
 marketing strategies, I proposed "duck". It's short, simple, and evokes 
 "duck typing".


 
 1. adaptTo helped me to understand what it does, while duck!Drawable doesn't.


I agree, just "adapt" might be an option, it even has a precedence of
something similar in Python (even when the PEP[1] was rejected, PEAK has
an implementation[2]). But "duck" is really cryptic (as symbol names
invented by Andrei usually are :).

[1] http://www.python.org/dev/peps/pep-0246/
[2] http://peak.telecommunity.com/protocol_ref/module-protocols.html

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Sus discipulos se miraron sin entended hasta que uno preguntose:
Peperino, soy Daniel Q. de Olivos tengo 54 años y aún soy virgen. A lo
que Peperino respondiole: Si sos ganso, ganso ser. Y lo frotó, y lo
curó y lo sanó. A lo que todos dijeron: ­¡¡¡Peperino se la come,
Peperino se la come!!!
	-- Peperino Pómoro
Oct 15 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 15 October 2010 23:35:35 Leandro Lucarella wrote:

 Kagamin, el 15 de octubre a las 17:16 me escribiste:

 Andrei Alexandrescu Wrote:

 I was talking to Walter about Kenji's adaptTo. We both think it's a
 very powerful enabler, but adaptTo is a bland name. After discussing a
 few marketing strategies, I proposed "duck". It's short, simple, and
 evokes "duck typing".


 
 1. adaptTo helped me to understand what it does, while duck!Drawable
 doesn't.


 
 I agree, just "adapt" might be an option, it even has a precedence of
 something similar in Python (even when the PEP[1] was rejected, PEAK has
 an implementation[2]). But "duck" is really cryptic (as symbol names
 invented by Andrei usually are :).
 
 [1] http://www.python.org/dev/peps/pep-0246/
 [2] http://peak.telecommunity.com/protocol_ref/module-protocols.html


Considering that no one has presented a term which makes it immediately obvious 
what the function does and that the programmer is going to have to look it up 
regardless, I find duck to be a far better name since you're not going to
mistake 
it for anything else. Adapt can and will be used it far more contexts that duck 
ever would be. duck is therefore more immediately recognizable and will not be 
ambiguous to the programmer. Sure, they're going to have to look it up, but 
they're going to have to look it up regardless of the name, so I think that the 
shorter and more memorable is a better name.

- Jonathan M Davis
Oct 16 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/16/10 2:21 CDT, Jonathan M Davis wrote:

 On Friday 15 October 2010 23:35:35 Leandro Lucarella wrote:

 Kagamin, el 15 de octubre a las 17:16 me escribiste:

 Andrei Alexandrescu Wrote:

 I was talking to Walter about Kenji's adaptTo. We both think it's a
 very powerful enabler, but adaptTo is a bland name. After discussing a
 few marketing strategies, I proposed "duck". It's short, simple, and
 evokes "duck typing".


 1. adaptTo helped me to understand what it does, while duck!Drawable
 doesn't.


 I agree, just "adapt" might be an option, it even has a precedence of
 something similar in Python (even when the PEP[1] was rejected, PEAK has
 an implementation[2]). But "duck" is really cryptic (as symbol names
 invented by Andrei usually are :).

 [1] http://www.python.org/dev/peps/pep-0246/
 [2] http://peak.telecommunity.com/protocol_ref/module-protocols.html


 Considering that no one has presented a term which makes it immediately obvious
 what the function does and that the programmer is going to have to look it up
 regardless, I find duck to be a far better name since you're not going to
mistake
 it for anything else. Adapt can and will be used it far more contexts that duck
 ever would be. duck is therefore more immediately recognizable and will not be
 ambiguous to the programmer. Sure, they're going to have to look it up, but
 they're going to have to look it up regardless of the name, so I think that the
 shorter and more memorable is a better name.


Besides, it's good marketing. It's one thing to say, "hey, D has this 
function called adaptTo that pretty much does duck typing" and a 
different one to say, "gee, D has duck to enact duck typing!"

Andrei
Oct 16 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/16/10 1:35 CDT, Leandro Lucarella wrote:

 Kagamin, el 15 de octubre a las 17:16 me escribiste:

 Andrei Alexandrescu Wrote:


 I was talking to Walter about Kenji's adaptTo. We both think it's a very
 powerful enabler, but adaptTo is a bland name. After discussing a few
 marketing strategies, I proposed "duck". It's short, simple, and evokes
 "duck typing".


 1. adaptTo helped me to understand what it does, while duck!Drawable doesn't.


 I agree, just "adapt" might be an option, it even has a precedence of
 something similar in Python (even when the PEP[1] was rejected, PEAK has
 an implementation[2]). But "duck" is really cryptic (as symbol names
 invented by Andrei usually are :).


Walter recognized it instantly, as I think most should. Isn't "duck 
typing" really spread out there?

Andrei
Oct 16 2010
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-10-16 09:54:50 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 Walter recognized it instantly, as I think most should. Isn't "duck 
 typing" really spread out there?


"duck" is a misnomer.

First, it's dubious whether this "duck" function implements what most 
people understand by "duck typing".

Wikipedia says "In duck typing, one is concerned with just those 
aspects of an object that are used, rather than with the type of the 
object itself. [...] If the object does not have the methods that are 
called then the function signals a run-time error." Your "duck" 
function isn't concerned about the aspects of an object that are used, 
it's concerned by the aspects of an objects that can implement a 
certain interface type. Duck typing is much more synonymous to dynamic 
dispatch, where errors are reported at runtime, than to the adaptor 
pattern. The two concepts are not totally unrelated, but they're not 
the same thing either.

Second, you meant "duck" as a noun, but "duck!" looks like a verb to me 
for two reasons: because of the exclamation mark and because it's a 
function. I fear that in the absence of prior knowledge of that 
function it gets understood as:

	duck (verb)
	- lower the head or the body quickly to avoid a blow

making sense only if you're writing some sort of game. Since we're 
looking for a verb, why not "quack!". :-)

"as!" doesn't have the verb ambiguity problem nor the terminology 
problem, and it's basically a continuation of the "to!" scheme. 
Personally, I'd go for "as!". But I'd prefer even "adaptTo!" or 
"adapt!" rather than "duck!".

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 16 2010
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Andrei Alexandrescu, el 16 de octubre a las 08:54 me escribiste:

 On 10/16/10 1:35 CDT, Leandro Lucarella wrote:

Kagamin, el 15 de octubre a las 17:16 me escribiste:

Andrei Alexandrescu Wrote:


I was talking to Walter about Kenji's adaptTo. We both think it's a very
powerful enabler, but adaptTo is a bland name. After discussing a few
marketing strategies, I proposed "duck". It's short, simple, and evokes
"duck typing".


1. adaptTo helped me to understand what it does, while duck!Drawable doesn't.


I agree, just "adapt" might be an option, it even has a precedence of
something similar in Python (even when the PEP[1] was rejected, PEAK has
an implementation[2]). But "duck" is really cryptic (as symbol names
invented by Andrei usually are :).


 
 Walter recognized it instantly, as I think most should. Isn't "duck
 typing" really spread out there?


Walter and you have the same convoluted brain, I can understand why he
instantly recognize it ;)

I already made my point, it make no sense to keep defending my position
since, evidently, is a pure subjective matter.

I just think auto a_bird = duck!Bird(a_duck) is not obvious at all
compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is
even cleaner, and I tend to hate long names, specially when camelCase is
involved, but since you didn't like it I, as others, suggested simply
adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would
be as clear as adaptTo is with the current syntax. With adaptTo!Type you
even have the precedent of the to!Type template, so it seems like a nice
extension.

F*ck, I finally kept defending my position...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si ella es la flor, yo soy la espina
Si ella es quien florece, yo quien se marchita
Y estamos en eclipse total, y estamos en eclipse total
Completamente cruzados, completamente cruzados
Oct 16 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Leandro Lucarella wrote:

 Walter and you have the same convoluted brain, I can understand why he
 instantly recognize it ;)





 I already made my point, it make no sense to keep defending my position
 since, evidently, is a pure subjective matter.


It certainly is a glorious bikeshed.


 I just think auto a_bird = duck!Bird(a_duck) is not obvious at all
 compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is
 even cleaner, and I tend to hate long names, specially when camelCase is
 involved, but since you didn't like it I, as others, suggested simply
 adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would
 be as clear as adaptTo is with the current syntax. With adaptTo!Type you
 even have the precedent of the to!Type template, so it seems like a nice
 extension.


Microsoft has a tradition of naming their products after what they do: Windows, 
Word, Office, etc. It's obvious why they do it, and it works, but it is just so 
generic and dull.

Being the upstart language, D needs now and then something a little more 
attention-getting than generic terms. The "duck" feature is important for two 
reasons:

1. duck typing is all the rage now

2. being able to implement duck typing as a library feature (rather than a 
language one) is a great demonstration of what D can do

Label it "adaptTo" and few will even notice it. Label it "duck" and people will 
click on the link to see what it does. It's important that people notice that D 
has these things, and "duck" helps with that.

I've been in this business a long time, and while you'd think that programmers 
are above "what's in a name", we are just like everyone else. A catchy name
gets 
results. Borland, for example, added a trivial and boring feature to their 
linker, called it "smart linking", and managed to get an unbelievable amount of 
hoopla from the computer press out of it. They did it again with another
feature 
they called "zoom".

Which blog article would you click on? "Interface Adapter for D" or "Duck
Typing 
for D"?

"duck" is a great name for the feature. It's short & sweet, fits right in with 
the popularity of duck typing, stands out, isn't boring, etc. Heck, as proof, 
look at all the interest in this thread!!
Oct 16 2010
next sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 10/16/2010 09:16 PM, Walter Bright wrote:

 Leandro Lucarella wrote:

 Walter and you have the same convoluted brain, I can understand why he
 instantly recognize it ;)





 I already made my point, it make no sense to keep defending my position
 since, evidently, is a pure subjective matter.


 It certainly is a glorious bikeshed.


 I just think auto a_bird = duck!Bird(a_duck) is not obvious at all
 compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is
 even cleaner, and I tend to hate long names, specially when camelCase is
 involved, but since you didn't like it I, as others, suggested simply
 adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would
 be as clear as adaptTo is with the current syntax. With adaptTo!Type you
 even have the precedent of the to!Type template, so it seems like a nice
 extension.


 Microsoft has a tradition of naming their products after what they do:
 Windows, Word, Office, etc. It's obvious why they do it, and it works,
 but it is just so generic and dull.

 Being the upstart language, D needs now and then something a little more
 attention-getting than generic terms. The "duck" feature is important
 for two reasons:

 1. duck typing is all the rage now

 2. being able to implement duck typing as a library feature (rather than
 a language one) is a great demonstration of what D can do

 Label it "adaptTo" and few will even notice it. Label it "duck" and
 people will click on the link to see what it does. It's important that
 people notice that D has these things, and "duck" helps with that.


I think that is a wrong approach to marketing. Even microsoft avoids 
giving fancy names to API functions. It is ok to give a fancy name to an 
API (Windows Presentation Foundation, etc) or a product but the mundane 
function names should be as boring and factual as they deserve it. It is 
poor programmers and not marketing folks who will be using them.

As other people said, there are better ways of marketing D. For example, 
you may want to hire a professional web designer to make D's web site 
look less amateurish.
Oct 16 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Max Samukha wrote:

 I think that is a wrong approach to marketing. Even microsoft avoids 
 giving fancy names to API functions. It is ok to give a fancy name to an 
 API (Windows Presentation Foundation, etc) or a product but the mundane 
 function names should be as boring and factual as they deserve it. It is 
 poor programmers and not marketing folks who will be using them.


If it's a cringeworthy name, I'd agree. But "duck" is not cringeworthy.



 As other people said, there are better ways of marketing D. For example, 
 you may want to hire a professional web designer to make D's web site 
 look less amateurish.


We're doing that, too.
Oct 16 2010
parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 10/16/2010 14:02, Walter Bright wrote:

 If it's a cringeworthy name, I'd agree. But "duck" is not cringeworthy.


Fact: I cringe every time I hear "duck typing".


-- 
Rainer Deyke - rainerd eldwood.com
Oct 16 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/16/2010 03:58 PM, Rainer Deyke wrote:

 On 10/16/2010 14:02, Walter Bright wrote:

 If it's a cringeworthy name, I'd agree. But "duck" is not cringeworthy.


 Fact: I cringe every time I hear "duck typing".


Me too, for a long time. Then I had to get used to it because most 
everybody was using it.

Andrei
Oct 16 2010
prev sibling next sibling parent so <so so.do> writes:
As "as" looks sweet, you have rather compelling points, "duck" sure grabs  
too much attention.

On Sat, 16 Oct 2010 21:16:08 +0300, Walter Bright  
<newshound2 digitalmars.com> wrote:


 Leandro Lucarella wrote:

 Walter and you have the same convoluted brain, I can understand why he
 instantly recognize it ;)





 I already made my point, it make no sense to keep defending my position
 since, evidently, is a pure subjective matter.


 It certainly is a glorious bikeshed.


 I just think auto a_bird = duck!Bird(a_duck) is not obvious at all
 compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is
 even cleaner, and I tend to hate long names, specially when camelCase is
 involved, but since you didn't like it I, as others, suggested simply
 adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would
 be as clear as adaptTo is with the current syntax. With adaptTo!Type you
 even have the precedent of the to!Type template, so it seems like a nice
 extension.


 Microsoft has a tradition of naming their products after what they do:  
 Windows, Word, Office, etc. It's obvious why they do it, and it works,  
 but it is just so generic and dull.

 Being the upstart language, D needs now and then something a little more  
 attention-getting than generic terms. The "duck" feature is important  
 for two reasons:

 1. duck typing is all the rage now

 2. being able to implement duck typing as a library feature (rather than  
 a language one) is a great demonstration of what D can do

 Label it "adaptTo" and few will even notice it. Label it "duck" and  
 people will click on the link to see what it does. It's important that  
 people notice that D has these things, and "duck" helps with that.

 I've been in this business a long time, and while you'd think that  
 programmers are above "what's in a name", we are just like everyone  
 else. A catchy name gets results. Borland, for example, added a trivial  
 and boring feature to their linker, called it "smart linking", and  
 managed to get an unbelievable amount of hoopla from the computer press  
 out of it. They did it again with another feature they called "zoom".

 Which blog article would you click on? "Interface Adapter for D" or  
 "Duck Typing for D"?

 "duck" is a great name for the feature. It's short & sweet, fits right  
 in with the popularity of duck typing, stands out, isn't boring, etc.  
 Heck, as proof, look at all the interest in this thread!!



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 16 2010
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Walter Bright Wrote:


 Which blog article would you click on? "Interface Adapter for D" or "Duck
Typing 
 for D"?
 


You are somewhat right. The right place for marketing is an article, not the
library source, right? What would you click on? "Duck typing for D" or
dsource.org/phobos/src/trunk?
Oct 16 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Kagamin wrote:

 Walter Bright Wrote:
 

 Which blog article would you click on? "Interface Adapter for D" or "Duck
 Typing for D"?
 


 You are somewhat right. The right place for marketing is an article, not the
 library source, right?


They're both important. Especially consider that Phobos is open source, is on 
the internet just a click away, and the words used in it are indexed by Google.



 What would you click on? "Duck typing for D" or
 dsource.org/phobos/src/trunk?


If I'm looking at a list of modules for Phobos, and I see "std.duck" as a 
clickable link, I'll click on it.

If I google for "adapt for D" I'll get a hopeless mess of irrelevant links. 
"duck typing for D" should be much better. Remember that google ranks pages by 
relevance, and searching for "duck" will give higher ranking for pages with 
"duck" in the url, title, headings, etc. That's just what we want.
Oct 16 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 16 Oct 2010 16:31:34 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 If I google for "adapt for D" I'll get a hopeless mess of irrelevant  
 links. "duck typing for D" should be much better. Remember that google  
 ranks pages by relevance, and searching for "duck" will give higher  
 ranking for pages with "duck" in the url, title, headings, etc. That's  
 just what we want.


And it should come up with the page on digitalmars.com titled 'duck typing  
in D' which describes how to use templates or the adaptTo type to achieve  
duck typing.

-Steve
Oct 16 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:

 On Sat, 16 Oct 2010 16:31:34 -0400, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 

 If I google for "adapt for D" I'll get a hopeless mess of irrelevant 
 links. "duck typing for D" should be much better. Remember that google 
 ranks pages by relevance, and searching for "duck" will give higher 
 ranking for pages with "duck" in the url, title, headings, etc. That's 
 just what we want.


 
 And it should come up with the page on digitalmars.com titled 'duck 
 typing in D' which describes how to use templates or the adaptTo type to 
 achieve duck typing.



When writing fiction, it's a good idea to constantly shift which words used to 
describe something. But when writing tech manuals, and when making things
search 
engine friendly, it pays to use a single term and use it consistently.

For example, once upon a time I read some article on arrays, and it variously 
referred to the array "elements", "entries", and "values". Really, that sucked, 
as the reader was left being not quite sure if they meant the same thing or not.

If you expect people to search for "duck typing" (and I do) then why stick 
another level of indirection? Call it a "duck". When you find yourself 
constantly saying "duck typing: see adaptTo", then you named it wrong.
Oct 16 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 16 Oct 2010 18:04:23 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 Steven Schveighoffer wrote:

 On Sat, 16 Oct 2010 16:31:34 -0400, Walter Bright  
 <newshound2 digitalmars.com> wrote:


 If I google for "adapt for D" I'll get a hopeless mess of irrelevant  
 links. "duck typing for D" should be much better. Remember that google  
 ranks pages by relevance, and searching for "duck" will give higher  
 ranking for pages with "duck" in the url, title, headings, etc. That's  
 just what we want.


  And it should come up with the page on digitalmars.com titled 'duck  
 typing in D' which describes how to use templates or the adaptTo type  
 to achieve duck typing.



 When writing fiction, it's a good idea to constantly shift which words  
 used to describe something. But when writing tech manuals, and when  
 making things search engine friendly, it pays to use a single term and  
 use it consistently.

 For example, once upon a time I read some article on arrays, and it  
 variously referred to the array "elements", "entries", and "values".  
 Really, that sucked, as the reader was left being not quite sure if they  
 meant the same thing or not.

 If you expect people to search for "duck typing" (and I do) then why  
 stick another level of indirection? Call it a "duck". When you find  
 yourself constantly saying "duck typing: see adaptTo", then you named it  
 wrong.


Is this a case of foresight is 20/20?  Look, you can't predict the future,  
and knowing what you will constantly be saying isn't possible.  You could  
constantly be saying 'yeah, I know duck isn't the only way to do duck  
typing in D, but we felt it was a good descriptive name.'  And not having  
to constantly say anything isn't proof that you have preemptively avoided  
it.

But it doesn't matter anyways.  My point is, marketing has nothing to do  
with naming functions.  People will not decide to use or not use a  
language based on a function name.  If the name describes the function  
properly, then it will not be noticed as a defect, and few will have  
problems with it.  All three suggestions (adaptTo, as, and duck) satisfy  
this IMO, so really this argument has nothing to do with the name.  It's  
all about the incorrect belief that the name itself will somehow be seen  
as a marketing benefit.

You're making a lake out of a duck pond ;)

-Steve
Oct 18 2010
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
'Duck Typing' is a very broad concept.
adaptTo is supported only in part.

For example, you can not adapt class from class.
It has semantic problem of object states, so I never support it.
----
// this is invalid example
class C{ draw(){ return 10; } }
class X{ draw(){ return value; } int value; }
X x = adaptTo!X(new C());
// x.value == ??, cannot provide generally.
----

If you call it a duck, it will tell a lie!

Kenji Hara.

2010/10/17 Walter Bright <newshound2 digitalmars.com>:

 Leandro Lucarella wrote:

 Walter and you have the same convoluted brain, I can understand why he
 instantly recognize it ;)





 I already made my point, it make no sense to keep defending my position
 since, evidently, is a pure subjective matter.


 It certainly is a glorious bikeshed.


 I just think auto a_bird = duck!Bird(a_duck) is not obvious at all
 compared to auto a_bird = adapt!Bird(a_duck). I even think adaptTo is
 even cleaner, and I tend to hate long names, specially when camelCase is
 involved, but since you didn't like it I, as others, suggested simply
 adapt). If one could write auto a_bird = adapt!a_duck(Bird), adapt would
 be as clear as adaptTo is with the current syntax. With adaptTo!Type you
 even have the precedent of the to!Type template, so it seems like a nice
 extension.


 Microsoft has a tradition of naming their products after what they do:
 Windows, Word, Office, etc. It's obvious why they do it, and it works, but
 it is just so generic and dull.

 Being the upstart language, D needs now and then something a little more
 attention-getting than generic terms. The "duck" feature is important for
 two reasons:

 1. duck typing is all the rage now

 2. being able to implement duck typing as a library feature (rather than a
 language one) is a great demonstration of what D can do

 Label it "adaptTo" and few will even notice it. Label it "duck" and people
 will click on the link to see what it does. It's important that people
 notice that D has these things, and "duck" helps with that.

 I've been in this business a long time, and while you'd think that
 programmers are above "what's in a name", we are just like everyone else. A
 catchy name gets results. Borland, for example, added a trivial and boring
 feature to their linker, called it "smart linking", and managed to get an
 unbelievable amount of hoopla from the computer press out of it. They did it
 again with another feature they called "zoom".

 Which blog article would you click on? "Interface Adapter for D" or "Duck
 Typing for D"?

 "duck" is a great name for the feature. It's short & sweet, fits right in
 with the popularity of duck typing, stands out, isn't boring, etc. Heck, as
 proof, look at all the interest in this thread!!
Oct 16 2010
prev sibling next sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Walter Bright, el 16 de octubre a las 11:16 me escribiste:

 Label it "adaptTo" and few will even notice it. Label it "duck" and
 people will click on the link to see what it does. It's important
 that people notice that D has these things, and "duck" helps with
 that.


Well, maybe I'm not people, but I wouldn't click on anything named duck.
And if you ask me, marketing is OK for a name product, but not for
writing source code. You are putting marketing in the wrong place.

I would hate to have to write meaningless code like:

auto wow = buzz!Word(cool);


 I've been in this business a long time, and while you'd think that
 programmers are above "what's in a name", we are just like everyone
 else. A catchy name gets results. Borland, for example, added a
 trivial and boring feature to their linker, called it "smart
 linking", and managed to get an unbelievable amount of hoopla from
 the computer press out of it. They did it again with another feature
 they called "zoom".


You are underestimating people, if your targets are morons, that's the
kind of people you'll get in the community.


 Which blog article would you click on? "Interface Adapter for D" or
 "Duck Typing for D"?


Probably "Duck typing for D", but why can't you name the function
"adapt", "adaptTo" or "as" and the article "Duck typing for D"???
The article is the right place to do marketing and use cool names to get
the attention, NOT THE CODE.


 "duck" is a great name for the feature. It's short & sweet, fits
 right in with the popularity of duck typing, stands out, isn't
 boring, etc. Heck, as proof, look at all the interest in this
 thread!!


What you're saying now is just plain stupid:

1. A long thread generally indicated the presence of something
   controversial, not something good and accepted (those threads are
   usually short, or filled with just "+1").
2. You can just post "hi" in this NG and get a thread of thousands of
   messages ;)

I hate myself, I just keep replying when I know this matter is closed,
if both you and Andrei like something, is a dead end for any
alternatives...

Well, at least I will be able to say "I tried"...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
"All mail clients suck. This one just sucks less." -me, circa 1995
Oct 16 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/16/2010 05:18 PM, Leandro Lucarella wrote:

 Walter Bright, el 16 de octubre a las 11:16 me escribiste:

 Label it "adaptTo" and few will even notice it. Label it "duck" and
 people will click on the link to see what it does. It's important
 that people notice that D has these things, and "duck" helps with
 that.


 Well, maybe I'm not people, but I wouldn't click on anything named duck.
 And if you ask me, marketing is OK for a name product, but not for
 writing source code. You are putting marketing in the wrong place.

 I would hate to have to write meaningless code like:

 auto wow = buzz!Word(cool);


 I've been in this business a long time, and while you'd think that
 programmers are above "what's in a name", we are just like everyone
 else. A catchy name gets results. Borland, for example, added a
 trivial and boring feature to their linker, called it "smart
 linking", and managed to get an unbelievable amount of hoopla from
 the computer press out of it. They did it again with another feature
 they called "zoom".


 You are underestimating people, if your targets are morons, that's the
 kind of people you'll get in the community.


 Which blog article would you click on? "Interface Adapter for D" or
 "Duck Typing for D"?


 Probably "Duck typing for D", but why can't you name the function
 "adapt", "adaptTo" or "as" and the article "Duck typing for D"???
 The article is the right place to do marketing and use cool names to get
 the attention, NOT THE CODE.


 "duck" is a great name for the feature. It's short&  sweet, fits
 right in with the popularity of duck typing, stands out, isn't
 boring, etc. Heck, as proof, look at all the interest in this
 thread!!


 What you're saying now is just plain stupid:

 1. A long thread generally indicated the presence of something
     controversial, not something good and accepted (those threads are
     usually short, or filled with just "+1").
 2. You can just post "hi" in this NG and get a thread of thousands of
     messages ;)

 I hate myself, I just keep replying when I know this matter is closed,
 if both you and Andrei like something, is a dead end for any
 alternatives...

 Well, at least I will be able to say "I tried"...


How about this: we call "adapt" the strict adaptation of one interface 
to another and "ducktype" the loose adaptation that might fail 
dynamically. Would that float your boat?

Andrei
Oct 16 2010
parent Leandro Lucarella <luca llucax.com.ar> writes:
Andrei Alexandrescu, el 16 de octubre a las 19:19 me escribiste:

I hate myself, I just keep replying when I know this matter is closed,
if both you and Andrei like something, is a dead end for any
alternatives...

Well, at least I will be able to say "I tried"...


 
 How about this: we call "adapt" the strict adaptation of one
 interface to another and "ducktype" the loose adaptation that might
 fail dynamically. Would that float your boat?


I don't find it ideal, but it's definitely better.

What I don't get is what the purpose/use of "ducktype" in D. And why do
you even have to pass a type to ducktype? If you aren't certain if the
object implements a function or not, that's not really duck-typing
either, that's just dynamic typing and in that case, why do you even
bother to specify an interface?

I really don't see a point to it...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
at ease, eating well (no more microwave dinners and saturated fats),
a patient better driver, a safer car (baby smiling in back seat),
sleeping well (no bad dreams), no paranoia,
Oct 16 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 16/10/2010 19:16, Walter Bright wrote:

 Being the upstart language, D needs now and then something a little more
 attention-getting than generic terms. The "duck" feature is important
 for two reasons:

 1. duck typing is all the rage now


What??... :o
I think this is very much a wrong perception! Sure, there has been a lot 
of articles, publicity and buzz surrounding duck typing in the past few 
years, but that doesn't meant it's "all the rage". More concretely, it 
doesn't mean that duck typing is popular, either now, or heading that 
way in the future. I think dynamic languages are somewhat of a niche 
(even if a growing one), but not really heading to be mainstream in 
medium/large scale projects.
Rather I think that the duck typing fanboys are just very vocal about 
it. (Kinda like the Tea Party movement... )



BTW, just as a clarifying side note, duck typing is nothing new in terms 
of language features. Duck typing is just dynamic typing as combined 
with Object Oriented. What is new about duck typing is not so much in 
the language, but rather the development philosophy that states:
  * dynamic typing with OO is an equally valid approach (if not better) 
than traditional static typing OO, for thinking about objects and their 
behavior,
  * documentation, clear code, and testing are good enough to ensure 
correct usage (especially testing, in some circles).

Note: I'm not implying I agree with the above, I'm just paraphrasing.

-- 
Bruno Medeiros - Software Engineer
Nov 11 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 11/11/2010 14:19, Bruno Medeiros wrote:

 way in the future. I think dynamic languages are somewhat of a niche
 (even if a growing one), but not really heading to be mainstream in
 medium/large scale projects.


Sorry, I actually meant "I think dynamic _typing_ is somewhat of a 
niche" rather than the above. Yes, the two are closely related, but they 
are not the same.
For example, I wouldn't be surprised if in the future certain 
dynamically-typed languages gain some static-typing capabilities. (like 
the inverse is happening)

-- 
Bruno Medeiros - Software Engineer
Nov 11 2010
next sibling parent Andrew Wiley <debio264 gmail.com> writes:
On Thu, Nov 11, 2010 at 10:01 AM, Bruno Medeiros
<brunodomedeiros+spam com.gmail> wrote:


 On 11/11/2010 14:19, Bruno Medeiros wrote:


 way in the future. I think dynamic languages are somewhat of a niche
 (even if a growing one), but not really heading to be mainstream in
 medium/large scale projects.


 Sorry, I actually meant "I think dynamic _typing_ is somewhat of a niche"
 rather than the above. Yes, the two are closely related, but they are not
 the same.
 For example, I wouldn't be surprised if in the future certain
 dynamically-typed languages gain some static-typing capabilities. (like the
 inverse is happening)


From reading about this, it seems like what D has is very similar to what


Scala calls "Structural Typing" (see
http://codemonkeyism.com/scala-goodness-structural-typing/). The difference
is that Scala tends to use structural typing with inline type declarations
(although they don't have to be inline). However, the basic concept is the
same, where a class is dynamically checked for compliance with a static
type. Not quite dynamic typing, but definitely related.
If you're after a more accurate description, how would that work?

Andrew Wiley
Nov 11 2010
prev sibling parent Andrew Wiley <debio264 gmail.com> writes:
On Thu, Nov 11, 2010 at 11:25 AM, Andrew Wiley <debio264 gmail.com> wrote:


 On Thu, Nov 11, 2010 at 10:01 AM, Bruno Medeiros
 <brunodomedeiros+spam com.gmail> wrote:


 On 11/11/2010 14:19, Bruno Medeiros wrote:


 way in the future. I think dynamic languages are somewhat of a niche
 (even if a growing one), but not really heading to be mainstream in
 medium/large scale projects.


 Sorry, I actually meant "I think dynamic _typing_ is somewhat of a niche"
 rather than the above. Yes, the two are closely related, but they are not
 the same.
 For example, I wouldn't be surprised if in the future certain
 dynamically-typed languages gain some static-typing capabilities. (like the
 inverse is happening)


 From reading about this, it seems like what D has is very similar to what
 Scala calls "Structural Typing" (see
 http://codemonkeyism.com/scala-goodness-structural-typing/). The
 difference is that Scala tends to use structural typing with inline type
 declarations (although they don't have to be inline). However, the basic
 concept is the same, where a class is dynamically checked for compliance
 with a static type. Not quite dynamic typing, but definitely related.
 If you're after a more accurate description, how would that work?

 Andrew Wiley


Actually, that's wrong, as the class is statically checked for compliance
with a static type, but still.
Nov 11 2010
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Kagamin wrote:

 Andrei Alexandrescu Wrote:
=20

 I was talking to Walter about Kenji's adaptTo. We both think it's a ve=




ry=20

 powerful enabler, but adaptTo is a bland name. After discussing a few =





 marketing strategies, I proposed "duck". It's short, simple, and evoke=




s=20

 "duck typing".


=20
 1. adaptTo helped me to understand what it does, while duck!Drawable do=


esn't.

 2. I don't think it's duck typing, I'm affraid "duck" name is misleadin=


g.

	Both make "duck" a very good name for it, considering some other
name choices in D...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Oct 16 2010
prev sibling next sibling parent reply "JimBob" <jim bob.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i9ae2n$k9g$1 digitalmars.com...

I was talking to Walter about Kenji's adaptTo. We both think it's a very 
powerful enabler, but adaptTo is a bland name. After discussing a few 
marketing strategies, I proposed "duck". It's short, simple, and evokes 
"duck typing".

 class C
 {
     int draw(){ return 10; }
 }
 interface Drawable
 {
     long draw();
 }
 ...
 auto c = new C;
 auto d = duck!Drawable(c); // awes

 Kenji, I'll be looking forward to your submission :o). Would be great to 
 allow structs to duck, too!


duck doesnt convey much meaning imo so.. why not "adapt!"

Ties in with the Adaptor design pattern.. which i'm guessing is what it 
actualy does.
Oct 15 2010
parent reply Jimmy Cao <jcao219 gmail.com> writes:
It doesn't matter if it sounds unintuitive to you right now,
eventually if you keep using it, the word will stick.
duck! is a nice name, so I'm fine with the idea.

On Fri, Oct 15, 2010 at 4:46 PM, JimBob <jim bob.com> wrote:


 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:i9ae2n$k9g$1 digitalmars.com...

I was talking to Walter about Kenji's adaptTo. We both think it's a very
powerful enabler, but adaptTo is a bland name. After discussing a few
marketing strategies, I proposed "duck". It's short, simple, and evokes
"duck typing".

 class C
 {
     int draw(){ return 10; }
 }
 interface Drawable
 {
     long draw();
 }
 ...
 auto c = new C;
 auto d = duck!Drawable(c); // awes

 Kenji, I'll be looking forward to your submission :o). Would be great to
 allow structs to duck, too!


 duck doesnt convey much meaning imo so.. why not "adapt!"

 Ties in with the Adaptor design pattern.. which i'm guessing is what it
 actualy does.
Oct 15 2010
parent "JimBob" <jim bob.com> writes:
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'd get used to Jimmy!, and thats a nice name too.



  "Jimmy Cao" <jcao219 gmail.com> wrote in message =
news:mailman.635.1287179560.858.digitalmars-d puremagic.com...
  It doesn't matter if it sounds unintuitive to you right now,
  eventually if you keep using it, the word will stick.
  duck! is a nice name, so I'm fine with the idea.


  On Fri, Oct 15, 2010 at 4:46 PM, JimBob <jim bob.com> wrote:


    "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in =
message
    news:i9ae2n$k9g$1 digitalmars.com...

    >I was talking to Walter about Kenji's adaptTo. We both think it's a =
very
    >powerful enabler, but adaptTo is a bland name. After discussing a =
few
    >marketing strategies, I proposed "duck". It's short, simple, and =
evokes
    >"duck typing".
    >
    > class C
    > {
    >     int draw(){ return 10; }
    > }
    > interface Drawable
    > {
    >     long draw();
    > }
    > ...
    > auto c =3D new C;
    > auto d =3D duck!Drawable(c); // awes
    >
    > Kenji, I'll be looking forward to your submission :o). Would be =
great to
    > allow structs to duck, too!


    duck doesnt convey much meaning imo so.. why not "adapt!"

    Ties in with the Adaptor design pattern.. which i'm guessing is what =
it
    actualy does.
Oct 15 2010
prev sibling next sibling parent reply "Christof Schardt" <csnews schardt.info> writes:
 auto d = duck!Drawable(c); // awes


What about "as" ?

auto d = as!Drawable(c);

Christof
Oct 16 2010
next sibling parent reply Justin Johansson <no spam.com> writes:
On 16/10/2010 6:30 PM, Christof Schardt wrote:

 auto d = duck!Drawable(c); // awes


 What about "as" ?

 auto d = as!Drawable(c);

 Christof


This is a totally brilliant suggestion by Christof as
anyone who understands the XPath 2.0 type language
would tell you also.

While finding duck! rather cute, marketing intelligence
will confirm that Christof's as! suggestion is the way to go.

I feel woeful that I did not think of it myself.  Award
for naming suggestion definitely goes to Christof.

Justin
Oct 16 2010
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Justin Johansson wrote:


 On 16/10/2010 6:30 PM, Christof Schardt wrote:

 auto d = duck!Drawable(c); // awes


 What about "as" ?

 auto d = as!Drawable(c);

 Christof


 
 This is a totally brilliant suggestion by Christof as
 anyone who understands the XPath 2.0 type language
 would tell you also.
 
 While finding duck! rather cute, marketing intelligence
 will confirm that Christof's as! suggestion is the way to go.
 
 I feel woeful that I did not think of it myself.  Award
 for naming suggestion definitely goes to Christof.
 
 Justin


plus, it's shorter to type. 

*ducks*
Oct 16 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Lutger wrote:

 Justin Johansson wrote:
 

 On 16/10/2010 6:30 PM, Christof Schardt wrote:

 auto d = duck!Drawable(c); // awes


 What about "as" ?

 auto d = as!Drawable(c);

 Christof


 This is a totally brilliant suggestion by Christof as
 anyone who understands the XPath 2.0 type language
 would tell you also.

 While finding duck! rather cute, marketing intelligence
 will confirm that Christof's as! suggestion is the way to go.

 I feel woeful that I did not think of it myself.  Award
 for naming suggestion definitely goes to Christof.

 Justin


 
 plus, it's shorter to type. 
 
 *ducks*


Try googling "as for D"
Oct 16 2010
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I'm going to go with duck on this one. It could be an attractive name
to put in reddit/yc titles.. "Can your language duck? D can, with
duck!". Plus it's easily greppable and easy to type. And I don't like
stuttering words like adaptTo, there's two repeating t's in there
*and* I need a shift, that is an outrage!

Not every word in the language/lib has to be dead-serious. :)


On 10/16/10, Walter Bright <newshound2 digitalmars.com> wrote:

 Lutger wrote:

 Justin Johansson wrote:


 On 16/10/2010 6:30 PM, Christof Schardt wrote:

 auto d = duck!Drawable(c); // awes


 What about "as" ?

 auto d = as!Drawable(c);

 Christof


 This is a totally brilliant suggestion by Christof as
 anyone who understands the XPath 2.0 type language
 would tell you also.

 While finding duck! rather cute, marketing intelligence
 will confirm that Christof's as! suggestion is the way to go.

 I feel woeful that I did not think of it myself.  Award
 for naming suggestion definitely goes to Christof.

 Justin


 plus, it's shorter to type.

 *ducks*


 Try googling "as for D"
Oct 16 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-10-16 03:30:27 -0400, "Christof Schardt" <csnews schardt.info> said:


 auto d = duck!Drawable(c); // awes


 
 What about "as" ?
 
 auto d = as!Drawable(c);


I like "as" much more than "duck". It's a good fit with "to".


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 16 2010
parent reply Justin Johansson <no spam.com> writes:
On 16/10/2010 11:03 PM, Michel Fortin wrote:

 On 2010-10-16 03:30:27 -0400, "Christof Schardt" <csnews schardt.info>
 said:


 auto d = duck!Drawable(c); // awes


 What about "as"

 auto d = as!Drawable(c);


 I like "as" much more than "duck". It's a good fit with "to".


It all comes down to some type of morphism, say, an isomorphism,
homomorphism, hetromorphism, polymorphism or other.

Maybe I am wrong but me thinks that "to" fits better with polymorphism
than isomorphism, whereas "as" fits better with "what quacks like"
and therefore asymptotically approaching isomorphism which I think
"duck typing" is all about.

To consider the argument further we could ask whether or not there is
is a bijective map f such that both f and its inverse f −1 are
homomorphisms, i.e., structure-preserving mappings. ..., and from
there further consider analogous mappings in the morphology domain
with respect to both isomorphisms and polymorphisms.

In short "as!" eats the lunch of "to!" in the "duck typing" metaphor.

Now we call upon the morphism experts to adjudicate.

Cheers
Justin
Oct 16 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-10-16 08:41:26 -0400, Justin Johansson <no spam.com> said:


 In short "as!" eats the lunch of "to!" in the "duck typing" metaphor.


Yeah, I do agree, and I didn't mean I'd prefer "to" instead of "as". 
All I said (or I meant to say) is that they look good as a pair, "as" 
is in a way a continuity from "to", which I like.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Oct 16 2010
prev sibling next sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 10/16/2010 10:30 AM, Christof Schardt wrote:

 auto d = duck!Drawable(c); // awes


 What about "as" ?

 auto d = as!Drawable(c);

 Christof



users but that is probably a non-issue.
Oct 16 2010
parent reply Russel Winder <russel russel.org.uk> writes:
On Sat, 2010-10-16 at 15:25 +0300, Max Samukha wrote:

 On 10/16/2010 10:30 AM, Christof Schardt wrote:

 auto d =3D duck!Drawable(c); // awes


 What about "as" ?

 auto d =3D as!Drawable(c);

 Christof


=20



=20

 users but that is probably a non-issue.


Groovy uses as as a conversion operator.  cf.

        def x =3D [ run : { println ( 'Hello World.' ) } ] as Thread
        x.start ( )


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 16 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:

 Groovy uses [...]


!!!
Oct 16 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/16/10 2:30 CDT, Christof Schardt wrote:

 auto d = duck!Drawable(c); // awes


 What about "as" ?

 auto d = as!Drawable(c);


Nice too, and evokes "to". "to" was a success in spite of the fact that 
it's difficult to talk about (e.g. "Could you use 'to'?" "To what?" 
etc). I still prefer "duck" because it doesn't have this problem.

Speaking of which, it looks like std.conv is a good place to put duck in.


Andrei
Oct 16 2010
parent Seth Hoenig <seth.a.hoenig gmail.com> writes:
On Sat, Oct 16, 2010 at 9:01 AM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 10/16/10 2:30 CDT, Christof Schardt wrote:


 auto d = duck!Drawable(c); // awes


 What about "as" ?

 auto d = as!Drawable(c);


 Nice too, and evokes "to". "to" was a success in spite of the fact that
 it's difficult to talk about (e.g. "Could you use 'to'?" "To what?" etc). I
 still prefer "duck" because it doesn't have this problem.






 Speaking of which, it looks like std.conv is a good place to put duck in.


 Andrei


Hmm.. I was going to suggest /dev/null but I suppose that works too. If we
have to have it, I would vote for "as" over "duck" simply because duck can
be interpreted either a noun with only metaphorical relevance or as a verb
with no relevance at all. On the other hand, "as" is simple and gets the
point across.



 Oct 16 2010



prev sibling next sibling parent  David Gileadi <gileadis NSPMgmail.com>  writes:


On 10/16/10 12:30 AM, Christof Schardt wrote:

 auto d = duck!Drawable(c); // awes


 What about "as" ?

 auto d = as!Drawable(c);

 Christof


Forgive my ignorance, but with uniform function syntax, could this be 
rewritten as:

auto d = c.as!Drawable;

or will uniform function syntax not work with templates?



 Oct 16 2010



prev sibling next sibling parent reply Juanjo Alvarez <fake fakeemail.com>  writes:


On Sat, 16 Oct 2010 09:30:27 +0200, "Christof Schardt" 
<csnews schardt.info> wrote:

 auto d = as!Drawable(c);


My turn:

auto d = implements!Drawable(c);



 Oct 16 2010



  parent  Peter Alexander <peter.alexander.au gmail.com>  writes:


On 16/10/10 4:24 PM, Juanjo Alvarez wrote:

 On Sat, 16 Oct 2010 09:30:27 +0200, "Christof Schardt"
 <csnews schardt.info> wrote:

 auto d = as!Drawable(c);


 My turn:

 auto d = implements!Drawable(c);


That doesn't really work. If I saw that, I would assume that 
"implements" returns a boolean true when c implements the Drawable 
interface, rather than returning an object that does implement the 
interface.

Out of all of them, I like "as" the best, although people might confuse 




 Oct 16 2010



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sat, 16 Oct 2010 03:30:27 -0400, Christof Schardt <csnews schardt.info>  
wrote:


 auto d = duck!Drawable(c); // awes


 What about "as" ?

 auto d = as!Drawable(c);

 Christof


I like as better than duck.

-Steve



 Oct 16 2010



  parent  Torarin <torarind gmail.com>  writes:


I feel "as" and "to" are too similar, they could both be interpreted
as simple casting for example.



 Oct 16 2010



prev sibling next sibling parent  "Denis Koroskin" <2korden gmail.com>  writes:


On Sat, 16 Oct 2010 00:37:10 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 I was talking to Walter about Kenji's adaptTo. We both think it's a very  
 powerful enabler, but adaptTo is a bland name. After discussing a few  
 marketing strategies, I proposed "duck". It's short, simple, and evokes  
 "duck typing".

 class C
 {
      int draw(){ return 10; }
 }
 interface Drawable
 {
      long draw();
 }
 ...
 auto c = new C;
 auto d = duck!Drawable(c); // awes

 Kenji, I'll be looking forward to your submission :o). Would be great to  
 allow structs to duck, too!


 Andrei


There is a lot in common between to and adaptTo (even the original names  
are similar). 'to' converts one type to another (unless the two are  
implicitly castable) and 'adaptTo' does the same. 'adaptTo' can transform  
some types that 'to' can't, and vice versa.

In my opinion, they don't compete but supplement each other. As such I  
would prefer merging the two together:

auto c = to!(Drawable)(c); // try casting to Drawable first, return  
adaptTo(Drawable) if it fails.

The difference between 'as' and 'to' is subtle yet both names are short  
and might be confusing for many people, not only novices. Yet 'as' is  
better than 'duck' imo.



 Oct 16 2010



prev sibling next sibling parent reply kenji hara <k.hara.pg gmail.com>  writes:


I'm not a native English speaker, so you are well about naming than I.

But, by two reasons, I think 'duck' isn't good.

1.
'Duck Typing' is phenomenon, not doing.
- auto d =3D adaptTo!Drawable(c)
- auto d =3D duck!Drawable(c)
Which is more explainable that this statement does?
I think adaptTo is more better.

2.
I'm now implementing function getting original object from
interface(like Drawable).
----
auto c =3D new C();
auto d =3D adaptTo!Drawable(c);
...
auto c2 =3D  =3D XXX!C(d)
assert(c2 is c);
----
In this case, XXX's name may be antonym of adaptTo.
What is the antonym of 'duck'?

I hope helpful.

Kenji Hara

2010/10/16 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 I was talking to Walter about Kenji's adaptTo. We both think it's a very
 powerful enabler, but adaptTo is a bland name. After discussing a few
 marketing strategies, I proposed "duck". It's short, simple, and evokes
 "duck typing".

 class C
 {
 =A0 =A0int draw(){ return 10; }
 }
 interface Drawable
 {
 =A0 =A0long draw();
 }
 ...
 auto c =3D new C;
 auto d =3D duck!Drawable(c); // awes

 Kenji, I'll be looking forward to your submission :o). Would be great to
 allow structs to duck, too!


 Andrei





 Oct 16 2010



 next sibling parent  "Simen kjaeraas" <simen.kjaras gmail.com>  writes:


kenji hara <k.hara.pg gmail.com> wrote:


 I'm now implementing function getting original object from
 interface(like Drawable).
 ----
 auto c = new C();
 auto d = adaptTo!Drawable(c);
 ...
 auto c2 =  = XXX!C(d)
 assert(c2 is c);
 ----
 In this case, XXX's name may be antonym of adaptTo.
 What is the antonym of 'duck'?


goose?

-- 
Simen



 Oct 16 2010



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 11:35 AM, kenji hara wrote:

 I'm not a native English speaker, so you are well about naming than I.

 But, by two reasons, I think 'duck' isn't good.

 1.
 'Duck Typing' is phenomenon, not doing.
 - auto d = adaptTo!Drawable(c)
 - auto d = duck!Drawable(c)
 Which is more explainable that this statement does?
 I think adaptTo is more better.


The problem with "adaptTo" is that, just like itoa or printf, it is too 
boring to have marketing value. I think the feature is going to be 
_big_. We can't leave a big feature to a name like "adaptTo". The New 
York Times won't have a headline like "adaptTo changes the name of the 
game".

This is also part of my beef with "as" or "to" for the feature. "As" is 
difficult to talk about. "Oh my God, D has 'as'!" "Has ass?"

I'd go with the longer "ducktype". Length is not as important as 
evocative power and brand name!

auto d = ducktype!Drawable(obj);

99.99% of programmers will have an idea of what's going on.


 2.
 I'm now implementing function getting original object from
 interface(like Drawable).
 ----
 auto c = new C();
 auto d = adaptTo!Drawable(c);
 ...
 auto c2 =  = XXX!C(d)
 assert(c2 is c);
 ----
 In this case, XXX's name may be antonym of adaptTo.
 What is the antonym of 'duck'?


No need for an antonym. Just apply again. It is its own inverse and 
makes everything simple for everyone:

----
auto c = new C();
auto d = ducktype!Drawable(c);
...
auto c2 =  = ducktype!C(d)
assert(c2 is c);
----

Boom! You're done.


Andrei



 Oct 16 2010



 next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 The problem with "adaptTo" is that, just like itoa or printf, it is too  
 boring to have marketing value.


Wait, really?  This statement has no place in a programming language  
decision IMO.  Nobody is going to start using D because it has a function  
*named* duck.

Let's change writef to shazam!  Let's call File BitLocker!  And 'to'  
really should be called transformationVehicle!

If you want to help market D, come up with some better logos, help  
redesign the web site, and maybe write a book (oh wait, you already did  
that :)

-Steve



 Oct 16 2010



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Steven Schveighoffer wrote:

 On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 The problem with "adaptTo" is that, just like itoa or printf, it is 
 too boring to have marketing value.


 
 Wait, really?  This statement has no place in a programming language 
 decision IMO.


One would think programmers are above all that, but we are not.



 Nobody is going to start using D because it has a 
 function *named* duck.


Maybe not, but it will raise awareness that "D has duck typing". Otherwise, I 
guarantee you that people will argue that "I need duck typing, and Z has it and 
D does not" if it is named adaptTo.

People will search on "duck typing in D" and with the duck template, they'll 
drop right in on it. With "adaptTo", it'll be on page 67 of the results,
they'll 
never find it, and will conclude that D cannot do duck typing.



 Let's change writef to shazam!  Let's call File BitLocker!  And 'to' 
 really should be called transformationVehicle!


Think of it another way. Remember zip files? What a great name, and yes, it 
seemed silly at first, but zip entered the lexicon and D has a zip module and
it 
never occurs to anyone it might be better named std.compressedArchive. Phil
Katz 
renamed arc files "zip" files, called his compressor "pkzip" and blew away arc 
so badly that most people are unaware it even existed.

I think the catchy, silly "zip" name was a significant factor in getting people 
to notice his program. In contrast, the superior "lharc" with its "lzh" files 
never caught on.



 If you want to help market D, come up with some better logos, help 
 redesign the web site, and maybe write a book (oh wait, you already did 
 that :)


We are working on all of that. It's all important.



 Oct 16 2010



 next sibling parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2010-10-16 14:32:10 -0400, Walter Bright <newshound2 digitalmars.com> said:


 Nobody is going to start using D because it has a function *named* duck.


 
 Maybe not, but it will raise awareness that "D has duck typing". 
 Otherwise, I guarantee you that people will argue that "I need duck 
 typing, and Z has it and D does not" if it is named adaptTo.


The problem is that D doesn't have duck-typing. The adapter pattern 
isn't duck-typing. Duck-typing is when you have an object and can call 
a 'quack' function on it and if there's no 'quack' function you get a 
runtime error.

It's like saying D is a dynamic language, people will know you're 
bullshitting them.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Oct 16 2010



 next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


Michel Fortin wrote:

 On 2010-10-16 14:32:10 -0400, Walter Bright <newshound2 digitalmars.com> 
 said:
 

 Nobody is going to start using D because it has a function *named* duck.


 Maybe not, but it will raise awareness that "D has duck typing". 
 Otherwise, I guarantee you that people will argue that "I need duck 
 typing, and Z has it and D does not" if it is named adaptTo.


 
 The problem is that D doesn't have duck-typing. The adapter pattern 
 isn't duck-typing. Duck-typing is when you have an object and can call a 
 'quack' function on it and if there's no 'quack' function you get a 
 runtime error.


If you make an interface that consists solely of the 'quack' function, then 
duck!quack(object) satisfies the requirement if object has a 'quack' function.


 It's like saying D is a dynamic language, people will know you're 
 bullshitting them.





 Oct 16 2010



prev sibling next sibling parent reply so <so so.do>  writes:


Reading wikipedia, definition and the examples exactly match adaptTo.  
Before naming it, i think we should first be clear about if it is really  
duck-typing or not.

On Sat, 16 Oct 2010 21:44:51 +0300, Michel Fortin  
<michel.fortin michelf.com> wrote:


 On 2010-10-16 14:32:10 -0400, Walter Bright <newshound2 digitalmars.com>  
 said:


 Nobody is going to start using D because it has a function *named*  
 duck.


  Maybe not, but it will raise awareness that "D has duck typing".  
 Otherwise, I guarantee you that people will argue that "I need duck  
 typing, and Z has it and D does not" if it is named adaptTo.


 The problem is that D doesn't have duck-typing. The adapter pattern  
 isn't duck-typing. Duck-typing is when you have an object and can call a  
 'quack' function on it and if there's no 'quack' function you get a  
 runtime error.

 It's like saying D is a dynamic language, people will know you're  
 bullshitting them.



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



 Oct 16 2010



 next sibling parent  Jimmy Cao <jcao219 gmail.com>  writes:


I think it's safe to say this is pretty much duck-typing in D (?)
So then, if duck! is used, it puts emphasis on what the function allows D to
do (duck-typing),
while if as! is used, it sounds more intuitive (kinda like ".respond_to?" in
Ruby) .

So going with my previous statement,
if you keep using duck!, or adaptTo!, or whatever this becomes, it will
eventually stick and will sound intuitive no matter what.
In that way, I think as! is not necessarily such a good choice.

Also, I really agree with Kagamin and Walter's argument, that simply the
name "duck!" would raise awareness for this features.

2010/10/16 so <so so.do>


 Reading wikipedia, definition and the examples exactly match adaptTo.
 Before naming it, i think we should first be clear about if it is really
 duck-typing or not.


 On Sat, 16 Oct 2010 21:44:51 +0300, Michel Fortin <
 michel.fortin michelf.com> wrote:

  On 2010-10-16 14:32:10 -0400, Walter Bright <newshound2 digitalmars.com>

 said:

  Nobody is going to start using D because it has a function *named* duck.


  Maybe not, but it will raise awareness that "D has duck typing".
 Otherwise, I guarantee you that people will argue that "I need duck typing,
 and Z has it and D does not" if it is named adaptTo.


 The problem is that D doesn't have duck-typing. The adapter pattern isn't
 duck-typing. Duck-typing is when you have an object and can call a 'quack'
 function on it and if there's no 'quack' function you get a runtime error.

 It's like saying D is a dynamic language, people will know you're
 bullshitting them.


 --
 Using Opera's revolutionary e-mail client: http://www.opera.com/mail/





 Oct 16 2010



prev sibling  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


What's all this arguing about anyway?

import std.conv : duck;

alias duck as;
alias duck adaptTo;

Done deal.

On 10/16/10, Jimmy Cao <jcao219 gmail.com> wrote:

 I think it's safe to say this is pretty much duck-typing in D (?)
 So then, if duck! is used, it puts emphasis on what the function allows D to
 do (duck-typing),
 while if as! is used, it sounds more intuitive (kinda like ".respond_to?" in
 Ruby) .

 So going with my previous statement,
 if you keep using duck!, or adaptTo!, or whatever this becomes, it will
 eventually stick and will sound intuitive no matter what.
 In that way, I think as! is not necessarily such a good choice.

 Also, I really agree with Kagamin and Walter's argument, that simply the
 name "duck!" would raise awareness for this features.

 2010/10/16 so <so so.do>


 Reading wikipedia, definition and the examples exactly match adaptTo.
 Before naming it, i think we should first be clear about if it is really
 duck-typing or not.


 On Sat, 16 Oct 2010 21:44:51 +0300, Michel Fortin <
 michel.fortin michelf.com> wrote:

  On 2010-10-16 14:32:10 -0400, Walter Bright <newshound2 digitalmars.com>

 said:

  Nobody is going to start using D because it has a function *named* duck.


  Maybe not, but it will raise awareness that "D has duck typing".
 Otherwise, I guarantee you that people will argue that "I need duck
 typing,
 and Z has it and D does not" if it is named adaptTo.


 The problem is that D doesn't have duck-typing. The adapter pattern isn't
 duck-typing. Duck-typing is when you have an object and can call a
 'quack'
 function on it and if there's no 'quack' function you get a runtime
 error.

 It's like saying D is a dynamic language, people will know you're
 bullshitting them.


 --
 Using Opera's revolutionary e-mail client: http://www.opera.com/mail/







 Oct 16 2010



prev sibling next sibling parent reply Kagamin <spam here.lot>  writes:


Michel Fortin Wrote:


 The problem is that D doesn't have duck-typing. The adapter pattern 
 isn't duck-typing. Duck-typing is when you have an object and can call 
 a 'quack' function on it and if there's no 'quack' function you get a 
 runtime error.


Isn't that dynamic typing?



 Oct 16 2010



  parent  Jimmy Cao <jcao219 gmail.com>  writes:


According to wikipedia,
duck typing is a style of dynamic typing where an object's
methods/properties determine what i can do.

On Sat, Oct 16, 2010 at 2:14 PM, Kagamin <spam here.lot> wrote:


 Michel Fortin Wrote:


 The problem is that D doesn't have duck-typing. The adapter pattern
 isn't duck-typing. Duck-typing is when you have an object and can call
 a 'quack' function on it and if there's no 'quack' function you get a
 runtime error.


 Isn't that dynamic typing?





 Oct 16 2010



prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


 The problem is that D doesn't have duck-typing.


But it does and it has for a long time:

void func(A)(A a) {
   a.quack();
}

This new thing looks to me to be more like Go typing (lol?), where objects
fulfill
interfaces without explicit templates on the functions nor decorations on the
class. Here's a name!

go!IWhatever(myclass)

hahaha.



 Oct 16 2010



  parent  Jimmy Cao <jcao219 gmail.com>  writes:


Haha!
But many people consider the interface system in Go as duck-typing,
so imo duck! is a very suitable name.

On Sat, Oct 16, 2010 at 2:25 PM, Adam D. Ruppe <destructionator gmail.com>wrote:


 The problem is that D doesn't have duck-typing.


 But it does and it has for a long time:

 void func(A)(A a) {
   a.quack();
 }

 This new thing looks to me to be more like Go typing (lol?), where objects
 fulfill
 interfaces without explicit templates on the functions nor decorations on
 the
 class. Here's a name!

 go!IWhatever(myclass)

 hahaha.





 Oct 16 2010



prev sibling  parent reply kenji hara <k.hara.pg gmail.com>  writes:


Adapter-Pattern! I'd have forgotten the name.
It is NOT equals to duck-typing.

adaptTo supports Adapter-Pattern.

Thanks Michel.

Kenji Hara

2010/10/17 Michel Fortin <michel.fortin michelf.com>:

 On 2010-10-16 14:32:10 -0400, Walter Bright <newshound2 digitalmars.com>
 said:


 Nobody is going to start using D because it has a function *named* duck.


 Maybe not, but it will raise awareness that "D has duck typing".
 Otherwise, I guarantee you that people will argue that "I need duck typing,
 and Z has it and D does not" if it is named adaptTo.


 The problem is that D doesn't have duck-typing. The adapter pattern isn't
 duck-typing. Duck-typing is when you have an object and can call a 'quack'
 function on it and if there's no 'quack' function you get a runtime error.

 It's like saying D is a dynamic language, people will know you're
 bullshitting them.

 --
 Michel Fortin
 michel.fortin michelf.com
 http://michelf.com/





 Oct 16 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 02:54 PM, kenji hara wrote:

 Adapter-Pattern! I'd have forgotten the name.
 It is NOT equals to duck-typing.


It's a subset of duck typing. I don't think calling a function that 
supports a limited form of duck typing "duck" is a lie.

Andrei



 Oct 16 2010



 next sibling parent  so <so so.do>  writes:


Wouldn't linking adaptTo to opDispatch (if the functions we are after not  
supported by that class) make it complete duck-typing?

On Sat, 16 Oct 2010 23:05:52 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 10/16/2010 02:54 PM, kenji hara wrote:

 Adapter-Pattern! I'd have forgotten the name.
 It is NOT equals to duck-typing.


 It's a subset of duck typing. I don't think calling a function that  
 supports a limited form of duck typing "duck" is a lie.

 Andrei



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



 Oct 16 2010



prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 On 10/16/2010 02:54 PM, kenji hara wrote:

 Adapter-Pattern! I'd have forgotten the name.
 It is NOT equals to duck-typing.


 
 It's a subset of duck typing. I don't think calling a function that 
 supports a limited form of duck typing "duck" is a lie.


Not a lie, just a word with a deceptive meaning that'll lead people to 
believe something else than the truth. Some cynically call that 
marketing speech.

In my opinion, a duck type in D should be a variant that allows you to 
call all the functions of the underlying object, and throws (at 
runtime) when no matching function is found. I think you'll agree with 
me that this is very far from the adapter pattern.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Oct 16 2010



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 03:30 PM, Michel Fortin wrote:

 On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:


 On 10/16/2010 02:54 PM, kenji hara wrote:

 Adapter-Pattern! I'd have forgotten the name.
 It is NOT equals to duck-typing.


 It's a subset of duck typing. I don't think calling a function that
 supports a limited form of duck typing "duck" is a lie.


 Not a lie, just a word with a deceptive meaning that'll lead people to
 believe something else than the truth. Some cynically call that
 marketing speech.


As Walter said, that's probably why he, you, and myself aren't marketers.


 In my opinion, a duck type in D should be a variant that allows you to
 call all the functions of the underlying object, and throws (at runtime)
 when no matching function is found. I think you'll agree with me that
 this is very far from the adapter pattern.


In fact I had this idea while running:

interface Widget
{
     void draw();
     void move(int x, int y);
}

interface ColoredWidget : Widget
{
    void setColor(Color c);
}

class Drawable
{
    void draw();
    void move(int x, int y);
}

unittest
{
     auto x = new Drawable;
     auto a = nameone!Widget(x); // works
     //auto b = nameone!ColoredWidget(x); // doesn't compile
     auto c = nametwo!ColoredWidget(x);
     c.draw(); // works
     c.setColor(red); // throws NotImplemented during runtime
}

"nameone" implements Kenji's current code. "nametwo" is the looser form 
of duck typing: whatever methods match will work, and the rest are 
implemented to throw during runtime.

Question is, of course, figuring out good substitutes for nameone and 
nametwo.

Kenji, do you think you could also implement nametwo?


Andrei



 Oct 16 2010



 next sibling parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2010-10-16 17:45:56 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 unittest
 {
      auto x = new Drawable;
      auto a = nameone!Widget(x); // works
      //auto b = nameone!ColoredWidget(x); // doesn't compile
      auto c = nametwo!ColoredWidget(x);
      c.draw(); // works
      c.setColor(red); // throws NotImplemented during runtime
 }
 
 "nameone" implements Kenji's current code. "nametwo" is the looser form 
 of duck typing: whatever methods match will work, and the rest are 
 implemented to throw during runtime.


What you're proposing above is just useless, and I'm honestly quite 
surprised you don't realize that.

The real duck type almost already exists in Phobos, and it's called a 
variant. The only problem with it is that it is powerless when it comes 
to calling functions without casting it's content to a type first. Make 
it so this code can run and then you'll have implemented duck typing 
for real:

	class Duck { void quack(); }
	Variant v = new Duck;
	v.quack();

Well, mostly. It could also be argued that this too should work too:

	Variant v = cast(Object)(new Duck);
	v.quack();

but that'd require runtime reflexion as part of ClassInfo.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Oct 16 2010



  parent reply Leandro Lucarella <luca llucax.com.ar>  writes:


Michel Fortin, el 16 de octubre a las 18:19 me escribiste:

 On 2010-10-16 17:45:56 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:
 

unittest
{
     auto x = new Drawable;
     auto a = nameone!Widget(x); // works
     //auto b = nameone!ColoredWidget(x); // doesn't compile
     auto c = nametwo!ColoredWidget(x);
     c.draw(); // works
     c.setColor(red); // throws NotImplemented during runtime
}

"nameone" implements Kenji's current code. "nametwo" is the looser
form of duck typing: whatever methods match will work, and the
rest are implemented to throw during runtime.


 
 What you're proposing above is just useless, and I'm honestly quite
 surprised you don't realize that.
 
 The real duck type almost already exists in Phobos, and it's called
 a variant. The only problem with it is that it is powerless when it
 comes to calling functions without casting it's content to a type
 first. Make it so this code can run and then you'll have implemented
 duck typing for real:
 
 	class Duck { void quack(); }
 	Variant v = new Duck;
 	v.quack();
 
 Well, mostly. It could also be argued that this too should work too:
 
 	Variant v = cast(Object)(new Duck);
 	v.quack();
 
 but that'd require runtime reflexion as part of ClassInfo.


I agree that "nametwo" is useless, but what you're proposing is plain
dynamic typing, not duck typing. Duck-typing is what Go (and adaptTo)
does. In dynamic languages you have to check for the methods existence
at runtime just because is the only way to do it, but if you want to use
a duck, you *need* to know that the object you're working with *can*
quack().

That doesn't make dynamic typing a bad idea, it can be useful, but
please don't name it "ducktype" as Andrei suggested.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Sometimes I think the sure sign that life exists elsewhere in the universe
Is that that none of them tried to contact us



 Oct 16 2010



  parent  Michel Fortin <michel.fortin michelf.com>  writes:


On 2010-10-16 22:02:35 -0400, Leandro Lucarella <luca llucax.com.ar> said:


 I agree that "nametwo" is useless, but what you're proposing is plain
 dynamic typing, not duck typing. Duck-typing is what Go (and adaptTo)
 does. In dynamic languages you have to check for the methods existence
 at runtime just because is the only way to do it, but if you want to use
 a duck, you *need* to know that the object you're working with *can*
 quack().
 
 That doesn't make dynamic typing a bad idea, it can be useful, but
 please don't name it "ducktype" as Andrei suggested.


What Go does is not duck typing, it's structural typing. It clearly has 
some of the benefits of duck typing and thus shares some similarities 
with it, but it's not the same.
<http://en.wikipedia.org/wiki/Structural_typing>


In my argumentation, I try to stick to Wikipedia's definition of duck typing:
<http://en.wikipedia.org/wiki/Duck_typing>


 In computer programming with object-oriented programming languages, 
 duck typing is a style of dynamic typing in which an object's current 
 set of methods and properties determines the valid semantics, rather 
 than its inheritance from a particular class or implementation of a 
 specific interface.
 
 [...]
 
 In duck typing, one is concerned with just those aspects of an object 
 that are used, rather than with the type of the object itself.
 
 [...]
 
 Duck typing is aided by habitually not testing for the type of 
 arguments in method and function bodies, relying on documentation, 
 clear code, and testing to ensure correct use. Users of statically 
 typed languages new to dynamically typed languages are usually tempted 
 to add such static (before run-time) type checks, defeating the 
 benefits and flexibility of duck typing, and constraining the 
 language's dynamism.


Read twice that last sentence. Clearly, statically implementing an 
interface is not what duck-typing is about. It could perhaps qualify as 
some sort structural typing, but it's better known as the adapter 
pattern.
<http://en.wikipedia.org/wiki/Adapter_pattern>


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Oct 16 2010



prev sibling  parent reply kenji hara <k.hara.pg gmail.com>  writes:


Current dmd does not enough support runtime reflection.

----
// test code
class A
{
    int quack() { return 10; }
}

void main()
{
    Object o =3D new A();
    TypeInfo ti;

    ti =3D typeid(o);
    if( auto ti_c =3D cast(TypeInfo_Class)ti ){

        auto members =3D ti_c.getMembers("quack");
        assert(members !is null);   // --> failed!!

        foreach( mi; members ){
            if( auto mi_fn =3D cast(MemberInfo_function)mi ){
                assert(mi_fn.name =3D=3D "quack");
                auto fp =3D mi_fn.fp;
                auto ti_fn =3D mi_fn.typeInfo;
                //...
            }
        }
    }
}
----

Kenji Hara.

2010/10/17 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 10/16/2010 03:30 PM, Michel Fortin wrote:

 On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:


 On 10/16/2010 02:54 PM, kenji hara wrote:

 Adapter-Pattern! I'd have forgotten the name.
 It is NOT equals to duck-typing.


 It's a subset of duck typing. I don't think calling a function that
 supports a limited form of duck typing "duck" is a lie.


 Not a lie, just a word with a deceptive meaning that'll lead people to
 believe something else than the truth. Some cynically call that
 marketing speech.


 As Walter said, that's probably why he, you, and myself aren't marketers.


 In my opinion, a duck type in D should be a variant that allows you to
 call all the functions of the underlying object, and throws (at runtime)
 when no matching function is found. I think you'll agree with me that
 this is very far from the adapter pattern.


 In fact I had this idea while running:

 interface Widget
 {
 =A0 =A0void draw();
 =A0 =A0void move(int x, int y);
 }

 interface ColoredWidget : Widget
 {
 =A0 void setColor(Color c);
 }

 class Drawable
 {
 =A0 void draw();
 =A0 void move(int x, int y);
 }

 unittest
 {
 =A0 =A0auto x =3D new Drawable;
 =A0 =A0auto a =3D nameone!Widget(x); // works
 =A0 =A0//auto b =3D nameone!ColoredWidget(x); // doesn't compile
 =A0 =A0auto c =3D nametwo!ColoredWidget(x);
 =A0 =A0c.draw(); // works
 =A0 =A0c.setColor(red); // throws NotImplemented during runtime
 }

 "nameone" implements Kenji's current code. "nametwo" is the looser form o=


f

 duck typing: whatever methods match will work, and the rest are implement=


ed

 to throw during runtime.

 Question is, of course, figuring out good substitutes for nameone and
 nametwo.

 Kenji, do you think you could also implement nametwo?


 Andrei





 Oct 16 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 05:57 PM, kenji hara wrote:

 Current dmd does not enough support runtime reflection.


[snip]

I think runtime reflection is not needed. What you'd need to do for the 
"loose duck" is generate code that throws for all interface methods that 
are not present in the class. Am I wrong?

Andrei



 Oct 16 2010



  parent reply "Denis Koroskin" <2korden gmail.com>  writes:


On Sun, 17 Oct 2010 04:17:18 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 10/16/2010 05:57 PM, kenji hara wrote:

 Current dmd does not enough support runtime reflection.


 [snip]

 I think runtime reflection is not needed. What you'd need to do for the  
 "loose duck" is generate code that throws for all interface methods that  
 are not present in the class. Am I wrong?

 Andrei


interface ICanQuack
{
	void quack() { ... }
}

class Duck
{
	void quack() { .. }
}

Object o = new Duck();
Duck d = duck!(ICanQuack)(o);

d.quack(); // throw or not?



 Oct 16 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 07:50 PM, Denis Koroskin wrote:

 On Sun, 17 Oct 2010 04:17:18 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 10/16/2010 05:57 PM, kenji hara wrote:

 Current dmd does not enough support runtime reflection.


 [snip]

 I think runtime reflection is not needed. What you'd need to do for
 the "loose duck" is generate code that throws for all interface
 methods that are not present in the class. Am I wrong?

 Andrei


 interface ICanQuack
 {
 void quack() { ... }
 }

 class Duck
 {
 void quack() { .. }
 }

 Object o = new Duck();
 Duck d = duck!(ICanQuack)(o);

 d.quack(); // throw or not?


Throw... but now I see what Kenji meant. Thanks! So really there's three 
levels:

- statically-enforced conformance

- statically-decided conformance

- dynamically-decided conformance

Now we have three names to find, not one :o).


Andrei



 Oct 16 2010



prev sibling  parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 16/10/2010 21:30, Michel Fortin wrote:

 On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:


 On 10/16/2010 02:54 PM, kenji hara wrote:

 Adapter-Pattern! I'd have forgotten the name.
 It is NOT equals to duck-typing.


 It's a subset of duck typing. I don't think calling a function that
 supports a limited form of duck typing "duck" is a lie.


 Not a lie, just a word with a deceptive meaning that'll lead people to
 believe something else than the truth. Some cynically call that
 marketing speech.


I have to agree with Kenji and Michael here: this is not duck typing. 
Duck typing is like example "6. Dynamic object type&  dynamic signature" 
in Kenji's last post.

The problem is not just strictly the name of the adapter function, but 
that from this whole thread there was that the implication that you 
Andrei, and Walter, were willing to market D as "having duck typing", or 
"supporting duck typing", without any qualification on that support 
("subset of", "limited form of", or even just "form of" like the Go 
slides). So I agree with Michael, this would be inaccurate at best, and 
deceitful at worst.

We could argue nomenclature, but there is a much more simple litmus 
test: any non-D developer who used proper duck typing before, and then 
heard "D has duck typing" from some official sources, and then tried D 
out and found out how the actual feature worked, would almost certainly 
feel deceived or disappointed.


-- 
Bruno Medeiros - Software Engineer



 Nov 11 2010



prev sibling next sibling parent reply kenji hara <k.hara.pg gmail.com>  writes:


Yes, it certainly is not a lie.
In Naming Type System, adaptTo extends duck.

But, people who you want to appeal it will think that all of
duck-typings each person imagine possible.
As a result, by knowing duck supports only Adapter-Pattern, they will
be lied to and angry.
It will negatively affect D.

D also has duck-typing by template, so naming adaptTo duck will be
making ambiguous situations.
(Like Tuple and TypeTuple)

Please reconsider it.

Kenji.

2010/10/17 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 10/16/2010 02:54 PM, kenji hara wrote:

 Adapter-Pattern! I'd have forgotten the name.
 It is NOT equals to duck-typing.


 It's a subset of duck typing. I don't think calling a function that supports
 a limited form of duck typing "duck" is a lie.

 Andrei





 Oct 16 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 03:43 PM, kenji hara wrote:

 Yes, it certainly is not a lie.
 In Naming Type System, adaptTo extends duck.

 But, people who you want to appeal it will think that all of
 duck-typings each person imagine possible.
 As a result, by knowing duck supports only Adapter-Pattern, they will
 be lied to and angry.
 It will negatively affect D.

 D also has duck-typing by template, so naming adaptTo duck will be
 making ambiguous situations.
 (Like Tuple and TypeTuple)

 Please reconsider it.

 Kenji.


One way to go would be to implement the looser form of duck typing under 
the name "duck" and the current stricter variant under the name "adapt". 
(See my previous message.)


Andrei



 Oct 16 2010



prev sibling  parent reply Jeff Nowakowski <jeff dilacero.org>  writes:


On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote:

 It's a subset of duck typing. I don't think calling a function that
 supports a limited form of duck typing "duck" is a lie.


I'm sure if it was on a Go slide you would.



 Oct 17 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/17/2010 01:09 PM, Jeff Nowakowski wrote:

 On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote:

 It's a subset of duck typing. I don't think calling a function that
 supports a limited form of duck typing "duck" is a lie.


 I'm sure if it was on a Go slide you would.


Probably not in as strong terms, but if you want to point out that I'm 
biased... what can I do? I'm a simple man.

Andrei



 Oct 17 2010



  parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 17/10/2010 20:11, Andrei Alexandrescu wrote:

 On 10/17/2010 01:09 PM, Jeff Nowakowski wrote:

 On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote:

 It's a subset of duck typing. I don't think calling a function that
 supports a limited form of duck typing "duck" is a lie.


 I'm sure if it was on a Go slide you would.


 Probably not in as strong terms, but if you want to point out that I'm
 biased... what can I do? I'm a simple man.

 Andrei


When I first heard you say you were biased (in the Google Talk), I 
thought you were being facetious, or just exaggerating.

I'm not so sure anymore, and I hope that is not the case. Because, as 
I'm sure you must realize, being biased for D will only result in an 
outcome of mild to severe annoyance and loss of credibility from:
* people biased for languages which are perceived to be competitors to D 
(like Go).
* people who are (or strive to be) unbiased.

And given who you are (one of the designers of D), this outcome will 
apply not just to yourself, but D as well, which obviously is not a good 
thing.

-- 
Bruno Medeiros - Software Engineer



 Nov 11 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/11/10 6:30 AM, Bruno Medeiros wrote:

 On 17/10/2010 20:11, Andrei Alexandrescu wrote:

 On 10/17/2010 01:09 PM, Jeff Nowakowski wrote:

 On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote:

 It's a subset of duck typing. I don't think calling a function that
 supports a limited form of duck typing "duck" is a lie.


 I'm sure if it was on a Go slide you would.


 Probably not in as strong terms, but if you want to point out that I'm
 biased... what can I do? I'm a simple man.

 Andrei


 When I first heard you say you were biased (in the Google Talk), I
 thought you were being facetious, or just exaggerating.

 I'm not so sure anymore, and I hope that is not the case. Because, as
 I'm sure you must realize, being biased for D will only result in an
 outcome of mild to severe annoyance and loss of credibility from:
 * people biased for languages which are perceived to be competitors to D
 (like Go).
 * people who are (or strive to be) unbiased.

 And given who you are (one of the designers of D), this outcome will
 apply not just to yourself, but D as well, which obviously is not a good
 thing.


I think I ascribe a milder meaning than you to "bias". It's in human 
nature to have preferences, and it's self-evident that I'm biased in 
favor of various facets of D's approach to computing. A completely 
unbiased person would have a hard time working on anything creative.

Andrei



 Nov 11 2010



  parent  Bruno Medeiros <brunodomedeiros+spam com.gmail>  writes:


On 11/11/2010 15:22, Andrei Alexandrescu wrote:

 On 11/11/10 6:30 AM, Bruno Medeiros wrote:

 On 17/10/2010 20:11, Andrei Alexandrescu wrote:

 On 10/17/2010 01:09 PM, Jeff Nowakowski wrote:

 On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote:

 It's a subset of duck typing. I don't think calling a function that
 supports a limited form of duck typing "duck" is a lie.


 I'm sure if it was on a Go slide you would.


 Probably not in as strong terms, but if you want to point out that I'm
 biased... what can I do? I'm a simple man.

 Andrei


 When I first heard you say you were biased (in the Google Talk), I
 thought you were being facetious, or just exaggerating.

 I'm not so sure anymore, and I hope that is not the case. Because, as
 I'm sure you must realize, being biased for D will only result in an
 outcome of mild to severe annoyance and loss of credibility from:
 * people biased for languages which are perceived to be competitors to D
 (like Go).
 * people who are (or strive to be) unbiased.

 And given who you are (one of the designers of D), this outcome will
 apply not just to yourself, but D as well, which obviously is not a good
 thing.


 I think I ascribe a milder meaning than you to "bias". It's in human
 nature to have preferences, and it's self-evident that I'm biased in
 favor of various facets of D's approach to computing. A completely
 unbiased person would have a hard time working on anything creative.

 Andrei


I don't think the bias above is just a case of preferences of one thing 
over the other. Having preferences is perfectly fine, as in "I prefer 
this approach", or even "I think this approach is more effective than 
that one".
Another thing is to describe reality in inaccurate terms ("I think 
approach A has property Z", when it doesn't), and/or to have a double 
standard when describing or analyzing something else.


-- 
Bruno Medeiros - Software Engineer



 Nov 19 2010



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sat, 16 Oct 2010 14:32:10 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 Steven Schveighoffer wrote:

 On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:


 The problem with "adaptTo" is that, just like itoa or printf, it is  
 too boring to have marketing value.


  Wait, really?  This statement has no place in a programming language  
 decision IMO.


 One would think programmers are above all that, but we are not.


We are not talking about a feature name, we are talking about a *function*  
name.  I personally think 'as' is better than 'adaptTo' or 'duck'.


 Nobody is going to start using D because it has a function *named* duck.


 Maybe not, but it will raise awareness that "D has duck typing".  
 Otherwise, I guarantee you that people will argue that "I need duck  
 typing, and Z has it and D does not" if it is named adaptTo.

 People will search on "duck typing in D" and with the duck template,  
 they'll drop right in on it. With "adaptTo", it'll be on page 67 of the  
 results, they'll never find it, and will conclude that D cannot do duck  
 typing.


I would expect them to search for it and find the 'duck typing' section of  
the D marketing documents, and see that 'D does duck typing, see  
adaptTo'.  Or find it on wikipedia.

Unless you plan on handing people a full copy of the phobos docs as  
'marketing material'...


 Let's change writef to shazam!  Let's call File BitLocker!  And 'to'  
 really should be called transformationVehicle!


 Think of it another way. Remember zip files? What a great name, and yes,  
 it seemed silly at first, but zip entered the lexicon and D has a zip  
 module and it never occurs to anyone it might be better named  
 std.compressedArchive. Phil Katz renamed arc files "zip" files, called  
 his compressor "pkzip" and blew away arc so badly that most people are  
 unaware it even existed.

 I think the catchy, silly "zip" name was a significant factor in getting  
 people to notice his program. In contrast, the superior "lharc" with its  
 "lzh" files never caught on.


These are completely unsubstantiated statements focused on a very narrow  
set of variables.  It's like all those studies that say X causes cancer  
because look most people who use X have cancer.  Well, yeah, but they are  
all 40-70 yr old people, who freaking knows how many factors went into  
them getting cancer!!!  And it proves itself again and again when the next  
year, they say, 'well that study was flawed, we now *know* that it was  
really Y'.

Besides, duck isn't the compiler name, it's a very very small part of the  
library.  I think you associate more weight to this than there actually  
is.  Let's concentrate on finding the name that best describes the  
function.  This might be 'duck', but let's leave marketing considerations  
out of it.  If duck was a verb that meant 'walk like a...'  then I'd agree  
it was a fine term.

How about if we can say D's functions are named intuitively instead of  
after some colloquial term that describes the function?

And yeah, I agree zip is now a de-facto term, so much so that I think  
std.range.Zip should be renamed :)  But was it zip that made the tool  
famous or the tool that made zip famous?

Let's also not forget the hundreds, probably thousands, of 'cute' names  
that didn't save their respective products because the marketing material  
sucked.

-Steve



 Oct 16 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Steven Schveighoffer wrote:

 Think of it another way. Remember zip files? What a great name, and 
 yes, it seemed silly at first, but zip entered the lexicon and D has a 
 zip module and it never occurs to anyone it might be better named 
 std.compressedArchive. Phil Katz renamed arc files "zip" files, called 
 his compressor "pkzip" and blew away arc so badly that most people are 
 unaware it even existed.

 I think the catchy, silly "zip" name was a significant factor in 
 getting people to notice his program. In contrast, the superior 
 "lharc" with its "lzh" files never caught on.


 
 These are completely unsubstantiated statements focused on a very narrow 
 set of variables.  It's like all those studies that say X causes cancer 
 because look most people who use X have cancer.  Well, yeah, but they 
 are all 40-70 yr old people, who freaking knows how many factors went 
 into them getting cancer!!!  And it proves itself again and again when 
 the next year, they say, 'well that study was flawed, we now *know* that 
 it was really Y'.


It's an example of a phenomenon I've seen over and over. How about the names 
Google and Yahoo? Boy did I think they were stupid names for companies and 
products. Boy was I wrong. How about the perjorative name "twitter" and the 
hopelessly undignified verb "tweet"? I still can't bring myself to say I 
"tweeted". Ugh.

I also couldn't believe all the mileage Borland got out of naming minor
features 
"zoom technology" and "smart linking". So I don't buy that we programmers are 
above all that.

"duck" *is* indicative of what the feature does, and so it is a lot better than 
"zoom" or "smart" or "yahoo", which I'd have a hard time justifying. I guess 
that's why I'm not a marketer!



 Besides, duck isn't the compiler name, it's a very very small part of 
 the library.  I think you associate more weight to this than there 
 actually is.


A lot of people do think duck typing is very important.



 Let's concentrate on finding the name that best describes 
 the function.  This might be 'duck', but let's leave marketing 
 considerations out of it.  If duck was a verb that meant 'walk like 
 a...'  then I'd agree it was a fine term.
 
 How about if we can say D's functions are named intuitively instead of 
 after some colloquial term that describes the function?
 
 And yeah, I agree zip is now a de-facto term, so much so that I think 
 std.range.Zip should be renamed :)  But was it zip that made the tool 
 famous or the tool that made zip famous?
 
 Let's also not forget the hundreds, probably thousands, of 'cute' names 
 that didn't save their respective products because the marketing 
 material sucked.


I think 'zip' got peoples' attention, and then pkzip delivered the goods
(better 
than arc). lharc, on the other hand, had a ponderous name and failed despite 
being significantly better. So yeah, I think the name got pkzip on the map, but 
yes, the product also had to deliver. A cute name is not enough to save a crap 
product, but it will help with a good one.

If you want people to notice something and give it a chance to be good, having
a 
boring name (that is also not google-friendly) will never give it a chance.

And besides, as Andrei pointed out, I'll get really tired of saying ad
infinitum 
"Yes, you can do duck typing in D, just use the adaptTo function." Say that
1000 
times, and you too will decide that "duck" is a better name.



 Oct 16 2010



 next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sat, 16 Oct 2010 16:26:15 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 Steven Schveighoffer wrote:

 Think of it another way. Remember zip files? What a great name, and  
 yes, it seemed silly at first, but zip entered the lexicon and D has a  
 zip module and it never occurs to anyone it might be better named  
 std.compressedArchive. Phil Katz renamed arc files "zip" files, called  
 his compressor "pkzip" and blew away arc so badly that most people are  
 unaware it even existed.

 I think the catchy, silly "zip" name was a significant factor in  
 getting people to notice his program. In contrast, the superior  
 "lharc" with its "lzh" files never caught on.


  These are completely unsubstantiated statements focused on a very  
 narrow set of variables.  It's like all those studies that say X causes  
 cancer because look most people who use X have cancer.  Well, yeah, but  
 they are all 40-70 yr old people, who freaking knows how many factors  
 went into them getting cancer!!!  And it proves itself again and again  
 when the next year, they say, 'well that study was flawed, we now  
 *know* that it was really Y'.


 It's an example of a phenomenon I've seen over and over. How about the  
 names Google and Yahoo? Boy did I think they were stupid names for  
 companies and products. Boy was I wrong. How about the perjorative name  
 "twitter" and the hopelessly undignified verb "tweet"? I still can't  
 bring myself to say I "tweeted". Ugh.


This is called cherry picking.  What about microsoft, IBM, apple,  
gillette, DOS, etc.  All these names aren't "wacky", yet they are still  
successful.  How do you explain that?  You might lump GoDaddy.com as one  
of those 'wacky' names that made it, but that has nothing to do with it.

Google and Yahoo succeeded because their product was good.  D will succeed  
because it does duck typing, not because the function that does duck  
typing is called 'duck'.  Now, if D was all about duck typing, and you  
called it 'ducky', then I think that the name might be appropriate, and  
actually help with marketing.  But naming the function that does duck  
typing 'duck' doesn't seem to me like it makes or breaks D at all.  I want  
to be clear that duck is not my first choice, but it's certainly a name  
that makes sense.  I'm just saying that marketability of D does not change  
no matter what appropriate term you choose.


 I also couldn't believe all the mileage Borland got out of naming minor  
 features "zoom technology" and "smart linking". So I don't buy that we  
 programmers are above all that.


But were there functions named zoomTechnology() and smartLink()?  Were  
their tools named zoom or smartl or something?  Is that what pushed them  
over the edge, or was it the bullet on the packaging that said:

* Includes zoom technology!


 "duck" *is* indicative of what the feature does, and so it is a lot  
 better than "zoom" or "smart" or "yahoo", which I'd have a hard time  
 justifying. I guess that's why I'm not a marketer!


Yes, duck is a valid option.  And the fact that duck typing is what it  
does is a very good reason to use it.  I just don't see 'marketing draw'  
as being a factor whatsoever.  It's useless noise.


 Besides, duck isn't the compiler name, it's a very very small part of  
 the library.  I think you associate more weight to this than there  
 actually is.


 A lot of people do think duck typing is very important.


And D already does duck typing.  Templates do duck typing.  'adaptTo' does  
it too, and it's cool, but it's not *that* important (no offense, Kenji).


 Let's concentrate on finding the name that best describes the  
 function.  This might be 'duck', but let's leave marketing  
 considerations out of it.  If duck was a verb that meant 'walk like  
 a...'  then I'd agree it was a fine term.
  How about if we can say D's functions are named intuitively instead of  
 after some colloquial term that describes the function?
  And yeah, I agree zip is now a de-facto term, so much so that I think  
 std.range.Zip should be renamed :)  But was it zip that made the tool  
 famous or the tool that made zip famous?
  Let's also not forget the hundreds, probably thousands, of 'cute'  
 names that didn't save their respective products because the marketing  
 material sucked.


 I think 'zip' got peoples' attention, and then pkzip delivered the goods  
 (better than arc). lharc, on the other hand, had a ponderous name and  
 failed despite being significantly better. So yeah, I think the name got  
 pkzip on the map, but yes, the product also had to deliver. A cute name  
 is not enough to save a crap product, but it will help with a good one.

 If you want people to notice something and give it a chance to be good,  
 having a boring name (that is also not google-friendly) will never give  
 it a chance.


But people don't search google for "duck typing programming languages" and  
pick the language they're going to use from this list!  I think you are  
really going cuckoo over this feature like it's the best thing since  
ranges, and I don't see it being that.  Not only that, but *D DOES DUCK  
TYPING*, just use a template.


 And besides, as Andrei pointed out, I'll get really tired of saying ad  
 infinitum "Yes, you can do duck typing in D, just use the adaptTo  
 function." Say that 1000 times, and you too will decide that "duck" is a  
 better name.


Invariant vs. immutable is not the same as adaptTo vs. duck.  Invariant  
already had a meaning in D1, and when choosing a new name, it was logical  
to use immutable.  Is immutable an 'exciting marketing term'?  No, it's as  
boring as they come.  But it's definitely the best term for the job.   
Let's focus on choosing the best term for what 'adaptTo' does, and when we  
market that D does duck typing in an article or a list of features (that  
shows up on google), we can include all the features of D that do duck  
typing.

-Steve



 Oct 16 2010



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 04:00 PM, Steven Schveighoffer wrote:

 But naming the function that does duck
 typing 'duck' doesn't seem to me like it makes or breaks D at all.


You do find it important, otherwise you wouldn't have spent cumulative 
hours arguing about it.

Andrei



 Oct 16 2010



  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sat, 16 Oct 2010 17:50:53 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 10/16/2010 04:00 PM, Steven Schveighoffer wrote:

 But naming the function that does duck
 typing 'duck' doesn't seem to me like it makes or breaks D at all.


 You do find it important, otherwise you wouldn't have spent cumulative  
 hours arguing about it.


Honestly, I am not objecting to the name duck!  It's a fine name, and  
successfully describes the meaning (as long as you explain it to newbies  
who have no idea what 'duck typing' is).  The only issue I have is the  
statement that naming the function duck is somehow a marketing benefit, or  
that naming it something that correctly describes the function, but isn't  
duck, will somehow push away users.

-Steve



 Oct 18 2010



prev sibling next sibling parent reply Michael Chen <sth4nth gmail.com>  writes:


totally agreeed. let advertisability to influence a function name is
ridiculous to me. you gotta have some princeple for names, but
advertisability? i dont think so.

On Sunday, October 17, 2010, Steven Schveighoffer <schveiguy yahoo.com> wro=
te:

 On Sat, 16 Oct 2010 16:26:15 -0400, Walter Bright <newshound2 digitalmars=


.com> wrote:

 Steven Schveighoffer wrote:

 Think of it another way. Remember zip files? What a great name, and yes, =


it seemed silly at first, but zip entered the lexicon and D has a zip modul=
e and it never occurs to anyone it might be better named std.compressedArch=
ive. Phil Katz renamed arc files "zip" files, called his compressor "pkzip"=
 and blew away arc so badly that most people are unaware it even existed.

 I think the catchy, silly "zip" name was a significant factor in getting =


people to notice his program. In contrast, the superior "lharc" with its "l=
zh" files never caught on.

 =A0These are completely unsubstantiated statements focused on a very narr=


ow set of variables. =A0It's like all those studies that say X causes cance=
r because look most people who use X have cancer. =A0Well, yeah, but they a=
re all 40-70 yr old people, who freaking knows how many factors went into t=
hem getting cancer!!! =A0And it proves itself again and again when the next=
 year, they say, 'well that study was flawed, we now *know* that it was rea=
lly Y'.

 It's an example of a phenomenon I've seen over and over. How about the na=


mes Google and Yahoo? Boy did I think they were stupid names for companies =
and products. Boy was I wrong. How about the perjorative name "twitter" and=
 the hopelessly undignified verb "tweet"? I still can't bring myself to say=
 I "tweeted". Ugh.

 This is called cherry picking. =A0What about microsoft, IBM, apple, gille=


tte, DOS, etc. =A0All these names aren't "wacky", yet they are still succes=
sful. =A0How do you explain that? =A0You might lump GoDaddy.com as one of t=
hose 'wacky' names that made it, but that has nothing to do with it.

 Google and Yahoo succeeded because their product was good. =A0D will succ=


eed because it does duck typing, not because the function that does duck ty=
ping is called 'duck'. =A0Now, if D was all about duck typing, and you call=
ed it 'ducky', then I think that the name might be appropriate, and actuall=
y help with marketing. =A0But naming the function that does duck typing 'du=
ck' doesn't seem to me like it makes or breaks D at all. =A0I want to be cl=
ear that duck is not my first choice, but it's certainly a name that makes =
sense. =A0I'm just saying that marketability of D does not change no matter=
 what appropriate term you choose.

 I also couldn't believe all the mileage Borland got out of naming minor f=


eatures "zoom technology" and "smart linking". So I don't buy that we progr=
ammers are above all that.

 But were there functions named zoomTechnology() and smartLink()? =A0Were =


their tools named zoom or smartl or something? =A0Is that what pushed them =
over the edge, or was it the bullet on the packaging that said:

 * Includes zoom technology!



 "duck" *is* indicative of what the feature does, and so it is a lot bette=


r than "zoom" or "smart" or "yahoo", which I'd have a hard time justifying.=
 I guess that's why I'm not a marketer!

 Yes, duck is a valid option. =A0And the fact that duck typing is what it =


does is a very good reason to use it. =A0I just don't see 'marketing draw' =
as being a factor whatsoever. =A0It's useless noise.

 Besides, duck isn't the compiler name, it's a very very small part of the=


 library. =A0I think you associate more weight to this than there actually =
is.

 A lot of people do think duck typing is very important.


 And D already does duck typing. =A0Templates do duck typing. =A0'adaptTo'=


 does it too, and it's cool, but it's not *that* important (no offense, Ken=
ji).

 Let's concentrate on finding the name that best describes the function. =


=A0This might be 'duck', but let's leave marketing considerations out of it=
. =A0If duck was a verb that meant 'walk like a...' =A0then I'd agree it wa=
s a fine term.

 =A0How about if we can say D's functions are named intuitively instead of=


 after some colloquial term that describes the function?

 =A0And yeah, I agree zip is now a de-facto term, so much so that I think =


std.range.Zip should be renamed :) =A0But was it zip that made the tool fam=
ous or the tool that made zip famous?

 =A0Let's also not forget the hundreds, probably thousands, of 'cute' name=


s that didn't save their respective products because the marketing material=
 sucked.

 I think 'zip' got peoples' attention, and then pkzip delivered the goods =


(better than arc). lharc, on the other hand, had a ponderous name and faile=
d despite being significantly better. So yeah, I think the name got pkzip o=
n the map, but yes, the product also had to deliver. A cute name is not eno=
ugh to save a crap product, but it will help with a good one.

 If you want people to notice something and give it a chance to be good, h=


aving a boring name (that is also not google-friendly) will never give it a=
 chance.

 But people don't search google for "duck typing programming languages" an=


d pick the language they're going to use from this list! =A0I think you are=
 really going cuckoo over this feature like it's the best thing since range=
s, and I don't see it being that. =A0Not only that, but *D DOES DUCK TYPING=
*, just use a template.

 And besides, as Andrei pointed out, I'll get really tired of saying ad in=


finitum "Yes, you can do duck typing in D, just use the adaptTo function." =
Say that 1000 times, and you too will decide that "duck" is a better name.

 Invariant vs. immutable is not the same as adaptTo vs. duck. =A0Invariant=


 already had a meaning in D1, and when choosing a new name, it was logical =
to use immutable. =A0Is immutable an 'exciting marketing term'? =A0No, it's=
 as boring as they come. =A0But it's definitely the best term for the job. =
=A0Let's focus on choosing the best term for what 'adaptTo' does, and when =
we market that D does duck typing in an article or a list of features (that=
 shows up on google), we can include all the features of D that do duck typ=
ing.

 -Steve





 Oct 16 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 04:52 PM, Michael Chen wrote:

 totally agreeed. let advertisability to influence a function name is
 ridiculous to me. you gotta have some princeple for names, but
 advertisability? i dont think so.


It is a function, but it implements an entire feature - like e.g. 
"cast". What if D has casting but called it e.g. "force"?

I'm looking for a name that is descriptive and evocative.


Andrei



 Oct 16 2010



prev sibling next sibling parent  Jimmy Cao <jcao219 gmail.com>  writes:


The very important principle here for the naming is making it obvious that D
supports an element of duck-typing.
Naming it duck! does just that.
Advertisability is not what I would use to describe it.  How about clarity,
articulateness, and lucidity?

On Sat, Oct 16, 2010 at 4:52 PM, Michael Chen <sth4nth gmail.com> wrote:


 totally agreeed. let advertisability to influence a function name is
 ridiculous to me. you gotta have some princeple for names, but
 advertisability? i dont think so.





 Oct 16 2010



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Steven Schveighoffer wrote:

 I'm just saying that marketability of D does 
 not change no matter what appropriate term you choose.


And this is our fundamental disagreement. I think the choices of names matters
a 
lot.

If names don't matter, why not name your son "Sue" ? :-)


 But were there functions named zoomTechnology() and smartLink()?  Were 
 their tools named zoom or smartl or something?  Is that what pushed them 
 over the edge, or was it the bullet on the packaging that said:
 
 * Includes zoom technology!


I don't believe that there is any fundamental difference between the name of a 
function and the name of the technology.




 But people don't search google for "duck typing programming languages" 
 and pick the language they're going to use from this list!


They may very well search "duck typing in the D programming language". Heck, 
that's what I do when I'm investigating whether language X supports feature Y.
I 
do it a lot.



 I think you 
 are really going cuckoo over this feature like it's the best thing since 
 ranges, and I don't see it being that.


I am happy with the name ranges for what it does, I think it's exactly right.
Am 
I going cuckoo over this one? Perhaps. But I also believe that even getting the 
small details right is important.

It reminds me of when a friend visited my house. After a very brief interval,
he 
announced could tell it was a quality house, not a cheap facade. Intrigued, I 
asked him how. He said that the screw slots holding the wall plates on were all 
aligned the same way. It's a wholly irrelevant detail, added absolutely nothing 
to the function, but he said such attention to detail indicated the contractor 
cared about getting the details right.



 Invariant vs. immutable is not the same as adaptTo vs. duck.  Invariant 
 already had a meaning in D1, and when choosing a new name, it was 
 logical to use immutable.  Is immutable an 'exciting marketing term'?  
 No, it's as boring as they come.  But it's definitely the best term for 
 the job.  Let's focus on choosing the best term for what 'adaptTo' does, 
 and when we market that D does duck typing in an article or a list of 
 features (that shows up on google), we can include all the features of D 
 that do duck typing.


With invariant I *always* had to explain it (even to people with no knowledge
of 
the D1 meaning), and people would looked puzzled even after the explanation. 
With immutable, I stopped having to explain it. The name change was a big win.



 Oct 16 2010



 next sibling parent reply "abram" <abramw901 no_robots.net>  writes:


Walter Bright wrote:


 It reminds me of when a friend visited my house. After a very brief
 interval, he announced could tell it was a quality house, not a cheap
 facade. Intrigued, I asked him how. He said that the screw slots
 holding the wall plates on were all aligned the same way. It's a
 wholly irrelevant detail, added absolutely nothing to the function,
 but he said such attention to detail indicated the contractor cared
 about getting the details right.


That reminds me of many a house I considered buying: what's behind those 
walls? Nuff said, but I'll go on. Are there rats in the cellar? Lead 
pipes? Asbestos? Walls cover it all. Show me what's under those walls and 
maybe you'll have a sale. Wait, that's the wrong "argument". Time out, 
regroup.: I would not buy anything "glossed over" (ref: engine 
compartments of cars people buy. Oh yes, they pressure wash them and give 
them a coat of laquer!).



 Oct 16 2010



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


abram wrote:

 Walter Bright wrote:
 

 It reminds me of when a friend visited my house. After a very brief
 interval, he announced could tell it was a quality house, not a cheap
 facade. Intrigued, I asked him how. He said that the screw slots
 holding the wall plates on were all aligned the same way. It's a
 wholly irrelevant detail, added absolutely nothing to the function,
 but he said such attention to detail indicated the contractor cared
 about getting the details right.


 
 That reminds me of many a house I considered buying: what's behind those 
 walls? Nuff said, but I'll go on. Are there rats in the cellar? Lead 
 pipes? Asbestos? Walls cover it all. Show me what's under those walls and 
 maybe you'll have a sale. Wait, that's the wrong "argument". Time out, 
 regroup.: I would not buy anything "glossed over" (ref: engine 
 compartments of cars people buy. Oh yes, they pressure wash them and give 
 them a coat of laquer!).


Yeah, but if they do a sloppy job on what shows, that doesn't bode well for
what 
doesn't.



 Oct 17 2010



prev sibling  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sat, 16 Oct 2010 18:20:37 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 Steven Schveighoffer wrote:

 I'm just saying that marketability of D does not change no matter what  
 appropriate term you choose.


 And this is our fundamental disagreement. I think the choices of names  
 matters a lot.

 If names don't matter, why not name your son "Sue" ? :-)


Notice I said *appropriate* term :)  And he prefers Susan.


 But were there functions named zoomTechnology() and smartLink()?  Were  
 their tools named zoom or smartl or something?  Is that what pushed  
 them over the edge, or was it the bullet on the packaging that said:
  * Includes zoom technology!


 I don't believe that there is any fundamental difference between the  
 name of a function and the name of the technology.


The name of the technology can be inventive, super-descriptive, slightly  
exaggerated, a marketing term.  The name of a function can be that, but  
doesn't have to be.  Preferrably it should be succinct and related to the  
technology.  'duck' is a fine term, but as a function name is not going to  
score any marketing points.


 But people don't search google for "duck typing programming languages"  
 and pick the language they're going to use from this list!


 They may very well search "duck typing in the D programming language".  
 Heck, that's what I do when I'm investigating whether language X  
 supports feature Y. I do it a lot.


Most people will look at something like  
http://en.wikipedia.org/wiki/Duck_typing and find D precariously missing  
because as Michel Fortin pointed out, adaptTo is not duck typing.


 I think you are really going cuckoo over this feature like it's the  
 best thing since ranges, and I don't see it being that.


 I am happy with the name ranges for what it does, I think it's exactly  
 right. Am I going cuckoo over this one? Perhaps. But I also believe that  
 even getting the small details right is important.


As do I.  To suggest that not liking the term 'duck' the best means a lack  
of attention to detail is a little argumentative, don't you think?


 It reminds me of when a friend visited my house. After a very brief  
 interval, he announced could tell it was a quality house, not a cheap  
 facade. Intrigued, I asked him how. He said that the screw slots holding  
 the wall plates on were all aligned the same way. It's a wholly  
 irrelevant detail, added absolutely nothing to the function, but he said  
 such attention to detail indicated the contractor cared about getting  
 the details right.


Really?  That's like saying a car is very well maintained because the  
headlights are properly aligned.  I'd highly advise against using the  
"screw alignment test" for buying a house ;)


 Invariant vs. immutable is not the same as adaptTo vs. duck.  Invariant  
 already had a meaning in D1, and when choosing a new name, it was  
 logical to use immutable.  Is immutable an 'exciting marketing term'?   
 No, it's as boring as they come.  But it's definitely the best term for  
 the job.  Let's focus on choosing the best term for what 'adaptTo'  
 does, and when we market that D does duck typing in an article or a  
 list of features (that shows up on google), we can include all the  
 features of D that do duck typing.


 With invariant I *always* had to explain it (even to people with no  
 knowledge of the D1 meaning), and people would looked puzzled even after  
 the explanation. With immutable, I stopped having to explain it. The  
 name change was a big win.


Yes, because using invariant to mean immutable is somewhat of a misnomer.   
The CS meaning of invariant is:  
http://en.wikipedia.org/wiki/Invariant_%28computer_science%29.  I think  
you'd agree that as!X and adaptTo!X are not obscure terms that don't  
describe the function properly.  Heck, the pattern being implemented here  
is the adapter pattern, so adaptTo seems like a pretty correct term.

-Steve



 Oct 18 2010



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 03:26 PM, Walter Bright wrote:

 It's an example of a phenomenon I've seen over and over. How about the
 names Google and Yahoo? Boy did I think they were stupid names for
 companies and products. Boy was I wrong. How about the perjorative name
 "twitter" and the hopelessly undignified verb "tweet"? I still can't
 bring myself to say I "tweeted". Ugh.

 I also couldn't believe all the mileage Borland got out of naming minor
 features "zoom technology" and "smart linking". So I don't buy that we
 programmers are above all that.


C++ credits a lot of its early success to provide "class" which is 
essentially a synonym to "struct". Technically it wasn't even necessary 
with that semantics, yet everybody wet their pants when they saw the 
keyword.


 "duck" *is* indicative of what the feature does, and so it is a lot
 better than "zoom" or "smart" or "yahoo", which I'd have a hard time
 justifying. I guess that's why I'm not a marketer!

 Besides, duck isn't the compiler name, it's a very very small part of
 the library. I think you associate more weight to this than there
 actually is.


 A lot of people do think duck typing is very important.


It's the defining feature of Go.


Andrei



 Oct 16 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Andrei Alexandrescu wrote:

 On 10/16/2010 03:26 PM, Walter Bright wrote:

 A lot of people do think duck typing is very important.


 It's the defining feature of Go.


That makes me curious about the etymology of duckduckgo.com !



 Oct 16 2010



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday 16 October 2010 15:06:21 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 On 10/16/2010 03:26 PM, Walter Bright wrote:

 A lot of people do think duck typing is very important.


 
 It's the defining feature of Go.


 
 That makes me curious about the etymology of duckduckgo.com !


I think that it's supposed to come from duck duck goose.

- Jonathan M Davis



 Oct 16 2010



prev sibling  parent  "abram" <abramw901 no_robots.net>  writes:


Walter Bright wrote:

 Andrei Alexandrescu wrote:

 On 10/16/2010 03:26 PM, Walter Bright wrote:

 A lot of people do think duck typing is very important.


 It's the defining feature of Go.


 That makes me curious about the etymology of duckduckgo.com !


Sympathy plea? 



 Oct 16 2010



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 12:38 PM, Steven Schveighoffer wrote:

 On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 The problem with "adaptTo" is that, just like itoa or printf, it is
 too boring to have marketing value.


 Wait, really? This statement has no place in a programming language
 decision IMO. Nobody is going to start using D because it has a function
 *named* duck.

 Let's change writef to shazam! Let's call File BitLocker! And 'to'
 really should be called transformationVehicle!


I think ducktype is an important feature of D. I want to give it a name 
that is correspondingly resounding. The likes of files, writef, and 
conversions are commonplace. That's all.

Andrei



 Oct 16 2010



  parent  "abram" <abramw901 no_robots.net>  writes:


Andrei Alexandrescu wrote:

 On 10/16/2010 12:38 PM, Steven Schveighoffer wrote:

 On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 The problem with "adaptTo" is that, just like itoa or printf, it is
 too boring to have marketing value.


 Wait, really? This statement has no place in a programming language
 decision IMO. Nobody is going to start using D because it has a
 function *named* duck.

 Let's change writef to shazam! Let's call File BitLocker! And 'to'
 really should be called transformationVehicle!


 I think ducktype is an important feature of D. I want to give it a
 name that is correspondingly resounding. The likes of files, writef,
 and conversions are commonplace. That's all.


Sounds like an epitaph! 



 Oct 16 2010



prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2010-10-16 13:19:36 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 The problem with "adaptTo" is that, just like itoa or printf, it is too 
 boring to have marketing value. I think the feature is going to be 
 _big_. We can't leave a big feature to a name like "adaptTo". The New 
 York Times won't have a headline like "adaptTo changes the name of the 
 game".


It's risky in my opinion to bet that it's going to be a feature big 
enough that everyone will remember what it means. Also, "duck" is a 
misnomer. The commonly-accepted meaning of duck typing is basically 
dynamic dispatch based on function names, and when the function doesn't 
exist it's a runtime error. I bet you'll get a ton of negative feedback 
for misrepresentation or deformation of the concept. That said, it 
could bring attention, but perhaps not the kind of attention you'd like.

Programmers like automated things. That feature should be called "magic 
adapters" or "cheap adapters" (or some variation of that) because it's 
an adapter and it's magic/cheap, and people can search "adapter" and 
immediately get hundreds of results explaining the concept. And the 
function name could be "adaptTo", or "adapt" (or "magic" if you want it 
to look funny).

And I think I agree with your arguments about "as" having problems.



 I'd go with the longer "ducktype". Length is not as important as 
 evocative power and brand name!
 
 auto d = ducktype!Drawable(obj);


At this point, why not call it ducktape™. Now that's a brand name.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Oct 16 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/16/2010 01:43 PM, Michel Fortin wrote:

 On 2010-10-16 13:19:36 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:


 The problem with "adaptTo" is that, just like itoa or printf, it is
 too boring to have marketing value. I think the feature is going to be
 _big_. We can't leave a big feature to a name like "adaptTo". The New
 York Times won't have a headline like "adaptTo changes the name of the
 game".


 It's risky in my opinion to bet that it's going to be a feature big
 enough that everyone will remember what it means. Also, "duck" is a
 misnomer. The commonly-accepted meaning of duck typing is basically
 dynamic dispatch based on function names, and when the function doesn't
 exist it's a runtime error. I bet you'll get a ton of negative feedback
 for misrepresentation or deformation of the concept. That said, it could
 bring attention, but perhaps not the kind of attention you'd like.


interface Duck
{
     void walk();
     void quack();
}

class Whatsthis
{
     void walk();
     void quack();
}

auto a = duck!Duck(new Whatsthis);

It's duck typing all right. The term does not have an academic canonical 
name. I doubt this is ever going to cause a rumpus or be a source of 
confusion.


 Programmers like automated things. That feature should be called "magic
 adapters" or "cheap adapters"


*yawn*


 (or some variation of that) because it's
 an adapter and it's magic/cheap, and people can search "adapter" and
 immediately get hundreds of results explaining the concept. And the
 function name could be "adaptTo", or "adapt" (or "magic" if you want it
 to look funny).


Please substitute: "X does duck typing in the D programming language". 
What is X?

FWIW this was the story with "immutable". Walter got tired of 
explaining: "Invariant implements immutable types in the D programming 
language".


 And I think I agree with your arguments about "as" having problems.



 I'd go with the longer "ducktype". Length is not as important as
 evocative power and brand name!

 auto d = ducktype!Drawable(obj);


 At this point, why not call it ducktape™. Now that's a brand name.


Meh.


Andrei



 Oct 16 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Andrei Alexandrescu wrote:

 Please substitute: "X does duck typing in the D programming language". 
 What is X?
 
 FWIW this was the story with "immutable". Walter got tired of 
 explaining: "Invariant implements immutable types in the D programming 
 language".


Boy did I ever get tired of that. It's a classic example of names mattering - 
it's not just a bikeshed color.



 Oct 16 2010



  parent reply "abram" <abramw901 no_robots.net>  writes:


Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Please substitute: "X does duck typing in the D programming
 language". What is X?

 FWIW this was the story with "immutable". Walter got tired of
 explaining: "Invariant implements immutable types in the D
 programming language".


 Boy did I ever get tired of that. It's a classic example of names
 mattering - it's not just a bikeshed color.


Maybe you should explain "bikeshed". Did someone steal your bike? From 
your parent's shed? 



 Oct 16 2010



  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday 16 October 2010 23:13:52 abram wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Please substitute: "X does duck typing in the D programming
 language". What is X?
 
 FWIW this was the story with "immutable". Walter got tired of
 explaining: "Invariant implements immutable types in the D
 programming language".


 
 Boy did I ever get tired of that. It's a classic example of names
 mattering - it's not just a bikeshed color.


 
 Maybe you should explain "bikeshed". Did someone steal your bike? From
 your parent's shed?


http://en.wiktionary.org/wiki/bikeshedding



 Oct 17 2010



  parent  so <so so.do>  writes:


If you got opera "g define:bikeshedding", else google "define:bikeshedding"

On Sun, 17 Oct 2010 10:13:54 +0300, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Saturday 16 October 2010 23:13:52 abram wrote:

 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Please substitute: "X does duck typing in the D programming
 language". What is X?

 FWIW this was the story with "immutable". Walter got tired of
 explaining: "Invariant implements immutable types in the D
 programming language".


 Boy did I ever get tired of that. It's a classic example of names
 mattering - it's not just a bikeshed color.


 Maybe you should explain "bikeshed". Did someone steal your bike? From
 your parent's shed?


 http://en.wiktionary.org/wiki/bikeshedding



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



 Oct 18 2010



prev sibling  parent reply Roman Ivanov <isroman.del ete.km.ru>  writes:


On 10/16/2010 1:19 PM, Andrei Alexandrescu wrote:

 The problem with "adaptTo" is that, just like itoa or printf, it is too
 boring to have marketing value. I think the feature is going to be
 _big_. We can't leave a big feature to a name like "adaptTo". The New
 York Times won't have a headline like "adaptTo changes the name of the
 game".


IMO, you overestimate marketing value of function names.

The paramount concern with API naming should be clarity. Reading and
understanding code should be easy. Ideally, discussing code and
searching for examples online should be easy too.

Personally, I like when features are demonstrated by examples. The
clearer the example, the easier it is to convince me that the
language/API/code does something good.


 This is also part of my beef with "as" or "to" for the feature. "As" is
 difficult to talk about. "Oh my God, D has 'as'!" "Has ass?"


My problem with "as" would be different. When something has a two-letter
name (is, in, as, to, and so on) I tend to assume it's a language

for casting, for example.


 I'd go with the longer "ducktype". Length is not as important as
 evocative power and brand name!
 
 auto d = ducktype!Drawable(obj);
 
 99.99% of programmers will have an idea of what's going on.


ducktype is a bit better than duck.

Hm, how about this?

auto d = make!Drawable(obj);

Reads "make Drawable from obj".



 Oct 19 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/19/10 17:50 CDT, Roman Ivanov wrote:

 On 10/16/2010 1:19 PM, Andrei Alexandrescu wrote:

 The problem with "adaptTo" is that, just like itoa or printf, it is too
 boring to have marketing value. I think the feature is going to be
 _big_. We can't leave a big feature to a name like "adaptTo". The New
 York Times won't have a headline like "adaptTo changes the name of the
 game".


 IMO, you overestimate marketing value of function names.

 The paramount concern with API naming should be clarity. Reading and
 understanding code should be easy. Ideally, discussing code and
 searching for examples online should be easy too.

 Personally, I like when features are demonstrated by examples. The
 clearer the example, the easier it is to convince me that the
 language/API/code does something good.


 This is also part of my beef with "as" or "to" for the feature. "As" is
 difficult to talk about. "Oh my God, D has 'as'!" "Has ass?"


 My problem with "as" would be different. When something has a two-letter
 name (is, in, as, to, and so on) I tend to assume it's a language

 for casting, for example.


 I'd go with the longer "ducktype". Length is not as important as
 evocative power and brand name!

 auto d = ducktype!Drawable(obj);

 99.99% of programmers will have an idea of what's going on.


 ducktype is a bit better than duck.

 Hm, how about this?

 auto d = make!Drawable(obj);

 Reads "make Drawable from obj".


"make" has factory conotations. I think it's best to concede and call 
the artifact "adapt".

Andrei



 Oct 19 2010



 next sibling parent  "Simen kjaeraas" <simen.kjaras gmail.com>  writes:


Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 I think it's best to concede and call the artifact "adapt".


Aww. I liked duck.

-- 
Simen



 Oct 19 2010



prev sibling  parent  Roman Ivanov <isroman.del ete.km.ru>  writes:


On 10/19/2010 7:01 PM, Andrei Alexandrescu wrote:

 On 10/19/10 17:50 CDT, Roman Ivanov wrote:

 Hm, how about this?

 auto d = make!Drawable(obj);

 Reads "make Drawable from obj".


 
 "make" has factory conotations. I think it's best to concede and call
 the artifact "adapt".
 
 Andrei


It's true about factory connotations. I think "adapt" would work pretty
well as a name.

...

A good way of looking at API naming might be by recalling APIs for other
languages/libraries and trying to avoid the bad things they had.



 Oct 19 2010



prev sibling next sibling parent reply Kagamin <spam here.lot>  writes:


Walter Bright Wrote:


 One would think programmers are above all that, but we are not.


Ask people what they think about "cross-platform" .net ad campaign.



 Oct 16 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Kagamin wrote:

 Walter Bright Wrote:

 One would think programmers are above all that, but we are not.


 
 Ask people what they think about "cross-platform" .net ad campaign.


I don't know anything about that.



 Oct 16 2010



  parent  "abram" <abramw901 no_robots.net>  writes:


Walter Bright wrote:

 Kagamin wrote:

 Walter Bright Wrote:

 One would think programmers are above all that, but we are not.


 Ask people what they think about "cross-platform" .net ad campaign.


 I don't know anything about that.


Liar COM (and then some) guy. 



 Oct 16 2010



prev sibling next sibling parent reply lurker <lurk lu.rk>  writes:


Andrei Alexandrescu Wrote:


 I was talking to Walter about Kenji's adaptTo. We both think it's a very 
 powerful enabler, but adaptTo is a bland name. After discussing a few 
 marketing strategies, I proposed "duck". It's short, simple, and evokes 
 "duck typing".
 
 class C
 {
      int draw(){ return 10; }
 }
 interface Drawable
 {
      long draw();
 }
 ...
 auto c = new C;
 auto d = duck!Drawable(c);


Object c = new C;
auto d = duck!Drawable(c); // awes

does this work? After all, c is a C:

Object c = new C;
auto d = duck!Drawable(cast(C)c);

One fears this feature has little real world use. But it's a great way to add
additional bloat to the puny little Phobos...

It's amusing as always that the syntax is being discussed before we even know
how this works. How does the int -> long coercion work there? Any possibility
to get a written spec for this?



 Oct 16 2010



 next sibling parent  Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me>  writes:


lurker napisał:


 class C
 {
int draw(){ return 10; }
 }
 interface Drawable
 {
long draw();
 }
 ...
 auto c = new C;
 auto d = duck!Drawable(c);


 
 Object c = new C;
 auto d = duck!Drawable(c); // awes
 
 does this work? After all, c is a C:


I'd say no. c is an Object, you don't know it can draw().


 Object c = new C;
 auto d = duck!Drawable(cast(C)c);


Yeah, that's what you have to do.


 One fears this feature has little real world use. But it's a great way to
 add additional bloat to the puny little Phobos...
 
 It's amusing as always that the syntax is being discussed before we even
 know how this works. How does the int -> long coercion work there? Any
 possibility to get a written spec for this?


I got a similar feeling after seeing there's 70+ posts in this thread. There's 
not even a link to the source to know what one is naming.

For one thing, I'd like to know whether (Duck|As|AdaptTo)!I is a class 
implementing I or a struct mimicking I's API.

Or if in duck!I(a) a already implements I, does Duck alias itself away?

Or if in duck!I(a) a is a struct exposing I's methods (walks and quacks like 
I), does Duck alias itself away?

What if I has an alias this to one of its properties?

What if I has static methods?

-- 
Tomek



 Oct 17 2010



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/17/2010 01:54 AM, lurker wrote:

 Andrei Alexandrescu Wrote:


 I was talking to Walter about Kenji's adaptTo. We both think it's a
 very powerful enabler, but adaptTo is a bland name. After
 discussing a few marketing strategies, I proposed "duck". It's
 short, simple, and evokes "duck typing".

 class C { int draw(){ return 10; } } interface Drawable { long
 draw(); } ... auto c = new C; auto d = duck!Drawable(c);


 Object c = new C; auto d = duck!Drawable(c); // awes

 does this work? After all, c is a C:

 Object c = new C; auto d = duck!Drawable(cast(C)c);

 One fears this feature has little real world use. But it's a great
 way to add additional bloat to the puny little Phobos...

 It's amusing as always that the syntax is being discussed before we
 even know how this works. How does the int ->  long coercion work
 there? Any possibility to get a written spec for this?


Fair point, but the discussion started as simply naming a 
well-understood artifact. That was Kenji Hara's code here:

http://github.com/9rnsr/scrap/blob/master/interfaces/interfaces.d

Essentially what his function did was to offer a given interface on top 
of an object (that did not implement the interface). The mechanism for 
doing so was to generate simple forwarding functions.

 From there, the discussion sprawled into defining different similar 
functions, i.e. one that implements a given interface for a given object 
on a best-effort basis and throws for non-matched methods.

Discussion also extended into a completely dynamic facility that 
promises any method and uses runtime reflection (and exceptions) to 
implement dynamic typing. It has been rightly pointed out that Variant 
is the best type for that.

Once such functions will be integrated into Phobos, they will be 
properly documented. I think it's okay to keep the discussion loosely 
structured for now.


Andrei



 Oct 17 2010



prev sibling next sibling parent reply kenji hara <k.hara.pg gmail.com>  writes:


I tried to arrange Duck-typing Patterns in D .

interface Quack
{
    void quack();
}
class Duck : Quack
{
    void quack(){...}
}
class Human
{
    void quack(){...}
}

1. Static object type & static signature
    ----
    Duck d = new Duck;
    d.quack();
        // The type of object referenced by d is statically chosen.
        // --> Duck,
        // The type of variable d is statically chosen.
        // --> Duck.
        // Signature 'quack' statically chosen.
    ----
    This is built-in-supported in D.

    Using template like this is included in this pattern:
    void f(T)(T t)
    {
        T.quack();
    }
    T and quack are bound statically.

2. Static object type & structural signature
    included in 5.

3. Static object type & dynamic signature
    included in 6.

4. Dynamic object type & static signature
    ----
    Quack q = new Duck;
    q.quack();
        // The type of object referenced by q is dynamically chosen.
        // --> extends Quack, like Duck,
        // The type of variable q is statically chosen.
        // --> Quack.
        // Signature 'quack' statically chosen.
    ----
    This is built-in-supported in D.

5. Dynamic object type & static/structural signature
    ----
    Quack q = adaptTo!Quack(new Duck());
    q.quack();
    q = adaptTo!Quack(new Human());
    q.quack();
        // The type of object referenced by q is dynamically chosen.
        // --> Structural conformance with Quack, like Duck, Human.
        // The type of variable q is statically chosen.
        // --> Quack.
        // Signature 'quack' statically chosen.
    ----
    Currently, adaptTo supports this pattern.

    adaptTo realizes structural conformance through using static
conformance of interface.
    It is belong to implementation decision.

6. Dynamic object type & dynamic signature
    ----
    X x;
        // x does not assume any signatures.
    x = new Duck();
    invoke(x, "quack"); // calls Duck.quack()
    invoke(x, "undef"); // throws runtime-exception

        // x can have like following templates:
        //  void opDispatch(string s)(){
        //      invoke(this, s);
        //  }
        // By using this, X can convert static/structural signature to
dynamic one.
    x.quack();          // calls Duck.quack()
    x.udnef();          // throws runtime-exception

    x = new Human();
    x.quack();          // calls Human.quack()
    invoke(x, "quack"); // calls Human.quack()
    ----

    std.variant only supports part of this pattern, it is limited
operator overloading.
    Implementing this needs runtime-reflection, so we can't support
    this pattern perfectly in current D, since my sample code does not work.

'duck' may be funny, but not accurate.

P.S.
I researched interface in Go language.
(via http://golang.org/doc/go_for_cpp_programmers.html#Interfaces),
I think it is closest to 5 than others.
But it does not called 'Duck-Typing' or 'duck'.

http://www.google.com/search?as_q=duck+typing&hl=en&as_sitesearch=golang.org%2Fdoc%2F
Searching result in go-lang doc matches none.

Kenji Hara



 Oct 17 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/17/2010 05:15 AM, kenji hara wrote:

 I tried to arrange Duck-typing Patterns in D .

 interface Quack
 {
      void quack();
 }
 class Duck : Quack
 {
      void quack(){...}
 }
 class Human
 {
      void quack(){...}
 }

 1. Static object type&  static signature


[snip]


 2. Static object type&  structural signature
      included in 5.

 3. Static object type&  dynamic signature
      included in 6.

 4. Dynamic object type&  static signature


[snip]


 5. Dynamic object type&  static/structural signature
      ----
      Quack q = adaptTo!Quack(new Duck());
      q.quack();
      q = adaptTo!Quack(new Human());
      q.quack();
          // The type of object referenced by q is dynamically chosen.
          // -->  Structural conformance with Quack, like Duck, Human.
          // The type of variable q is statically chosen.
          // -->  Quack.
          // Signature 'quack' statically chosen.
      ----
      Currently, adaptTo supports this pattern.


Yup. Nice.


      adaptTo realizes structural conformance through using static
 conformance of interface.
      It is belong to implementation decision.

 6. Dynamic object type&  dynamic signature
      ----
      X x;
          // x does not assume any signatures.
      x = new Duck();
      invoke(x, "quack"); // calls Duck.quack()
      invoke(x, "undef"); // throws runtime-exception

          // x can have like following templates:
          //  void opDispatch(string s)(){
          //      invoke(this, s);
          //  }
          // By using this, X can convert static/structural signature to
 dynamic one.
      x.quack();          // calls Duck.quack()
      x.udnef();          // throws runtime-exception

      x = new Human();
      x.quack();          // calls Human.quack()
      invoke(x, "quack"); // calls Human.quack()
      ----

      std.variant only supports part of this pattern, it is limited
 operator overloading.
      Implementing this needs runtime-reflection, so we can't support
      this pattern perfectly in current D, since my sample code does not work.


Correct. Could you please submit the appropriate bug report(s) so this 
is looked into?

Actually Variant can be made to support calls by using compile-time 
reflection, as long as the type during assignment is known. Consider:

Variant v;
v = new Human;

At assignment time, v knows the static type of Human and can store a map 
with "quack"'s signature. Later on, if you say v.quack(), the Variant 
will access the map and find the right method.

The scenario that needs runtime reflection is this:

Variant v;
v = cast(Object) new Human;

At this point all static information is lost at assignment time.


 'duck' may be funny, but not accurate.

 P.S.
 I researched interface in Go language.
 (via http://golang.org/doc/go_for_cpp_programmers.html#Interfaces),
 I think it is closest to 5 than others.
 But it does not called 'Duck-Typing' or 'duck'.

 http://www.google.com/search?as_q=duck+typing&hl=en&as_sitesearch=golang.org%2Fdoc%2F
 Searching result in go-lang doc matches none.


I wouldn't want the creator of the facility himself to be unhappy about 
the name. Here's a thought - I suggest we call your function simply 
"adapt". Later on we might add an extra parameter to it that controls 
strictness. Works?


Andrei



 Oct 17 2010



prev sibling next sibling parent  bearophile <bearophileHUGS lycos.com>  writes:


I was busy, so just two comments about this long thread.

Walter Bright:


 A lot of people do think duck typing is very important.


But it's better to add features to D because they are useful for D programs,
and not because lot of people want "duck typing" in general.


is powerful and very well integrated with the rest of the language and virtual

substance:
http://msdn.microsoft.com/en-us/library/dd264736.aspx

If you want you may use Google to find other better pages about the "dynamic"


-----------------------

Andrej Mitrovic


 What's all this arguing about anyway?
 
 import std.conv : duck;
 
 alias duck as;
 alias duck adaptTo;
 
 Done deal.


That's false/misleading. I've once renamed "writeln" as "putr" in one of my
code snippets and Walter answered me he didn't know what "putr" means despite
the first line in the 10-lines long program was the
import std.stdio: putr = writeln;

"alias" is useful, but it's also misleading. Usually if you want your code to
be easy to understand you have to stick with the default names that everyone
else uses.

Something partially related, about abuse of typedef in Linux kernel:
http://lkml.indiana.edu/hypermail/linux/kernel/0206.1/0402.html

Bye,
bearophile



 Oct 17 2010



prev sibling  parent  #ponce <spam spam.org>  writes:


It would be ironic to call it go instead of duck. 
- it helps memorizing what it does 
- it's a funny reminder of the Go vs Go! naming issue with D template
instanciation (!)
- "we can do that, with templates"


 auto d = go!Drawable(c); // awes


Andrei Alexandrescu Wrote:


 I was talking to Walter about Kenji's adaptTo. We both think it's a very 
 powerful enabler, but adaptTo is a bland name. After discussing a few 
 marketing strategies, I proposed "duck". It's short, simple, and evokes 
 "duck typing".
 
 class C
 {
      int draw(){ return 10; }
 }
 interface Drawable
 {
      long draw();
 }
 ...
 auto c = new C;
 auto d = duck!Drawable(c); // awes
 
 Kenji, I'll be looking forward to your submission :o). Would be great to 
 allow structs to duck, too!
 
 
 Andrei





 Oct 18 2010