Re: duck!
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
Re: duck!
On 16/10/2010 21:30, Michel Fortin wrote: On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu seewebsiteforem...@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
Re: duck!
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
Re: duck!
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
Re: duck!
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
Re: duck!
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
Re: duck!
On Thu, Nov 11, 2010 at 10:01 AM, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 11/11/2010 14:19, Bruno Medeiros wrote: way in the future. I think dynamic languages are somewhat of a niche (even if a growing one), but not really heading to be mainstream in medium/large scale projects. Sorry, I actually meant I think dynamic _typing_ is somewhat of a niche rather than the above. Yes, the two are closely related, but they are not the same. For example, I wouldn't be surprised if in the future certain dynamically-typed languages gain some static-typing capabilities. (like the inverse is happening) From reading about this, it seems like what D has is very similar to what Scala calls Structural Typing (see http://codemonkeyism.com/scala-goodness-structural-typing/). The difference is that Scala tends to use structural typing with inline type declarations (although they don't have to be inline). However, the basic concept is the same, where a class is dynamically checked for compliance with a static type. Not quite dynamic typing, but definitely related. If you're after a more accurate description, how would that work? Andrew Wiley
Re: duck!
On Thu, Nov 11, 2010 at 11:25 AM, Andrew Wiley debio...@gmail.com wrote: On Thu, Nov 11, 2010 at 10:01 AM, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 11/11/2010 14:19, Bruno Medeiros wrote: way in the future. I think dynamic languages are somewhat of a niche (even if a growing one), but not really heading to be mainstream in medium/large scale projects. Sorry, I actually meant I think dynamic _typing_ is somewhat of a niche rather than the above. Yes, the two are closely related, but they are not the same. For example, I wouldn't be surprised if in the future certain dynamically-typed languages gain some static-typing capabilities. (like the inverse is happening) From reading about this, it seems like what D has is very similar to what Scala calls Structural Typing (see http://codemonkeyism.com/scala-goodness-structural-typing/). The difference is that Scala tends to use structural typing with inline type declarations (although they don't have to be inline). However, the basic concept is the same, where a class is dynamically checked for compliance with a static type. Not quite dynamic typing, but definitely related. If you're after a more accurate description, how would that work? Andrew Wiley Actually, that's wrong, as the class is statically checked for compliance with a static type, but still.
Re: Duck typing for structs
Ash Logan: but I wanted to see what the D community thought of it. Just a question. Aren't lines like: if (is(typeof(candidate) == const)) Better as static ifs? Bye, bearophile
Re: Duck typing for structs
On 10/21/2010 12:58 PM, bearophile wrote: Just a question. Aren't lines like: if (is(typeof(candidate) == const)) Better as static ifs? Bye, bearophile Probably they are; this was my first try at compile-time functions, and while writing it I kept crossing the line between what could and could not be evaluated at compile-time/as a condition to a static if, so I made most of the ifs non-static until I got it working. -- Ash
Re: duck!
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.
Re: duck!
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
Re: duck!
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I think it's best to concede and call the artifact adapt. Aww. I liked duck. -- Simen
Re: duck!
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.
Re: duck!
If you got opera g define:bikeshedding, else google define:bikeshedding On Sun, 17 Oct 2010 10:13:54 +0300, Jonathan M Davis jmdavisp...@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/
Re: duck!
It would be ironic to call it go instead of duck.
- it helps memorizing what it does
- it's a funny reminder of the Go vs Go! naming issue with D template
instanciation (!)
- we can do that, with templates
auto d = go!Drawable(c); // awes
Andrei Alexandrescu Wrote:
I was talking to Walter about Kenji's adaptTo. We both think it's a very
powerful enabler, but adaptTo is a bland name. After discussing a few
marketing strategies, I proposed duck. It's short, simple, and evokes
duck typing.
class C
{
int draw(){ return 10; }
}
interface Drawable
{
long draw();
}
...
auto c = new C;
auto d = duck!Drawable(c); // awes
Kenji, I'll be looking forward to your submission :o). Would be great to
allow structs to duck, too!
Andrei
Re: duck!
On Sat, 16 Oct 2010 18:04:23 -0400, Walter Bright newshou...@digitalmars.com wrote: Steven Schveighoffer wrote: On Sat, 16 Oct 2010 16:31:34 -0400, Walter Bright newshou...@digitalmars.com wrote: If I google for adapt for D I'll get a hopeless mess of irrelevant links. duck typing for D should be much better. Remember that google ranks pages by relevance, and searching for duck will give higher ranking for pages with duck in the url, title, headings, etc. That's just what we want. And it should come up with the page on digitalmars.com titled 'duck typing in D' which describes how to use templates or the adaptTo type to achieve duck typing. When writing fiction, it's a good idea to constantly shift which words used to describe something. But when writing tech manuals, and when making things search engine friendly, it pays to use a single term and use it consistently. For example, once upon a time I read some article on arrays, and it variously referred to the array elements, entries, and values. Really, that sucked, as the reader was left being not quite sure if they meant the same thing or not. If you expect people to search for duck typing (and I do) then why stick another level of indirection? Call it a duck. When you find yourself constantly saying duck typing: see adaptTo, then you named it wrong. Is this a case of foresight is 20/20? Look, you can't predict the future, and knowing what you will constantly be saying isn't possible. You could constantly be saying 'yeah, I know duck isn't the only way to do duck typing in D, but we felt it was a good descriptive name.' And not having to constantly say anything isn't proof that you have preemptively avoided it. But it doesn't matter anyways. My point is, marketing has nothing to do with naming functions. People will not decide to use or not use a language based on a function name. If the name describes the function properly, then it will not be noticed as a defect, and few will have problems with it. All three suggestions (adaptTo, as, and duck) satisfy this IMO, so really this argument has nothing to do with the name. It's all about the incorrect belief that the name itself will somehow be seen as a marketing benefit. You're making a lake out of a duck pond ;) -Steve
Re: duck!
On Sat, 16 Oct 2010 17:50:53 -0400, Andrei Alexandrescu seewebsiteforem...@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
Re: duck!
On Sat, 16 Oct 2010 18:20:37 -0400, Walter Bright newshou...@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
Re: duck!
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!).
Re: duck!
Walter Bright wrote: Andrei Alexandrescu wrote: On 10/16/2010 03:26 PM, Walter Bright wrote: A lot of people do think duck typing is very important. It's the defining feature of Go. That makes me curious about the etymology of duckduckgo.com ! Sympathy plea?
Re: duck!
Andrei Alexandrescu wrote: On 10/16/2010 12:38 PM, Steven Schveighoffer wrote: On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@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!
Re: duck!
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?
Re: duck!
Walter Bright wrote: Kagamin wrote: Walter Bright Wrote: One would think programmers are above all that, but we are not. Ask people what they think about cross-platform .net ad campaign. I don't know anything about that. Liar COM (and then some) guy.
Re: duck!
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?
Re: duck!
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
Re: duck!
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.
Re: duck!
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+typinghl=enas_sitesearch=golang.org%2Fdoc%2F
Searching result in go-lang doc matches none.
Kenji Hara
Re: duck!
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
Re: duck!
On 10/17/2010 05:15 AM, kenji hara wrote:
I tried to arrange Duck-typing Patterns in D .
interface Quack
{
void quack();
}
class Duck : Quack
{
void quack(){...}
}
class Human
{
void quack(){...}
}
1. Static object type static signature
[snip]
2. Static object type structural signature
included in 5.
3. Static object type dynamic signature
included in 6.
4. Dynamic object type static signature
[snip]
5. Dynamic object type static/structural signature
Quack q = adaptTo!Quack(new Duck());
q.quack();
q = adaptTo!Quack(new Human());
q.quack();
// The type of object referenced by q is dynamically chosen.
// -- Structural conformance with Quack, like Duck, Human.
// The type of variable q is statically chosen.
// -- Quack.
// Signature 'quack' statically chosen.
Currently, adaptTo supports this pattern.
Yup. Nice.
adaptTo realizes structural conformance through using static
conformance of interface.
It is belong to implementation decision.
6. Dynamic object type dynamic signature
X x;
// x does not assume any signatures.
x = new Duck();
invoke(x, quack); // calls Duck.quack()
invoke(x, undef); // throws runtime-exception
// x can have like following templates:
// void opDispatch(string s)(){
// invoke(this, s);
// }
// By using this, X can convert static/structural signature to
dynamic one.
x.quack(); // calls Duck.quack()
x.udnef(); // throws runtime-exception
x = new Human();
x.quack(); // calls Human.quack()
invoke(x, quack); // calls Human.quack()
std.variant only supports part of this pattern, it is limited
operator overloading.
Implementing this needs runtime-reflection, so we can't support
this pattern perfectly in current D, since my sample code does not work.
Correct. Could you please submit the appropriate bug report(s) so this
is looked into?
Actually Variant can be made to support calls by using compile-time
reflection, as long as the type during assignment is known. Consider:
Variant v;
v = new Human;
At assignment time, v knows the static type of Human and can store a map
with quack's signature. Later on, if you say v.quack(), the Variant
will access the map and find the right method.
The scenario that needs runtime reflection is this:
Variant v;
v = cast(Object) new Human;
At this point all static information is lost at assignment time.
'duck' may be funny, but not accurate.
P.S.
I researched interface in Go language.
(via http://golang.org/doc/go_for_cpp_programmers.html#Interfaces),
I think it is closest to 5 than others.
But it does not called 'Duck-Typing' or 'duck'.
http://www.google.com/search?as_q=duck+typinghl=enas_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
Re: duck!
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.
Re: duck!
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
Re: duck!
I was busy, so just two comments about this long thread. Walter Bright: A lot of people do think duck typing is very important. But it's better to add features to D because they are useful for D programs, and not because lot of people want duck typing in general. C#4 has added the dynamic keyword, its not named WizBang!, and its semantics is powerful and very well integrated with the rest of the language and virtual machine. This is how C# is better than D both in nomenclature style and in substance: http://msdn.microsoft.com/en-us/library/dd264736.aspx If you want you may use Google to find other better pages about the dynamic of C#4. --- Andrej Mitrovic What's all this arguing about anyway? import std.conv : duck; alias duck as; alias duck adaptTo; Done deal. That's false/misleading. I've once renamed writeln as putr in one of my code snippets and Walter answered me he didn't know what putr means despite the first line in the 10-lines long program was the import std.stdio: putr = writeln; alias is useful, but it's also misleading. Usually if you want your code to be easy to understand you have to stick with the default names that everyone else uses. Something partially related, about abuse of typedef in Linux kernel: http://lkml.indiana.edu/hypermail/linux/kernel/0206.1/0402.html Bye, bearophile
Re: duck!
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
Re: duck!
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
Re: duck!
auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Christof
Re: duck!
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
Re: duck!
On 2010-10-16 03:30:27 -0400, Christof Schardt csn...@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.for...@michelf.com http://michelf.com/
Re: duck!
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.
Re: duck!
On 16/10/2010 11:03 PM, Michel Fortin wrote: On 2010-10-16 03:30:27 -0400, Christof Schardt csn...@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
Re: duck!
On 2010-10-16 08:41:26 -0400, Justin Johansson n...@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.for...@michelf.com http://michelf.com/
Re: duck!
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*
Re: duck!
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
Re: duck!
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
Re: duck!
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
Re: duck!
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?
Re: duck!
On Sat, 2010-10-16 at 15:25 +0300, Max Samukha wrote:
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.
Groovy uses as as a conversion operator. cf.
def x = [ run : { println ( 'Hello World.' ) } ] as Thread
x.start ( )
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: duck!
On Sat, Oct 16, 2010 at 9:01 AM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 10/16/10 2:30 CDT, Christof Schardt wrote: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Nice too, and evokes to. to was a success in spite of the fact that it's difficult to talk about (e.g. Could you use 'to'? To what? etc). I still prefer duck because it doesn't have this problem. Speaking of which, it looks like std.conv is a good place to put duck in. Andrei Hmm.. I was going to suggest /dev/null but I suppose that works too. If we have to have it, I would vote for as over duck simply because duck can be interpreted either a noun with only metaphorical relevance or as a verb with no relevance at all. On the other hand, as is simple and gets the point across.
Re: duck!
On 2010-10-16 09:54:50 -0400, Andrei Alexandrescu seewebsiteforem...@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.for...@michelf.com http://michelf.com/
Re: duck!
On Sat, 16 Oct 2010 09:30:27 +0200, Christof Schardt csn...@schardt.info wrote: auto d = as!Drawable(c); My turn: auto d = implements!Drawable(c);
Re: duck!
On Sat, 16 Oct 2010 03:30:27 -0400, Christof Schardt csn...@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
Re: duck!
I feel as and to are too similar, they could both be interpreted as simple casting for example.
Re: duck!
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
Re: duck!
On 16/10/10 4:24 PM, Juanjo Alvarez wrote: On Sat, 16 Oct 2010 09:30:27 +0200, Christof Schardt csn...@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#.
Re: duck!
On Sat, 16 Oct 2010 00:37:10 +0400, Andrei Alexandrescu
seewebsiteforem...@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.
Re: duck!
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.
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'?
I hope helpful.
Kenji Hara
2010/10/16 Andrei Alexandrescu seewebsiteforem...@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
{
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
Re: duck!
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. Both make duck a very good name for it, considering some other name choices in D... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: duck!
kenji hara k.hara...@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
Re: duck!
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
Re: duck!
On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@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
Re: duck!
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!!
Re: duck!
Russel Winder wrote: Groovy uses [...] !!!
Re: duck!
Steven Schveighoffer wrote: On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@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.
Re: duck!
On 2010-10-16 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@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.for...@michelf.com http://michelf.com/
Re: duck!
On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@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.for...@michelf.com http://michelf.com/
Re: duck!
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.
Re: duck!
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 newshou...@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/
Re: duck!
Michel Fortin wrote: On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@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.
Re: duck!
Walter Bright Wrote: One would think programmers are above all that, but we are not. Ask people what they think about cross-platform .net ad campaign.
Re: duck!
On Sat, 16 Oct 2010 14:32:10 -0400, Walter Bright newshou...@digitalmars.com wrote: Steven Schveighoffer wrote: On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: The problem with adaptTo is that, just like itoa or printf, it is too boring to have marketing value. Wait, really? This statement has no place in a programming language decision IMO. One would think programmers are above all that, but we are not. We are not talking about a feature name, we are talking about a *function* name. I personally think 'as' is better than 'adaptTo' or 'duck'. Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. People will search on duck typing in D and with the duck template, they'll drop right in on it. With adaptTo, it'll be on page 67 of the results, they'll never find it, and will conclude that D cannot do duck typing. I would expect them to search for it and find the 'duck typing' section of the D marketing documents, and see that 'D does duck typing, see adaptTo'. Or find it on wikipedia. Unless you plan on handing people a full copy of the phobos docs as 'marketing material'... Let's change writef to shazam! Let's call File BitLocker! And 'to' really should be called transformationVehicle! Think of it another way. Remember zip files? What a great name, and yes, it seemed silly at first, but zip entered the lexicon and D has a zip module and it never occurs to anyone it might be better named std.compressedArchive. Phil Katz renamed arc files zip files, called his compressor pkzip and blew away arc so badly that most people are unaware it even existed. I think the catchy, silly zip name was a significant factor in getting people to notice his program. In contrast, the superior lharc with its lzh files never caught on. These are completely unsubstantiated statements focused on a very narrow set of variables. It's like all those studies that say X causes cancer because look most people who use X have cancer. Well, yeah, but they are all 40-70 yr old people, who freaking knows how many factors went into them getting cancer!!! And it proves itself again and again when the next year, they say, 'well that study was flawed, we now *know* that it was really Y'. Besides, duck isn't the compiler name, it's a very very small part of the library. I think you associate more weight to this than there actually is. Let's concentrate on finding the name that best describes the function. This might be 'duck', but let's leave marketing considerations out of it. If duck was a verb that meant 'walk like a...' then I'd agree it was a fine term. How about if we can say D's functions are named intuitively instead of after some colloquial term that describes the function? And yeah, I agree zip is now a de-facto term, so much so that I think std.range.Zip should be renamed :) But was it zip that made the tool famous or the tool that made zip famous? Let's also not forget the hundreds, probably thousands, of 'cute' names that didn't save their respective products because the marketing material sucked. -Steve
Re: duck!
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.for...@michelf.com wrote: On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@digitalmars.com said: Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. It's like saying D is a dynamic language, people will know you're bullshitting them. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
Walter Bright Wrote: Which blog article would you click on? Interface Adapter for D or Duck Typing for D? You are somewhat right. The right place for marketing is an article, not the library source, right? What would you click on? Duck typing for D or dsource.org/phobos/src/trunk?
Re: duck!
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?
Re: duck!
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 s...@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.for...@michelf.com wrote: On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@digitalmars.com said: Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. It's like saying D is a dynamic language, people will know you're bullshitting them. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
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 jcao...@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 s...@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.for...@michelf.com wrote: On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@digitalmars.com said: Nobody is going to start using D because it has a function *named* duck. Maybe not, but it will raise awareness that D has duck typing. Otherwise, I guarantee you that people will argue that I need duck typing, and Z has it and D does not if it is named adaptTo. The problem is that D doesn't have duck-typing. The adapter pattern isn't duck-typing. Duck-typing is when you have an object and can call a 'quack' function on it and if there's no 'quack' function you get a runtime error. It's like saying D is a dynamic language, people will know you're bullshitting them. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
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 s...@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?
Re: duck!
On 10/16/2010 12:38 PM, Steven Schveighoffer wrote: On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu seewebsiteforem...@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
Re: duck!
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.
Re: duck!
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 destructiona...@gmail.comwrote:
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.
Re: duck!
'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 newshou...@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!!
Re: duck!
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.for...@michelf.com: On 2010-10-16 14:32:10 -0400, Walter Bright newshou...@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.for...@michelf.com http://michelf.com/
Re: duck!
On 10/16/2010 01:43 PM, Michel Fortin wrote:
On 2010-10-16 13:19:36 -0400, Andrei Alexandrescu
seewebsiteforem...@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
Re: duck!
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.
Re: duck!
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.
Re: duck!
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
Re: duck!
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 seewebsiteforem...@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/
Re: duck!
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.
Re: duck!
On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu seewebsiteforem...@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.for...@michelf.com http://michelf.com/
Re: duck!
Kagamin wrote: Walter Bright Wrote: Which blog article would you click on? Interface Adapter for D or Duck Typing for D? You are somewhat right. The right place for marketing is an article, not the library source, right? They're both important. Especially consider that Phobos is open source, is on the internet just a click away, and the words used in it are indexed by Google. What would you click on? Duck typing for D or dsource.org/phobos/src/trunk? If I'm looking at a list of modules for Phobos, and I see std.duck as a clickable link, I'll click on it. If I google for adapt for D I'll get a hopeless mess of irrelevant links. duck typing for D should be much better. Remember that google ranks pages by relevance, and searching for duck will give higher ranking for pages with duck in the url, title, headings, etc. That's just what we want.
Re: duck!
Lutger wrote: Justin Johansson wrote: On 16/10/2010 6:30 PM, Christof Schardt wrote: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Christof This is a totally brilliant suggestion by Christof as anyone who understands the XPath 2.0 type language would tell you also. While finding duck! rather cute, marketing intelligence will confirm that Christof's as! suggestion is the way to go. I feel woeful that I did not think of it myself. Award for naming suggestion definitely goes to Christof. Justin plus, it's shorter to type. *ducks* Try googling as for D
Re: duck!
Kagamin wrote: Walter Bright Wrote: One would think programmers are above all that, but we are not. Ask people what they think about cross-platform .net ad campaign. I don't know anything about that.
Re: duck!
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 seewebsiteforem...@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
Re: duck!
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 newshou...@digitalmars.com wrote: Lutger wrote: Justin Johansson wrote: On 16/10/2010 6:30 PM, Christof Schardt wrote: auto d = duck!Drawable(c); // awes What about as ? auto d = as!Drawable(c); Christof This is a totally brilliant suggestion by Christof as anyone who understands the XPath 2.0 type language would tell you also. While finding duck! rather cute, marketing intelligence will confirm that Christof's as! suggestion is the way to go. I feel woeful that I did not think of it myself. Award for naming suggestion definitely goes to Christof. Justin plus, it's shorter to type. *ducks* Try googling as for D
Re: duck!
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 - rain...@eldwood.com
Re: duck!
On Sat, 16 Oct 2010 16:26:15 -0400, Walter Bright newshou...@digitalmars.com wrote: Steven Schveighoffer wrote: Think of it another way. Remember zip files? What a great name, and yes, it seemed silly at first, but zip entered the lexicon and D has a zip module and it never occurs to anyone it might be better named std.compressedArchive. Phil Katz renamed arc files zip files, called his compressor pkzip and blew away arc so badly that most people are unaware it even existed. I think the catchy, silly zip name was a significant factor in getting people to notice his program. In contrast, the superior lharc with its lzh files never caught on. These are completely unsubstantiated statements focused on a very narrow set of variables. It's like all those studies that say X causes cancer because look most people who use X have cancer. Well, yeah, but they are all 40-70 yr old people, who freaking knows how many factors went into them getting cancer!!! And it proves itself again and again when the next year, they say, 'well that study was flawed, we now *know* that it was really Y'. It's an example of a phenomenon I've seen over and over. How about the names Google and Yahoo? Boy did I think they were stupid names for companies and products. Boy was I wrong. How about the perjorative name twitter and the hopelessly undignified verb tweet? I still can't bring myself to say I tweeted. Ugh. This is called cherry picking. What about microsoft, IBM, apple, gillette, DOS, etc. All these names aren't wacky, yet they are still successful. How do you explain that? You might lump GoDaddy.com as one of those 'wacky' names that made it, but that has nothing to do with it. Google and Yahoo succeeded because their product was good. D will succeed because it does duck typing, not because the function that does duck typing is called 'duck'. Now, if D was all about duck typing, and you called it 'ducky', then I think that the name might be appropriate, and actually help with marketing. But naming the function that does duck typing 'duck' doesn't seem to me like it makes or breaks D at all. I want to be clear that duck is not my first choice, but it's certainly a name that makes sense. I'm just saying that marketability of D does not change no matter what appropriate term you choose. I also couldn't believe all the mileage Borland got out of naming minor features zoom technology and smart linking. So I don't buy that we programmers are above all that. But were there functions named zoomTechnology() and smartLink()? Were their tools named zoom or smartl or something? Is that what pushed them over the edge, or was it the bullet on the packaging that said: * Includes zoom technology! duck *is* indicative of what the feature does, and so it is a lot better than zoom or smart or yahoo, which I'd have a hard time justifying. I guess that's why I'm not a marketer! Yes, duck is a valid option. And the fact that duck typing is what it does is a very good reason to use it. I just don't see 'marketing draw' as being a factor whatsoever. It's useless noise. Besides, duck isn't the compiler name, it's a very very small part of the library. I think you associate more weight to this than there actually is. A lot of people do think duck typing is very important. And D already does duck typing. Templates do duck typing. 'adaptTo' does it too, and it's cool, but it's not *that* important (no offense, Kenji). Let's concentrate on finding the name that best describes the function. This might be 'duck', but let's leave marketing considerations out of it. If duck was a verb that meant 'walk like a...' then I'd agree it was a fine term. How about if we can say D's functions are named intuitively instead of after some colloquial term that describes the function? And yeah, I agree zip is now a de-facto term, so much so that I think std.range.Zip should be renamed :) But was it zip that made the tool famous or the tool that made zip famous? Let's also not forget the hundreds, probably thousands, of 'cute' names that didn't save their respective products because the marketing material sucked. I think 'zip' got peoples' attention, and then pkzip delivered the goods (better than arc). lharc, on the other hand, had a ponderous name and failed despite being significantly better. So yeah, I think the name got pkzip on the map, but yes, the product also had to deliver. A cute name is not enough to save a crap product, but it will help with a good one. If you want people to notice something and give it a chance to be good, having a boring name (that is also not google-friendly) will never give it a chance. But people don't search google for duck typing programming languages and pick the language they're going to use from this list! I think you are really going cuckoo over this feature like
Re: duck!
On Sat, 16 Oct 2010 16:31:34 -0400, Walter Bright newshou...@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
Re: duck!
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
Re: duck!
On 10/16/2010 03:30 PM, Michel Fortin wrote:
On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
seewebsiteforem...@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
Re: duck!
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
Re: duck!
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
