Difference between revisions of "Talk:Implicit class"

Latest revision as of 14:05, 20 November 2007

When you say downcast, presumably you mean an object test (as assignment attempt has been dropped from ECMA)?

So your second case is equivalent to saying that an object test for a STRING_EXTRA always succeeds if the actual object is a STRING.

Your example only makes use of the feature `count' from STRING, and so all that is actually needed is that the object concerned has a feature count: INTEGER.

So perhaps rather than inheriting from STRING, you provide a deferred feature definition, and the object test passes if the tested object posseses a feature that matches the name, signature an contract. --Colin-adams 10:03, 3 October 2007 (CEST)

I edited the page to include only one idea. The main reason I requested comments on the first idea was so that multiple conformance could be used in actual generic parameters and to clean up multiple conformance. --Clemahieu 22:21, 3 October 2007 (CEST)

--Ericb 22:49, 4 October 2007 (CEST): The syntax of your "implicit" class is misleading. It was considered during one of the ECMA meetings but it was not adopted. Indeed, even though you said "Any class inheriting from B and C would automatically inherit from A", the definition of the implicit class says that A inherits from B and C. These two statements are incompatible. So the idea is nice, but the syntax is too confusing.

--Clemahieu 00:10, 5 October 2007 (CEST)Hmm, I thought it was pretty straight forward.

D -> B, C

implicitly becomes D -> A A -> B, C

Is there a way to make it less confusing?

--Ericb 23:53, 5 October 2007 (CEST): What is not obvious is the transition from D -> B, C to D -> A.

--Clemahieu 15:05, 20 November 2007 (PST) I just noticed that they're doing this in C# 3.0 I'm not a fan of pretty much any 'features' C# has but this one I think poses a legitimate function. http://en.wikipedia.org/wiki/Extension_method I'm also going to change the wording from "would automatically inherit from" to "could be downcast to". It would be nice to differentiate between a downcast that could fail, such as an object test, and a downcast that can't fail, such as downcasting to an implicit class.