tag:blogger.com,1999:blog-813074883684404285.post7340256339058663897..comments2023-06-26T02:44:10.717-07:00Comments on Kirill Osenkov: C# 3.0 Collection Initializers, Duck Typing and ISupportsAddKirill Osenkovhttp://www.blogger.com/profile/09976634721522023791noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-813074883684404285.post-4706384543836628822008-11-30T03:17:00.000-08:002008-11-30T03:17:00.000-08:00Definitely!Definitely!Kirill Osenkovhttps://www.blogger.com/profile/09976634721522023791noreply@blogger.comtag:blogger.com,1999:blog-813074883684404285.post-7906037472787574292008-11-30T01:54:00.000-08:002008-11-30T01:54:00.000-08:00I recently found about using Structural Types in S...I recently found about using <A HREF="http://langexplr.blogspot.com/2007/07/structural-types-in-scala-260-rc1.html" REL="nofollow">Structural Types</A> in Scala. Although it's not <B>directly</B> related to your post, I think it is related, is a beautiful language feature, and is interesting to know.Владимирhttps://www.blogger.com/profile/00331194583266302228noreply@blogger.comtag:blogger.com,1999:blog-813074883684404285.post-71855578756147841712007-12-13T10:50:00.000-08:002007-12-13T10:50:00.000-08:00I also posted on duck typing and collection initia...I also posted on duck typing and collection initializers and why making semantic assumptions based on identifiers in a statically typed language is a bad idea (whoever decided that foreach should use GetEnumerator without the IEnumerable interface should be shot). I like that there are people who are considering possible solutions, instead of just ranting about the problem like I did :) I really hope that something like this makes it into the language, and soon.<BR/><BR/>http://commongenius.com/variable_irony/archive/2006/12/09/Collection-Initializers-and-Duck-Typing.aspxAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-813074883684404285.post-67064969604346515602007-11-21T08:03:00.000-08:002007-11-21T08:03:00.000-08:00The IENumerable is required to make the Duck Typin...The IENumerable is required to make the Duck Typing assumptions a little more exact.<BR/><BR/>Research turned out, that Add methods do not only mean Collection Add and the idea was to initialize collections...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-813074883684404285.post-22737387806399280092007-11-16T14:15:00.000-08:002007-11-16T14:15:00.000-08:00Thanks John. Very good considerations about Extens...Thanks John. Very good considerations about Extension Interfaces. I'll make sure this feedback reaches the C# team.Kirill Osenkovhttps://www.blogger.com/profile/09976634721522023791noreply@blogger.comtag:blogger.com,1999:blog-813074883684404285.post-25255962912584257762007-10-30T00:11:00.000-07:002007-10-30T00:11:00.000-07:00You comment about "extension interfaces" is intere...You comment about "extension interfaces" is interesting. I've also blogged about that idea, suggesting two other reasons why they might be useful: http://dotnet.agilekiwi.com/blog/2006/04/extension-interfaces.htmlJohn Ruskhttps://www.blogger.com/profile/06542045668842804974noreply@blogger.comtag:blogger.com,1999:blog-813074883684404285.post-7084754374214683262007-10-29T08:18:00.000-07:002007-10-29T08:18:00.000-07:00This post talks about the motivation behind requir...This post talks about the motivation behind requiring IEnumerable: http://blogs.msdn.com/madst/archive/2006/10/10/What-is-a-collection_3F00_.aspx<BR/><BR/>Spoiler: they determined that Add without IEnumerable is usually mathematical.Jacobhttps://www.blogger.com/profile/07300518452274773472noreply@blogger.comtag:blogger.com,1999:blog-813074883684404285.post-48114119571727887022007-09-11T12:45:00.000-07:002007-09-11T12:45:00.000-07:00But then again - how would such a mapping differ f...<I>But then again - how would such a mapping differ from the plain vanilla Adapter pattern? Apart from the syntax, the intent would still be the same: we want an existing class (which we can't change) to implement an additional interface.</I><BR/><BR/>Yes, you do have a point: Haskell-Like typeclasses aren't "orthogonal" to the C# type system; They're elegant in Haskell, because they're the only way to implement an "interface" there, but in the C# type system they would just add a second way to do something that can already be done. (Unless of course one would remove "classic" interface implementations from the language in favor of a type-class like system, but I don't think that's likely...) On the other hand, the same thing can be said about many language elements (e.g. events vs. observer pattern), so the question probably is how intuitive people would find such a feature.<BR/><BR/>To parallel hierarchies: the idea is really quite simple, you can concentrate more on what an object is supposed to do and less on where it fits in a hierarchy, because the hierarchy can be added later, and different clients can use different type class hierarchies to interface with the same objects. Of course that can be acchieved with adapters too, to some extent, but in my experience that's not common - adapters are usually seen more as last-resort hacks to bridge incompatibilities, I've never seen anyone build a clean design from scratch with many adapters bridging between different hierarchies in it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-813074883684404285.post-43488737146067429072007-09-11T11:30:00.000-07:002007-09-11T11:30:00.000-07:00But then again - how would such a mapping differ f...But then again - how would such a mapping differ from the plain vanilla Adapter pattern? Apart from the syntax, the intent would still be the same: we want an existing class (which we can't change) to implement an additional interface.<BR/><BR/>A problem with Adapter is that it is not referentially transparent - an adapter and its target object are different objects, which makes the Adapter in many cases useless.Kirill Osenkovhttps://www.blogger.com/profile/09976634721522023791noreply@blogger.comtag:blogger.com,1999:blog-813074883684404285.post-37329045641875512842007-09-11T11:24:00.000-07:002007-09-11T11:24:00.000-07:00So you're sceptical about duck typing in C#? Becau...So you're sceptical about duck typing in C#? Because one might inadvertently make random classes implement your interface? I agree.<BR/><BR/>Instead, you propose explicit mapping "I want class A to implement interface B and here's how". This mapping leaves both class A and interface B untouched, just like Haskell's type classes leave existing types untouched - they only specify the mapping: how a type implements an interface. Did I get it correctly?<BR/><BR/>Sounds like a good idea to me. I'm also a little bit cautious about duck typing in strongly typed languages - you might shoot yourself in the foot by accidentally allowing types to make false promises about their semantics.<BR/><BR/>One more thing: you mention parallel hierarchies. I'm very interested in designing parallel class hierarchies and you seem to have some experience in that area. I'd love to hear anything about it and the Bridge pattern...<BR/><BR/>Anyway, thanks for the great comment!Kirill Osenkovhttps://www.blogger.com/profile/09976634721522023791noreply@blogger.comtag:blogger.com,1999:blog-813074883684404285.post-1916481331964422662007-09-11T08:54:00.000-07:002007-09-11T08:54:00.000-07:00I don't think this is a very good idea. An interfa...I don't think this is a very good idea. An interface is not just a couple of methods with the right signature - it's a contract, it specifies usage patterns and expected behavior that clients can rely on - a couple of methods that happen to have the right names would be a lot more fragile.<BR/><BR/>However, there is a (IMO) more elegant option: type classes, as in Haskell type classes. The idea is similar: you specify a "type class", in your example "Closeable":<BR/>// purely fictional C# syntax<BR/>typeclass Closeable<BR/>{<BR/> void Close();<BR/>}<BR/><BR/>And, in a addition to that, you provide an implementation, that can be in a different module than the typeclass and the class declaration<BR/>implementation System.Windows.Forms.Form : Closeable<BR/>{<BR/> void Close() <BR/> { <BR/> DialogResult = DialogResult.Ok;<BR/> }<BR/>}<BR/><BR/>This way, clients could rely on a correct implemntation if a type class is implemented. It also helps you get rid of lots of Adapter-classes and parallel hierarchies in traditional OO designs.Anonymousnoreply@blogger.com