Difference between revisions of "Talk:Catcall Test Proposal"
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)?
 
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)
 
  
−
: 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.
 +
 
 +
: '''--[[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>.
 +
: 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.

Revision as of 10:53, 6 November 2007

--Colin-adams 00:09, 6 November 2007 (PST): 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)?

--Schoelle 03:26, 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.
--manus 11:53, 6 November 2007 (PST): The variant keyword has to be used whenever you want to preserve today's generic conformance rules. For example assigning a LIST [STRING] to a LIST [ANY] is possible today, but with the new rule, only if you declare it as LIST [variant ANY].
The frozen 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 class A [G -> {B,C}] 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.
Retrieved from "https://dev.eiffel.com/index.php?title=Talk:Catcall_Test_Proposal&oldid=9981"