Duck typing
-
In computer programming with object-oriented programming languages, duck typing is a style of typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface.
An interesting read, but something remains unclear to me: Why would you want to have something like
class Duck
{
public void Quack() { ... }
public void Walk() { ... }
}
class OtherDuck
{
public void Quack() { ... }
public void Walk() { ... }
}
...
void M(Duck bird)
{
bird.Quack();
bird.Walk();
}
...
M(new Duck()); // Legal
M(new OtherDuck()); // Illegalrather than have and inherit from an interface ? To me Duck Typing seems some [to be]* form of Duct Taping (I'll admit it: Pun intended). * Fixed Typo - I forgot 'to be' in there.
Veni, vidi, caecus | Everything summarizes to Assembly code
-
In computer programming with object-oriented programming languages, duck typing is a style of typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface.
An interesting read, but something remains unclear to me: Why would you want to have something like
class Duck
{
public void Quack() { ... }
public void Walk() { ... }
}
class OtherDuck
{
public void Quack() { ... }
public void Walk() { ... }
}
...
void M(Duck bird)
{
bird.Quack();
bird.Walk();
}
...
M(new Duck()); // Legal
M(new OtherDuck()); // Illegalrather than have and inherit from an interface ? To me Duck Typing seems some [to be]* form of Duct Taping (I'll admit it: Pun intended). * Fixed Typo - I forgot 'to be' in there.
Veni, vidi, caecus | Everything summarizes to Assembly code
It's seams that he try to invent a kind of environment where the compiler/linker/runtime will decide - based on actual structure - if types are equal or not. I can image how much fun it should be when two types render incompatible because you added some property to one of them...
-
In computer programming with object-oriented programming languages, duck typing is a style of typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface.
An interesting read, but something remains unclear to me: Why would you want to have something like
class Duck
{
public void Quack() { ... }
public void Walk() { ... }
}
class OtherDuck
{
public void Quack() { ... }
public void Walk() { ... }
}
...
void M(Duck bird)
{
bird.Quack();
bird.Walk();
}
...
M(new Duck()); // Legal
M(new OtherDuck()); // Illegalrather than have and inherit from an interface ? To me Duck Typing seems some [to be]* form of Duct Taping (I'll admit it: Pun intended). * Fixed Typo - I forgot 'to be' in there.
Veni, vidi, caecus | Everything summarizes to Assembly code
It can be useful. I remember working on a VB6 project - okay, I know - and we used duck typing to get around a lot of problems with inheritance in the language. The object relationships were mostly loose and most cross calls were based on config. It worked and it was useful, however when it came to managing the method signatures fun ensued. :-D
speramus in juniperus
-
In computer programming with object-oriented programming languages, duck typing is a style of typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface.
An interesting read, but something remains unclear to me: Why would you want to have something like
class Duck
{
public void Quack() { ... }
public void Walk() { ... }
}
class OtherDuck
{
public void Quack() { ... }
public void Walk() { ... }
}
...
void M(Duck bird)
{
bird.Quack();
bird.Walk();
}
...
M(new Duck()); // Legal
M(new OtherDuck()); // Illegalrather than have and inherit from an interface ? To me Duck Typing seems some [to be]* form of Duct Taping (I'll admit it: Pun intended). * Fixed Typo - I forgot 'to be' in there.
Veni, vidi, caecus | Everything summarizes to Assembly code
Quote:[/\]
C#'s static type system says that the relevant fact about new ... A duck-typed system -- again, remember we are talking about what my conception of duck typing here -- would allow a program like this:
Definitely a duct tape system
Loading signature... . . . Please Wait . . .
-
In computer programming with object-oriented programming languages, duck typing is a style of typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface.
An interesting read, but something remains unclear to me: Why would you want to have something like
class Duck
{
public void Quack() { ... }
public void Walk() { ... }
}
class OtherDuck
{
public void Quack() { ... }
public void Walk() { ... }
}
...
void M(Duck bird)
{
bird.Quack();
bird.Walk();
}
...
M(new Duck()); // Legal
M(new OtherDuck()); // Illegalrather than have and inherit from an interface ? To me Duck Typing seems some [to be]* form of Duct Taping (I'll admit it: Pun intended). * Fixed Typo - I forgot 'to be' in there.
Veni, vidi, caecus | Everything summarizes to Assembly code
There's an example of Duck Typing using 'dynamic in C# 4.0 on Wikpedia: [^]. Looking at the code, and how it is used, makes me ... nauseous.
“There are obvious things, and there are many obvious things no one tried, because no one needed to try them.” Sergey Alexandrovich Kryukov, January 1, 2014
-
In computer programming with object-oriented programming languages, duck typing is a style of typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface.
An interesting read, but something remains unclear to me: Why would you want to have something like
class Duck
{
public void Quack() { ... }
public void Walk() { ... }
}
class OtherDuck
{
public void Quack() { ... }
public void Walk() { ... }
}
...
void M(Duck bird)
{
bird.Quack();
bird.Walk();
}
...
M(new Duck()); // Legal
M(new OtherDuck()); // Illegalrather than have and inherit from an interface ? To me Duck Typing seems some [to be]* form of Duct Taping (I'll admit it: Pun intended). * Fixed Typo - I forgot 'to be' in there.
Veni, vidi, caecus | Everything summarizes to Assembly code
See this: http://www.google.com/search?q=c%2B%2B+compile+time+polymorphism[^] For instance, in a C++ template, you can do something like this:
template class Foo: public T
{
int Baa(int k)
{
T * pT = static_cast(this); // this is the magic
return 42 + pT->Baz(k - 3); // for instance.
}
};Any class that exposes a method Baz that returns something that can be converted to an integer, and can be called with an integer parameter, can be a template paremeter for class Foo. No special interfaces required, so it is less restrictive than, for instance, C# generics. Aside: 'less restrictive' doesn't mean 'better', or 'worse'. Also, the code above is resolved at compile time, which may have a noticeable impact on performance. Duck typing is also used in Javascript, for other reasons (mostly, IMHO, flexibility). JM2B,
Pablo. "Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899). "You are to act in the light of experience as guided by intelligence" (Rex Stout, "In the Best Families", 1950).
-
In computer programming with object-oriented programming languages, duck typing is a style of typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface.
An interesting read, but something remains unclear to me: Why would you want to have something like
class Duck
{
public void Quack() { ... }
public void Walk() { ... }
}
class OtherDuck
{
public void Quack() { ... }
public void Walk() { ... }
}
...
void M(Duck bird)
{
bird.Quack();
bird.Walk();
}
...
M(new Duck()); // Legal
M(new OtherDuck()); // Illegalrather than have and inherit from an interface ? To me Duck Typing seems some [to be]* form of Duct Taping (I'll admit it: Pun intended). * Fixed Typo - I forgot 'to be' in there.
Veni, vidi, caecus | Everything summarizes to Assembly code
C# has been internally using duct typing for a very long time.
Link says:
For example, the C#’s foreach operator already uses duck typing. This might be surprising to some, but to support foreach in C# you don’t need to implement IEnumerable! All you have to do is: Provide a public method GetEnumerator that takes no parameters and returns a type that has two members: a) a method MoveMext that takes no parameters and return a Boolean, and b) a property Current with a getter that returns an Object.
-
See this: http://www.google.com/search?q=c%2B%2B+compile+time+polymorphism[^] For instance, in a C++ template, you can do something like this:
template class Foo: public T
{
int Baa(int k)
{
T * pT = static_cast(this); // this is the magic
return 42 + pT->Baz(k - 3); // for instance.
}
};Any class that exposes a method Baz that returns something that can be converted to an integer, and can be called with an integer parameter, can be a template paremeter for class Foo. No special interfaces required, so it is less restrictive than, for instance, C# generics. Aside: 'less restrictive' doesn't mean 'better', or 'worse'. Also, the code above is resolved at compile time, which may have a noticeable impact on performance. Duck typing is also used in Javascript, for other reasons (mostly, IMHO, flexibility). JM2B,
Pablo. "Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899). "You are to act in the light of experience as guided by intelligence" (Rex Stout, "In the Best Families", 1950).
Ah yes, the Curiously Reoccuring Template Pattern reoccurs.... Templates are highly infectious, suddenly everything working with this type(s) has to be a template over that type. Templates still affect the tool chain significantly, and have some problems with other features (such as static data). There is no explicit statement what T needs to support. Foo<T> can be instantiated for any struct / class typetype:
struct cool {};
Foo x; // legal
x.Baa(17); // failsIn a real app you can expect a dozen of "cool candidates", some that work and some you wish they did and that
Baa()call ist hidden in deep jungle of calls, throwing error messages about a dozen of templated types you never heard of. Duck Typing (or C++ concepts) would allow to reject early, at the instantiation of Foo<cool>. -
There's an example of Duck Typing using 'dynamic in C# 4.0 on Wikpedia: [^]. Looking at the code, and how it is used, makes me ... nauseous.
“There are obvious things, and there are many obvious things no one tried, because no one needed to try them.” Sergey Alexandrovich Kryukov, January 1, 2014
Check out the article that the OP linked - it's Eric Lippert (a long time C# compiler writer until he recently left MS) specifically linking to that Wikipedia article and picking apart what it says about Duck Typing. He even specifically derides that C# dynamic explanation you noted offered by that article.
-
In computer programming with object-oriented programming languages, duck typing is a style of typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface.
An interesting read, but something remains unclear to me: Why would you want to have something like
class Duck
{
public void Quack() { ... }
public void Walk() { ... }
}
class OtherDuck
{
public void Quack() { ... }
public void Walk() { ... }
}
...
void M(Duck bird)
{
bird.Quack();
bird.Walk();
}
...
M(new Duck()); // Legal
M(new OtherDuck()); // Illegalrather than have and inherit from an interface ? To me Duck Typing seems some [to be]* form of Duct Taping (I'll admit it: Pun intended). * Fixed Typo - I forgot 'to be' in there.
Veni, vidi, caecus | Everything summarizes to Assembly code
I think in a statically-typed language, Duck Typing would subvert all of the strengths of that environment. Indeed, Interfaces provide all of the function offered by Duck Typing, with the additional benefit of compile-time type checking. Duck Typing, to me, is more of an approach or way of thinking than an actual type system. In dynamic languages, with no compile-time checks, thinking in terms of "duck typing" can be a tool for designing code structure. In most cases, IMHO, if we work in a static language and think "duck typing" we should immediately think "interface" instead.
-
In computer programming with object-oriented programming languages, duck typing is a style of typing in which an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface.
An interesting read, but something remains unclear to me: Why would you want to have something like
class Duck
{
public void Quack() { ... }
public void Walk() { ... }
}
class OtherDuck
{
public void Quack() { ... }
public void Walk() { ... }
}
...
void M(Duck bird)
{
bird.Quack();
bird.Walk();
}
...
M(new Duck()); // Legal
M(new OtherDuck()); // Illegalrather than have and inherit from an interface ? To me Duck Typing seems some [to be]* form of Duct Taping (I'll admit it: Pun intended). * Fixed Typo - I forgot 'to be' in there.
Veni, vidi, caecus | Everything summarizes to Assembly code
