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
next sibling parent 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
prev sibling 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 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 next 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 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 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"?
 

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"?
 

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 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
prev sibling next sibling parent 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
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 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
prev sibling next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Kagamin wrote:
 Andrei Alexandrescu Wrote:
=20
 I was talking to Walter about Kenji's adaptTo. We both think it's a ve=


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


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


 "duck typing".

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

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

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 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 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 "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
prev sibling next sibling 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.

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 Andrew Wiley <debio264 gmail.com> writes:
--485b393ab0f324d9ff0494ca44e1
Content-Type: text/plain; charset=ISO-8859-1

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

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 --485b393ab0f324d9ff0494ca44e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Thu, Nov 11, 2010 at 10:01 AM, Bruno Medeiros= <span dir=3D"ltr">&lt;brunodomedeiros+spam com.gmail&gt;</span> wrote:<br>= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> <div class=3D"im">On 11/11/2010 14:19, Bruno Medeiros wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> way in the future. I think dynamic languages are somewhat of a niche<br> (even if a growing one), but not really heading to be mainstream in<br> medium/large scale projects.<br> </blockquote> <br></div> Sorry, I actually meant &quot;I think dynamic _typing_ is somewhat of a nic= he&quot; rather than the above. Yes, the two are closely related, but they = are not the same.<br> For example, I wouldn&#39;t be surprised if in the future certain dynamical= ly-typed languages gain some static-typing capabilities. (like the inverse = is happening)<br><font color=3D"#888888"> <br></font></blockquote><div><br></div><div>From reading about this, it see= ms like what D has is very similar to what Scala calls &quot;Structural Typ= ing&quot; (see=A0<a href=3D"http://codemonkeyism.com/scala-goodness-structu= ral-typing/">http://codemonkeyism.com/scala-goodness-structural-typing/</a>= ). The difference is that Scala tends to use structural typing with inline = type declarations (although they don&#39;t have to be inline). However, the= basic concept is the same, where a class is dynamically checked for compli= ance with a static type. Not quite dynamic typing, but definitely related.<= /div> <div>If you&#39;re after a more accurate description, how would that work?<= /div><div><br></div><div>Andrew Wiley=A0</div></div><br> --485b393ab0f324d9ff0494ca44e1--
Nov 11 2010
prev sibling parent Andrew Wiley <debio264 gmail.com> writes:
--485b393aafa5d740c30494ca52cd
Content-Type: text/plain; charset=ISO-8859-1

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)

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. --485b393aafa5d740c30494ca52cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Nov 11, 2010 at 11:25 AM, Andrew= Wiley <span dir=3D"ltr">&lt;<a href=3D"mailto:debio264 gmail.com">debio264= gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"gmail_quote"><div><div></div><div class=3D"h5">On Thu, Nov 11= , 2010 at 10:01 AM, Bruno Medeiros <span dir=3D"ltr">&lt;brunodomedeiros+sp= am com.gmail&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>On 11/11/2010 14:19, Bruno Medeiros wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> way in the future. I think dynamic languages are somewhat of a niche<br> (even if a growing one), but not really heading to be mainstream in<br> medium/large scale projects.<br> </blockquote> <br></div> Sorry, I actually meant &quot;I think dynamic _typing_ is somewhat of a nic= he&quot; rather than the above. Yes, the two are closely related, but they = are not the same.<br> For example, I wouldn&#39;t be surprised if in the future certain dynamical= ly-typed languages gain some static-typing capabilities. (like the inverse = is happening)<br><font color=3D"#888888"> <br></font></blockquote><div><br></div></div></div><div>From reading about = this, it seems like what D has is very similar to what Scala calls &quot;St= ructural Typing&quot; (see=A0<a href=3D"http://codemonkeyism.com/scala-good= ness-structural-typing/" target=3D"_blank">http://codemonkeyism.com/scala-g= oodness-structural-typing/</a>). The difference is that Scala tends to use = structural typing with inline type declarations (although they don&#39;t ha= ve 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 ty= ping, but definitely related.</div> <div>If you&#39;re after a more accurate description, how would that work?<= /div><div><br></div><div>Andrew Wiley=A0</div></div></blockquote><div><br><= /div><div>Actually, that&#39;s wrong, as the class is statically checked fo= r compliance with a static type, but still.=A0</div> </div> --485b393aafa5d740c30494ca52cd--
Nov 11 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:
--0015174c39602ddfce0492aed86e
Content-Type: text/plain; charset=ISO-8859-1

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.

--0015174c39602ddfce0492aed86e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It doesn&#39;t matter if it sounds unintuitive to you right now,<div>eventu= ally if you keep using it, the word will stick.</div><div>duck! is a nice n= ame, so I&#39;m fine with the idea.<br><br><div class=3D"gmail_quote">On Fr= i, Oct 15, 2010 at 4:46 PM, JimBob <span dir=3D"ltr">&lt;<a href=3D"mailto:= jim bob.com">jim bob.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im"><br> &quot;Andrei Alexandrescu&quot; &lt;<a href=3D"mailto:SeeWebsiteForEmail er= dani.org">SeeWebsiteForEmail erdani.org</a>&gt; wrote in message<br> news:i9ae2n$k9g$1 digitalmars.com...<br> </div><div><div></div><div class=3D"h5">&gt;I was talking to Walter about K= enji&#39;s adaptTo. We both think it&#39;s a very<br> &gt;powerful enabler, but adaptTo is a bland name. After discussing a few<b= r> &gt;marketing strategies, I proposed &quot;duck&quot;. It&#39;s short, simp= le, and evokes<br> &gt;&quot;duck typing&quot;.<br> &gt;<br> &gt; class C<br> &gt; {<br> &gt; =A0 =A0 int draw(){ return 10; }<br> &gt; }<br> &gt; interface Drawable<br> &gt; {<br> &gt; =A0 =A0 long draw();<br> &gt; }<br> &gt; ...<br> &gt; auto c =3D new C;<br> &gt; auto d =3D duck!Drawable(c); // awes<br> &gt;<br> &gt; Kenji, I&#39;ll be looking forward to your submission :o). Would be gr= eat to<br> &gt; allow structs to duck, too!<br> <br> </div></div>duck doesnt convey much meaning imo so.. why not &quot;adapt!&q= uot;<br> <br> Ties in with the Adaptor design pattern.. which i&#39;m guessing is what it= <br> actualy does.<br> <br> <br> </blockquote></div><br></div> --0015174c39602ddfce0492aed86e--
Oct 15 2010
parent "JimBob" <jim bob.com> writes:
Content-Type: text/plain;
	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 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
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 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

auto d = as!Drawable(c); Christof

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

Nice name. It can be confused with the dynamic cast operator by some C# users but that is probably a non-issue.
Oct 16 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:
 Groovy uses [...]

!!!
Oct 16 2010
prev sibling next sibling parent 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
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 Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

Nice name. It can be confused with the dynamic cast operator by some C#=

 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
prev sibling next sibling parent Seth Hoenig <seth.a.hoenig gmail.com> writes:
--90e6ba6139d46210190492bcf4a4
Content-Type: text/plain; charset=ISO-8859-1

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

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. --90e6ba6139d46210190492bcf4a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sat, Oct 16, 2010 at 9:01 AM, Andrei = Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erd= ani.org">SeeWebsiteForEmail erdani.org</a>&gt;</span> wrote:<br><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex;"> <div class=3D"im">On 10/16/10 2:30 CDT, Christof Schardt wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> auto d =3D duck!Drawable(c); // awes<br> </blockquote> <br> What about &quot;as&quot; ?<br> <br> auto d =3D as!Drawable(c);<br> </blockquote> <br></div> Nice too, and evokes &quot;to&quot;. &quot;to&quot; was a success in spite = of the fact that it&#39;s difficult to talk about (e.g. &quot;Could you use= &#39;to&#39;?&quot; &quot;To what?&quot; etc). I still prefer &quot;duck&q= uot; because it doesn&#39;t have this problem.<br> </blockquote><div><br></div><div><br></div><div>=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex;"> <br> Speaking of which, it looks like std.conv is a good place to put duck in.<b= r><font color=3D"#888888"> <br> <br> Andrei<br> <br></font></blockquote><div>=A0</div></div>Hmm.. I was going to suggest /d= ev/null but I suppose that works too. If we have to have it, I would vote f= or &quot;as&quot; over &quot;duck&quot; simply because duck can be interpre= ted either a noun with only metaphorical=A0relevance=A0or as a verb with no= =A0relevance=A0at all. On the other hand, &quot;as&quot; is simple and gets= the point across.=A0 --90e6ba6139d46210190492bcf4a4--
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 it with the "as" casting operator in C#.
Oct 16 2010
prev sibling next sibling parent "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
prev sibling next sibling 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 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

auto d = as!Drawable(c); Christof

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 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
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 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 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 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
prev sibling next sibling parent 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
prev sibling 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 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 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 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/16/2010 05:57 PM, kenji hara wrote:
 Current dmd does not enough support runtime reflection.

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 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.

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 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 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 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
next sibling 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.


That makes me curious about the etymology of duckduckgo.com !
Oct 16 2010
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.


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

Sympathy plea?
Oct 16 2010
prev 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 next sibling parent 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
prev sibling next sibling 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 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
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 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
next sibling parent "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
prev sibling next sibling parent 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
prev sibling 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 next 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 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 keyword, unless I know the language enough to say it's not. C# uses "as" 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 keyword, unless I know the language enough to say it's not. C# uses "as" 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
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 parent 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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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.

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
prev sibling next sibling parent 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.

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 Jimmy Cao <jcao219 gmail.com> writes:
--0015174a0fc6aff6670492c0c42c
Content-Type: text/plain; charset=ISO-8859-1

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.

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/

--0015174a0fc6aff6670492c0c42c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it&#39;s safe to say this is pretty much duck-typing in D (?)<div>S= o then, if duck! is used, it puts emphasis on what the function allows D to= do (duck-typing),</div><div>while if as! is used, it sounds more intuitive= (kinda like &quot;.respond_to?&quot; in Ruby) .</div> <div><br></div><div>So going with my previous statement,</div><div>if you k= eep using duck!, or adaptTo!, or whatever this becomes, it will eventually = stick and will sound intuitive no matter what.</div><div>In that way, I thi= nk as! is not necessarily such a good choice.</div> <div><br></div><div>Also, I really agree with Kagamin and Walter&#39;s argu= ment, that simply the name &quot;duck!&quot; would raise awareness for this= features.<br><br><div class=3D"gmail_quote">2010/10/16 so <span dir=3D"ltr= ">&lt;so so.do&gt;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Reading wikipedia, definition and the examp= les exactly match adaptTo. Before naming it, i think we should first be cle= ar about if it is really duck-typing or not.<div> <div></div><div class=3D"h5"><br> <br> On Sat, 16 Oct 2010 21:44:51 +0300, Michel Fortin &lt;<a href=3D"mailto:mic= hel.fortin michelf.com" target=3D"_blank">michel.fortin michelf.com</a>&gt;= wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 2010-10-16 14:32:10 -0400, Walter Bright &lt;<a href=3D"mailto:newshound= 2 digitalmars.com" target=3D"_blank">newshound2 digitalmars.com</a>&gt; sai= d:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Nobody is going to start using D because it has a function *named* duck.<br=

=A0Maybe not, but it will raise awareness that &quot;D has duck typing&quot= ;. Otherwise, I guarantee you that people will argue that &quot;I need duck= typing, and Z has it and D does not&quot; if it is named adaptTo.<br> </blockquote> <br> The problem is that D doesn&#39;t have duck-typing. The adapter pattern isn= &#39;t duck-typing. Duck-typing is when you have an object and can call a &= #39;quack&#39; function on it and if there&#39;s no &#39;quack&#39; functio= n you get a runtime error.<br> <br> It&#39;s like saying D is a dynamic language, people will know you&#39;re b= ullshitting them.<br> <br> </blockquote> <br> <br> -- <br></div></div><div><div></div><div class=3D"h5"> Using Opera&#39;s revolutionary e-mail client: <a href=3D"http://www.opera.= com/mail/" target=3D"_blank">http://www.opera.com/mail/</a><br> </div></div></blockquote></div><br></div> --0015174a0fc6aff6670492c0c42c--
Oct 16 2010
prev sibling next 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.

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 Jimmy Cao <jcao219 gmail.com> writes:
--90e6ba5bb913013ac60492c0de63
Content-Type: text/plain; charset=ISO-8859-1

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?

--90e6ba5bb913013ac60492c0de63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable According to wikipedia,<div>duck typing is a style of dynamic typing where = an object&#39;s methods/properties determine what i can do.</div><div><br><= div class=3D"gmail_quote">On Sat, Oct 16, 2010 at 2:14 PM, Kagamin <span di= r=3D"ltr">&lt;spam here.lot&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">Michel Fortin Wrote:<br> <br> &gt; The problem is that D doesn&#39;t have duck-typing. The adapter patter= n<br> &gt; isn&#39;t duck-typing. Duck-typing is when you have an object and can = call<br> &gt; a &#39;quack&#39; function on it and if there&#39;s no &#39;quack&#39;= function you get a<br> &gt; runtime error.<br> <br> </div>Isn&#39;t that dynamic typing?<br> </blockquote></div><br></div> --90e6ba5bb913013ac60492c0de63--
Oct 16 2010
prev sibling next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
--0015174c3bf804bc850492c10909
Content-Type: text/plain; charset=ISO-8859-1

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.

--0015174c3bf804bc850492c10909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Haha!<br><div>But many people consider the interface system in Go as duck-t= yping,</div><div>so imo duck! is a very suitable name.<br><div><br><div cla= ss=3D"gmail_quote">On Sat, Oct 16, 2010 at 2:25 PM, Adam D. Ruppe <span dir= =3D"ltr">&lt;<a href=3D"mailto:destructionator gmail.com">destructionator g= mail.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"im">&gt; The problem is that = D doesn&#39;t have duck-typing.<br> <br> </div>But it does and it has for a long time:<br> <br> void func(A)(A a) {<br> =A0 a.quack();<br> }<br> <br> This new thing looks to me to be more like Go typing (lol?), where objects = fulfill<br> interfaces without explicit templates on the functions nor decorations on t= he<br> class. Here&#39;s a name!<br> <br> go!IWhatever(myclass)<br> <br> hahaha.<br> </blockquote></div><br></div></div> --0015174c3bf804bc850492c10909--
Oct 16 2010
prev sibling next sibling parent 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
prev sibling 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 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
prev sibling next sibling parent "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.

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
prev sibling next sibling parent 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=

 Steven Schveighoffer wrote:

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

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 =

zh" files never caught on.
 =A0These are completely unsubstantiated statements focused on a very narr=

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=

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=

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=

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=

ammers are above all that.
 But were there functions named zoomTechnology() and smartLink()? =A0Were =

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=

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 =

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=

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


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

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

. =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=

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

ous or the tool that made zip famous?
 =A0Let's also not forget the hundreds, probably thousands, of 'cute' name=

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

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=

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

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=

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=

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
prev sibling next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
--90e6ba5bb90bc682740492c32d87
Content-Type: text/plain; charset=ISO-8859-1

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.

--90e6ba5bb90bc682740492c32d87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The very important principle here for the naming is making it obvious that = D supports an element of duck-typing.<div>Naming it duck! does just that.</= div><div>Advertisability is not what I would use to describe it. =A0How abo= ut clarity, articulateness, and lucidity?</div> <div><br><div class=3D"gmail_quote">On Sat, Oct 16, 2010 at 4:52 PM, Michae= l Chen <span dir=3D"ltr">&lt;<a href=3D"mailto:sth4nth gmail.com">sth4nth g= mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> totally agreeed. let advertisability to influence a function name is<br> ridiculous to me. you gotta have some princeple for names, but<br> advertisability? i dont think so.</blockquote></div></div> --90e6ba5bb90bc682740492c32d87--
Oct 16 2010
prev sibling next sibling parent 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=

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

 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
prev sibling next sibling parent 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
prev sibling next sibling parent "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.

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
prev sibling next sibling 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 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

 2. Static object type&  structural signature
      included in 5.

 3. Static object type&  dynamic signature
      included in 6.

 4. Dynamic object type&  static signature

 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 "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 "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 "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