Talk:Catcall Test Proposal - Revision history

Colin-adams: What is the example supposed to mean?

2007-11-07T07:41:08Z

What is the example supposed to mean?

Clemahieu at 05:51, 7 November 2007

2007-11-07T05:51:43Z

Manus: cosmetics

2007-11-06T19:53:50Z

cosmetics

Manus at 19:53, 6 November 2007

2007-11-06T19:53:12Z

Schoelle at 11:26, 6 November 2007

2007-11-06T11:26:37Z

Schoelle at 11:26, 6 November 2007

2007-11-06T11:26:21Z

Colin-adams at 08:09, 6 November 2007

2007-11-06T08:09:00Z

New page

Can you give an example of when using the variant keyword makes sense?

As for the frozen keyword, doesn't this break the open/closed principle yet again (I know the example shows an attribute, but the wording suggests a routine could also be marked with a frozen type - does this limit redeclaration)?

What is supposed to happen in the multiple constraint case (if the compiler didn't have a limitation)?
--[[User:Colin-adams|Colin-adams]] 00:09, 6 November 2007 (PST)

← Older revision		Revision as of 07:41, 7 November 2007
Line 18:		Line 18:

	Didn't someone state that most covariant problems can be solved type safely with generics? Honestly that's what I use instead of covariance.		Didn't someone state that most covariant problems can be solved type safely with generics? Honestly that's what I use instead of covariance.
		+
		+	== What is the example supposed to mean? ==
		+
		+	What is the example supposed to mean? I can't see that the G in class B comes into anything.
		+
		+	Bernd, I haven't follow Java developments since I last did any Java programming, several years ago, so I am none the wiser.
		+	Can we have an example showing how this is supposed to work (for both situations, with and without the variant keyword). I am completely unable to follow the article at the moment.
		+
		+	--[[User:Colin-adams\|Colin-adams]] 23:41, 6 November 2007 (PST)

← Older revision		Revision as of 05:51, 7 November 2007
Line 11:		Line 11:
	:* The <e>frozen</e> keyword is not preventing you from redefining a feature, just its signature. So if it breaks the open/closed prinicple, then it just does it very slightly. I would say it is a small price to pay for not having catcalls.		:* The <e>frozen</e> keyword is not preventing you from redefining a feature, just its signature. So if it breaks the open/closed prinicple, then it just does it very slightly. I would say it is a small price to pay for not having catcalls.
	:* For the multiple constraint case, if the descendant type base class is <e>class A [G -> {B,C}]</e> I need to define a type that matches the constraint and being a descendant type. If there are no classes in the universe that inherits from both B and C, such a type cannot be constructed and thus the compiler limitation which will report a potential catcall. Possibly, we could find all the classes that are matching the constraint and use them as base types. For the moment we haven't done it, because it is still experimental and there is little code with multiple constraint.		:* For the multiple constraint case, if the descendant type base class is <e>class A [G -> {B,C}]</e> I need to define a type that matches the constraint and being a descendant type. If there are no classes in the universe that inherits from both B and C, such a type cannot be constructed and thus the compiler limitation which will report a potential catcall. Possibly, we could find all the classes that are matching the constraint and use them as base types. For the moment we haven't done it, because it is still experimental and there is little code with multiple constraint.
		+
		+	--[[User:Clemahieu\|Clemahieu]] 21:51, 6 November 2007 (PST)
		+	I forgot where it was stated but it was something to the effect of "If a language isn't type safe in all instances, it's not really type safe"
		+
		+	Maybe we can eventually solve all catcall issues but covariant redefinition seems like it's taking a lot of resources to try and make work safely.
		+
		+	Didn't someone state that most covariant problems can be solved type safely with generics? Honestly that's what I use instead of covariance.

@@ Line 7: / Line 7: @@
 : '''--[[User:Schoelle|Schoelle]] 03:26, 6 November 2007 (PST)''': The <e>variant</e> keyword is nearly the same as the wildcard types introduced in Java. The only difference is the use of a global analysis (i.e. non-modular) to check certain corner cases that are valid although generics are used in the arguments.
-: '''--[[User:Manus|manus]] 11:53, 6 November 2007 (PST)''': The <e>variant</e> keyword has to be used whenever you want to preserve today's generic conformance rules. For example assigning a <e>LIST [STRING]</e> to a <e>LIST [ANY]</e> is possible today, but with the new rule, only if you declare it as <e>LIST [variant ANY]</e>.
+: '''--[[User:Manus|manus]] 11:53, 6 November 2007 (PST)''':
-: The <e>frozen</e> keyword is not preventing you from redefining a feature, just its signature. So if it breaks the open/closed prinicple, then it just does it very slightly. I would say it is a small price to pay for not having catcalls.
+:* The <e>variant</e> keyword has to be used whenever you want to preserve today's generic conformance rules. For example assigning a <e>LIST [STRING]</e> to a <e>LIST [ANY]</e> is possible today, but with the new rule, only if you declare it as <e>LIST [variant ANY]</e>.
-: For the multiple constraint case, if the descendant type base class is <e>class A [G -> {B,C}]</e> I need to define a type that matches the constraint and being a descendant type. If there are no classes in the universe that inherits from both B and C, such a type cannot be constructed and thus the compiler limitation which will report a potential catcall. Possibly, we could find all the classes that are matching the constraint and use them as base types. For the moment we haven't done it, because it is still experimental and there is little code with multiple constraint.
+:* The <e>frozen</e> keyword is not preventing you from redefining a feature, just its signature. So if it breaks the open/closed prinicple, then it just does it very slightly. I would say it is a small price to pay for not having catcalls.

@@ Line 1: / Line 1: @@
-Can you give an example of when using the variant keyword makes sense?
+'''--[[User:Colin-adams|Colin-adams]] 00:09, 6 November 2007 (PST)''': Can you give an example of when using the <e>variant</e> keyword makes sense?
-As for the frozen keyword, doesn't this break the open/closed principle yet again (I know the example shows an attribute, but the wording suggests a routine could also be marked with a frozen type - does this limit redeclaration)?
+As for the <e>frozen</e> keyword, doesn't this break the open/closed principle yet again (I know the example shows an attribute, but the wording suggests a routine could also be marked with a frozen type - does this limit redeclaration)?
 What is supposed to happen in the multiple constraint case (if the compiler didn't have a limitation)?
-: The 'variant' keyword is nearly the same as the wildcard types introduced in Java. The only difference is the use of a global analysis (i.e. non-modular) to check certain corner cases that are valid although generics are used in the arguments. --[[User:Schoelle|Schoelle]] 03:26, 6 November 2007 (PST)
+: '''--[[User:Schoelle|Schoelle]] 03:26, 6 November 2007 (PST)''': The <e>variant</e> keyword is nearly the same as the wildcard types introduced in Java. The only difference is the use of a global analysis (i.e. non-modular) to check certain corner cases that are valid although generics are used in the arguments.

← Older revision		Revision as of 11:26, 6 November 2007
Line 6:		Line 6:
	--[[User:Colin-adams\|Colin-adams]] 00:09, 6 November 2007 (PST)		--[[User:Colin-adams\|Colin-adams]] 00:09, 6 November 2007 (PST)

−	: The 'variant' keyword is nearly the same as the wildcard types introduced in Java. The only difference is the use of a global analysis (i.e. non-modular) to check certain corner cases that are valid although generics are used in the arguments.	+	: The 'variant' keyword is nearly the same as the wildcard types introduced in Java. The only difference is the use of a global analysis (i.e. non-modular) to check certain corner cases that are valid although generics are used in the arguments. --[[User:Schoelle\|Schoelle]] 03:26, 6 November 2007 (PST)

← Older revision		Revision as of 11:26, 6 November 2007
Line 5:		Line 5:
	What is supposed to happen in the multiple constraint case (if the compiler didn't have a limitation)?		What is supposed to happen in the multiple constraint case (if the compiler didn't have a limitation)?
	--[[User:Colin-adams\|Colin-adams]] 00:09, 6 November 2007 (PST)		--[[User:Colin-adams\|Colin-adams]] 00:09, 6 November 2007 (PST)
		+
		+	: The 'variant' keyword is nearly the same as the wildcard types introduced in Java. The only difference is the use of a global analysis (i.e. non-modular) to check certain corner cases that are valid although generics are used in the arguments.