Difference between revisions of "Talk:Catcall Test Proposal"
Colin-adams (Talk | contribs) (What is the example supposed to mean?) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| 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: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. |
| + | :* 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. | ||
| + | |||
| + | == 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) | ||
Latest revision as of 22:41, 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
variantkeyword 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
variantkeyword has to be used whenever you want to preserve today's generic conformance rules. For example assigning aLIST [STRING]to aLIST [ANY]is possible today, but with the new rule, only if you declare it asLIST [variant ANY]. - The
frozenkeyword 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.
- The
--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.
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.
--Colin-adams 23:41, 6 November 2007 (PST)
