Duck Notation

re: Duck Notation

Tom Kirby-Green — Wed, 18 Jul 2007 22:43:51 GMT

I am super interested in these LINQ design patterns. Is there any chance you can publish them as a work-in-progress document to the community? I'm sure I can't be alone in wanting to read these - and am more than prepaired to be flexable and accept they're like to mutate a lot in the short term! :-)

re: Duck Notation

mharder — Wed, 18 Jul 2007 23:30:45 GMT

What's the need for supporting duck typing at all? Why isn't static typing sufficient?

re: Duck Notation

tomasp — Wed, 18 Jul 2007 23:39:55 GMT

You might want to look at Haskell type classes (http://en.wikipedia.org/wiki/Type_class). As far as I understand it, they are used to solve this kind of problems, but I'm not sure if it helps with finding good way for writing "easy to parse description".

re: Duck Notation

kcwalina — Wed, 18 Jul 2007 23:55:58 GMT

Tom, yes, I would be more than willing to publish something that is not formally reviewed/approved yet, but we don't even have that. We are still in the stage of exploring what we want to have in the guidelines. For example, we do know that extension methods can be abused and we willo have some guidelines recommending where the boundary between good and bad usage of the extension methods is, but we don't yet know how to describe the boundary.

We need duck typing cause static types are not expressive enough in some cases. For example, there is no way to say that a parameter can be either an Expression or a delegate.

Tomas, thanks for the pointer to Haskell. I will take a look.

re: Duck Notation

Orion Edwards — Thu, 19 Jul 2007 01:22:14 GMT

Here's an idea for C# 4 or 3.5 or whatever which would solve this problem, and make millions of developers the world over jump for joy. I'd hazard a guess and say it wouldn't be too hard with the type inferencing stuff that's already there:

Define an alternative to an interface called 'requirement'

It would work and behave exactly the same as an interface EXCEPT that it would use duck typing instead of static typing: For example:

public requirement Closeable {

void Close();

}

public void TestMethod( Closeable c ) {

c.Close();

}

TestMethod( new System.Windows.Forms.Form() );

A windows form has a public void Close() method so this should work. The typechecking is still just as good and can be done entirely by the compiler so there should be no speed or safety hit. 'requirement' may not be the best word, but the world would rejoice if C# had this

re: Duck Notation

Daniel Slaney — Thu, 19 Jul 2007 01:28:31 GMT

It looks like you want structural subtyping instead of nominal subtyping. Also what's the scope of the [ItemType] mentioned in the [Enumerator] example? Is it assumed to be defined elsewhere?

OCaml has row polymorphism on objects and concepts in the latest C++ draft are all related to this kind of thing. The template constraints idiom in C++ might be a good place to look for ideas as well.

The Expression or delegate example could be handled with sum types if you're willing to take the type tag over head.

re: Duck Notation

rryan — Thu, 19 Jul 2007 02:16:43 GMT

mharder :

Duck typing is used to allow objects that do not implement IEnumerable to be used with foreach. If it walks like a duck (implements GetEnumerator), then it is a duck!

re: Duck Notation

Simon Buchan — Thu, 19 Jul 2007 04:17:30 GMT

kcwalina: Couldn't overloading handle the Expression/delegate case?

rryan: or at least a good decoy :)

Duck typing makes the OO purist in me squirm, Just because it has the same signature, its ok to call the methods, even though the semantics might be completely different?

There's an example in "The C++ Programming Language" that is very approximately:

class Sprite { void draw(int x, int y) {...} ... };

class Cowboy { void draw(int speed, int accuracy) {...} ... };

Of course, the template stuff in C++ uses this all the time, so it can't be all bad :). As far as I am aware, the only way to specify duck typing is to give a code snippet that uses the type in every way you want to require, at least in as screwed up a language as C++ (Just try listing all the ways to implement 'a < b') - This is how the concepts stuff in C++0x looks to be going.

Haskell's type classes are awesome, but totally incompatible with regular OO.

re: Duck Notation

Daniel Fortunov — Thu, 19 Jul 2007 10:58:50 GMT

Just out of interest, I can see that the added flexibility of duck typing might be necessary for the query operators, but what does it buy you in the case of foreach?

IEnumerable and IEnumerator are trivial interfaces and it's surely more readable if you implement those interfaces, rather than just having a floating GetEnumerator() method on your object?

What is the usecase for ducktyping on foreach?

re: Duck Notation

sdether — Thu, 19 Jul 2007 18:17:20 GMT

I'll grant that interfaces are not always expressive enough, but I am confused why foreach doesn't just require IEnumerable? I mean the pattern is quite specific, where you are not likely to run into an object that has these members but doesn't implement IEnumerable and if you are creating your own type, implementing IEnumerable doesn't seem like an onerous requirement.

But I could see the benefit of being able to do something like Orion suggested. Maybe it could be something similar to extension methods, i.e. the ability to decorate some object with an Interface. This way if you have several objects that have similar use patterns but no common interface, you could create one and decorate the classes with that interface. You could already achieve something similar with Attributes, but that does move the checking to runtime.

re: Duck Notation

Keith J. Farmer — Thu, 19 Jul 2007 21:38:35 GMT

mharder: The point that people are making is that sometimes a type -- for whatever reason -- doesn't implement an interface. Perhaps it has all the methods but doesn't declare itself (eg, it's an older type that predates an interface), or it only partially implements an interface (eg, the interface may encompass too much).

It also makes it easier when you're crossing service boundaries. You (the client) can specify some interfaces that partition fields into interesting bits. IId { string Id { get; set; }}, for example, and get access to things without having to explicity reflect over the type.

That reflection is already commonly used for this sort of thing is a strong motivation, for me at least, to push for duck typing.

re: Duck Notation

Keith J. Farmer — Thu, 19 Jul 2007 21:48:58 GMT

Krzysztof:

I like the idea.. a lot. In C#'s case I wouldn't use square brackets, because of the ambiguity that would cause with attributes. I'd suggest parentheses instead (which has conceptual baggage in the casting department, itself related to the idea of duck typing).

After all, maybe we'd like to extend attributes to other parts of the syntax at some point.

Would this be limited to public APIs (like interfaces are today)?

Also, your [ItemType] .. why not just use generics there?

(Foreachable<T>) {

public (Enumerator<T>) GetEnumerator();

}

(Enumerator<T>) {

public bool MoveMext();

public T Current { get; }

}

Orion's idea also has strong merits, and could be easier on the syntax. But in the end, this is all dependant on the language it's being fit into.

re: Duck Notation

Pete — Fri, 20 Jul 2007 01:33:25 GMT

Hi Krzysztof,

Thank goodness you're getting involved with design guidelines for language-integrated query. There's a lot of work to be done in this area.

The first thing you must surely do is get the awful decision to use the acronym "Linq" everywhere instead of the word "Query" reversed. This decision change goes against pretty much everything that the wonderful FDG book stood for.

There's still time.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1573951&SiteID=1

Thanks, Pete.

Dynamic nature of C# I bet you don't know :)

Pawel Pabich's blog — Fri, 20 Jul 2007 03:01:20 GMT

Dynamic nature of C# I bet you don't know :)

re: Duck Notation

Jonas — Fri, 20 Jul 2007 06:27:03 GMT

Hi,

What's wrong with the interface description? It's well known, no need to come up with some new "syntax".

The "duck" type doesn't have to "implement" the interface it just used to describe the contract.

But seriously... what will happen if it doesn't implement all of the contract ;)

Thanks

/Jonas

re: Duck Notation

Pawel Pabich — Fri, 20 Jul 2007 12:25:34 GMT

Hi,

Could you provide more examples like the IEnumerable one?

re: Duck Notation

Sven — Fri, 20 Jul 2007 16:34:00 GMT

I think that that notation could be usable, however [ItemType] should be replaced with [Foreachable], or else something like this

[ItemType : Foreachable]

{ ...

}

[Enumerator]

{ [ItemType]

}

Now, it's not clear that ItemType is actually the "foreachable" type.

Dynamic nature of C# I bet you don't know :)

Blog — Sat, 21 Jul 2007 01:19:35 GMT

Dynamic nature of C# I bet you don't know :)

re: Duck Notation

Raja R Harinath — Sat, 21 Jul 2007 12:54:31 GMT

This seems similar to the all the discussions of "concept"s in C++ generic libraries.

re: Duck Notation

Ian Horwill — Mon, 23 Jul 2007 15:57:50 GMT

How about adding an [implicit] attribute to an interface definition?

re: Duck Notation

kcwalina — Tue, 24 Jul 2007 20:36:15 GMT

Sorry for a late reply. I was on short vacation.

Just to clarify, this is not about features in the compiler. This is just a paper notatio so it's easier to describe such patterns.

And of course, thanks for all the pointers and comments!

Why Duck Typing Matters To C# Developers

you've been HAACKED — Mon, 20 Aug 2007 07:45:10 GMT

Why Duck Typing Matters To C# Developers

Supporting "foreach" without implementing IEnumerable

Dotmad — Sat, 15 Sep 2007 19:21:46 GMT

Krzysztof Cwalina wrote a post detailing how have your class support the "foreach" loop without implementing

re: Duck Notation

Wayne — Fri, 19 Oct 2007 02:00:28 GMT

You are wrong :-)

I have just sat and passed 70-536, there was a question on foreach and the "correct" answer was "IEnumerable".

re: Duck Notation

kcwalina — Fri, 26 Oct 2007 22:58:56 GMT

Wayne, what was the question?

re: Duck Notation

Ricardo Lacerda Castelo Branco — Sat, 03 Nov 2007 05:24:15 GMT

I really like Ian Horwill suggestion. The only problem is that to really duck typing we are not forced to "implement" all members of the interface. We have to implement only the ones used in a given method.

re: Duck Notation

Wayne — Fri, 09 Nov 2007 02:00:05 GMT

There was a question in the exam about what functionality must be implemented by a class so that it can support foreach, the answer being "implement the IEnurable interface".

From reading your post the the correct answer implement MoveNext and Current was not available as an option.

It is this type of inaccuracy/simplification in the exams that lessens the value of certification.

re: Duck Notation

Ulf L — Sat, 17 Nov 2007 20:12:55 GMT

Dear Krzysztof Cwalina,

There is some confusion about C#, duck notation and foreach on Wikipedia. Please see:'

http://en.wikipedia.org/wiki/Talk:Duck_typing#C.23

Sincerly

Ulf L

re: Duck Notation

Paddy3118 — Sat, 17 Nov 2007 21:27:18 GMT

If you take into account this comparison of Duck-Typing with Structural-Typing:

http://en.wikipedia.org/wiki/Duck_typing#Comparison_with_Structural_type_systems

I don't think you give enough information for me to determine which you intend to implement. COuld you say which?

Thanks.

re: Duck Notation

David — Thu, 13 Dec 2007 22:00:56 GMT

I'm sorry, but who decided that duck typing in C# was a good idea? The foreach decision is still incomprehensible, but since almost no one knows about it, and since its mostly irrelevant since everyone implements IEnumerable anyway, I can let that slide. But now you are pushing duck typing to the forefront in what has been (and should be!) a statically typed language. Not that dynamic language features can't be useful, but shoehorning them into a language that clearly wasn't designed for them is just asking for trouble. If the C# language team continues on this course, I am confident that C# as a language will be mostly unusable just one or two versions from now. Please, THINK about what you are doing, and get community feedback, before you throw yourself off a cliff. Compromising the integrity of a language for the sake of a "cool" feature is a recipe for disaster, especially when there are other ways to accomplish the same goal that could also be useful in other areas and would not compromise the language.

re: Duck Notation

David Banister — Mon, 14 Jan 2008 01:15:46 GMT

I have run into this situation in various occasions:

1. Sometimes a common pattern is implemented without a formal interface.

2. Looking for static methods which cannot be defined in an interface.

I had never heard of "duck typing", but I used a similar notation with the concept of a "shadow" (with similar logic "If it casts the shadow of a signature, it has that signature."). I defined interfaces that contained the signatures for which I was looking. This process would be much easier if it was handled by the compiler.

The syntax that would be awesome would be very similar to interfaces, but would allow all the generally possible modifiers. For the foreach example:

shadow SForeachable

{

public SEnumerator GetEnumerator( );

}

shadow SEnumerator

{

public object Current{ get; }

public bool MoveNext( );

}

No object could actually "implement" the shadow, it would simply match it or not, but this syntax would be easy to use with type casting constructs. For example:

foreach(MyObject obj in myEnumerable)

{

// do something in the loop

}

would be converted into:

SForeachable foreachable = (SForeachable)myEnumerable;

while(foreachable.MoveNext( ))

{

MyOjbect obj = foreachable.Current;

// do something in the loop

}

From my experience, the most useful aspect would be to have some way of dealing with static methods that are commonly implemented:

shadow SParsable

{

public static shadow Parse( string text );

}

In this syntax I used the shadow keyword in place of the concrete type that is defined. The problem comes with merging instance syntax with static syntax. Something like the following might do:

Type x = ...// some time gathered by reflection

Decimal instance = SParsable(x).Parse( text );

I agree that this violates OO principles, but it drastically simplifies various tasks. At a minimum the "shadow" syntax could provide a representation at least in documentation for "duck typing".

C# vNext Revisited

Matthew Podwysocki's Blog — Thu, 31 Jan 2008 22:18:07 GMT

I often rethink or have additions to my posts. This topic of what's coming in C# vNext is definitely

re: Duck Notation

Mats Helander — Sat, 23 Feb 2008 07:35:04 GMT

Yes, your example compiles. The following, however, does not. Does this make you agree that the duck typing choice for foreach was a bad one? If not, why not?

class Program

{

static void Main(string[] args)

{

// the following does not complile!

// all thanks to foreach duck typing

// rather than properly using interfaces...

YearCollection f = new YearCollection();

foreach (object o in f)

{

Console.WriteLine("Hi!");

}

Console.ReadLine();

}

class YearCollection

{

public Year GetEnumerator() { return new Year(); }

public struct Year : IEnumerator

{

public object Current

{

get { return new DateTime(DateTime.Today.Year, 1, 1); }

}

private int cursor;

bool IEnumerator.MoveNext()

{

if (cursor >= DateTime.Today.Year)

return false;

cursor++;

return true;

}

object IEnumerator.Current

{

get { return new DateTime(cursor, 1, 1); }

}

void IEnumerator.Reset()

{

cursor = 0;

}

re: Duck Notation

Andrew — Tue, 11 Mar 2008 13:42:58 GMT

Hi, I guess in this particular case (foreach), duck typing is used so that CLR woudn't need to cast an enumerator to IEnumerator interface. Hence, we can use structs as enumerators (thus decreasing the pressure on GC). Generic List and Dictionary enumerators are implemented in that way.

But the drawback is that we need to make such enumerator structs public nested (not private nested) - otherwise boxing occures anyway.

Foreach is Duck Typed!

This Blog Can Also Be A Hat — Tue, 22 Jul 2008 20:04:29 GMT

I thought I know how the foreach construct worked under the covers. I figured the runtime/compiler would

今天看到的好文，很不错，特别是那漫画。

真见 — Fri, 25 Jul 2008 14:01:45 GMT

感谢Gray Zhang 的再次帮助，C#4.0的四个新特性由他大致翻译。