Talk:Implicit class - Revision history

Clemahieu at 23:05, 20 November 2007

2007-11-20T23:05:56Z

Ericb at 21:53, 5 October 2007

2007-10-05T21:53:46Z

Clemahieu at 22:10, 4 October 2007

2007-10-04T22:10:00Z

Ericb at 20:49, 4 October 2007

2007-10-04T20:49:51Z

Clemahieu at 20:21, 3 October 2007

2007-10-03T20:21:55Z

Clemahieu at 20:21, 3 October 2007

2007-10-03T20:21:46Z

Colin-adams at 08:03, 3 October 2007

2007-10-03T08:03:43Z

New page

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 <e>`count'</e> from <e>STRING</e>, and so all that is actually needed is that the object concerned has a feature <e>count: INTEGER</e>.

So perhaps rather than inheriting from <e>STRING</e>, 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.
--[[User:Colin-adams|Colin-adams]] 10:03, 3 October 2007 (CEST)

← Older revision		Revision as of 23:05, 20 November 2007
Line 24:		Line 24:

	--[[User:Ericb\|Ericb]] 23:53, 5 October 2007 (CEST): What is not obvious is the transition from D -> B, C to D -> A.		--[[User:Ericb\|Ericb]] 23:53, 5 October 2007 (CEST): What is not obvious is the transition from D -> B, C to D -> A.
		+
		+	--[[User:Clemahieu\|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.

← Older revision		Revision as of 21:53, 5 October 2007
Line 22:		Line 22:

	Is there a way to make it less confusing?		Is there a way to make it less confusing?
		+
		+	--[[User:Ericb\|Ericb]] 23:53, 5 October 2007 (CEST): What is not obvious is the transition from D -> B, C to D -> A.

← Older revision		Revision as of 22:10, 4 October 2007
Line 12:		Line 12:

	--[[User:Ericb\|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.		--[[User:Ericb\|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.
		+
		+	--[[User:Clemahieu\|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?

← Older revision		Revision as of 20:49, 4 October 2007
Line 10:		Line 10:
	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.		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.
	--[[User:Clemahieu\|Clemahieu]] 22:21, 3 October 2007 (CEST)		--[[User:Clemahieu\|Clemahieu]] 22:21, 3 October 2007 (CEST)
		+
		+	--[[User:Ericb\|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.

← Older revision		Revision as of 20:21, 3 October 2007
Line 9:		Line 9:

	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.		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.
		+	--[[User:Clemahieu\|Clemahieu]] 22:21, 3 October 2007 (CEST)

← Older revision		Revision as of 20:21, 3 October 2007
Line 7:		Line 7:
	So perhaps rather than inheriting from <e>STRING</e>, 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.		So perhaps rather than inheriting from <e>STRING</e>, 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.
	--[[User:Colin-adams\|Colin-adams]] 10:03, 3 October 2007 (CEST)		--[[User:Colin-adams\|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.