Personal view about catcall solution - Revision history

Juliant at 22:37, 23 June 2007

2007-06-23T22:37:33Z

← Older revision		Revision as of 22:37, 23 June 2007
Line 1:		Line 1:
			[[Category:Catcall]]

	--[[User:Juliant\|Juliant]] 07:30, 23 June 2007 (CEST)		--[[User:Juliant\|Juliant]] 07:30, 23 June 2007 (CEST)

Juliant: /* NUMERIC / COMPARABLE and the like */

2007-06-23T05:45:10Z

NUMERIC / COMPARABLE and the like

← Older revision		Revision as of 05:45, 23 June 2007
Line 17:		Line 17:
	We identified NUMERIC, COMPARABLE as well as several ANY features like is_equal, copy, ... as the source of argument covariance in ordinary types. NUMERIC and COMPARABLE rely on `like Current'. I would design classes which have a need for argument covariance in the sense of 'like Current' over generics:		We identified NUMERIC, COMPARABLE as well as several ANY features like is_equal, copy, ... as the source of argument covariance in ordinary types. NUMERIC and COMPARABLE rely on `like Current'. I would design classes which have a need for argument covariance in the sense of 'like Current' over generics:
	==== NUMERIC / COMPARABLE and the like ====		==== NUMERIC / COMPARABLE and the like ====
			<e>
	class NUMERIC [G]		class NUMERIC [G]
	feature		feature
Line 31:		Line 32:
	-- ...		-- ...
	end		end
			</e>

	The same is possible for COMPARABLE and makes it even more expressive in conjunction with the ''Usage-site variance''.		The same is possible for COMPARABLE and makes it even more expressive in conjunction with the ''Usage-site variance''.

Juliant at 05:44, 23 June 2007

2007-06-23T05:44:18Z

← Older revision		Revision as of 05:44, 23 June 2007
Line 46:		Line 46:


	Your opinion?		Your opinion? Add it here.


	----		----

Juliant at 05:43, 23 June 2007

2007-06-23T05:43:56Z

← Older revision		Revision as of 05:43, 23 June 2007
Line 41:		Line 41:
	I also think that the solution by using renaming is ok in the rare cases where a sudden need for covariant argument redefinition occurs. Usually this is a setter of covariant redefined attribute. Other proposals, like the dog proposal, cannot help here either as the need for covariance was not foreseen.		I also think that the solution by using renaming is ok in the rare cases where a sudden need for covariant argument redefinition occurs. Usually this is a setter of covariant redefined attribute. Other proposals, like the dog proposal, cannot help here either as the need for covariance was not foreseen.
	After removing ordinary argument covariance from our libraries we could make the covariant feature redefinition configurable on a per cluster basis to support legacy code.		After removing ordinary argument covariance from our libraries we could make the covariant feature redefinition configurable on a per cluster basis to support legacy code.


			----


			Your opinion?


			----

Juliant at 05:43, 23 June 2007

2007-06-23T05:43:18Z

← Older revision		Revision as of 05:43, 23 June 2007
Line 6:		Line 6:

	For this reason I suggest using the [[DOG proposal]] for non-generic covariance. Although this may restrict the use of covariance severely as you need to know in advance which features can be used covariantly, it still allows features to declare parameters as <e>like Current</e> and thus implicitly as covariant.		For this reason I suggest using the [[DOG proposal]] for non-generic covariance. Although this may restrict the use of covariance severely as you need to know in advance which features can be used covariantly, it still allows features to declare parameters as <e>like Current</e> and thus implicitly as covariant.


			----


Line 13:		Line 16:

	We identified NUMERIC, COMPARABLE as well as several ANY features like is_equal, copy, ... as the source of argument covariance in ordinary types. NUMERIC and COMPARABLE rely on `like Current'. I would design classes which have a need for argument covariance in the sense of 'like Current' over generics:		We identified NUMERIC, COMPARABLE as well as several ANY features like is_equal, copy, ... as the source of argument covariance in ordinary types. NUMERIC and COMPARABLE rely on `like Current'. I would design classes which have a need for argument covariance in the sense of 'like Current' over generics:
	=== NUMERIC / COMPARABLE and the like ===		==== NUMERIC / COMPARABLE and the like ====
	class NUMERIC [G]		class NUMERIC [G]
	feature		feature
Line 33:		Line 36:
	These classes are both basic building structures of the base library which would need to be adapted. But a redesign is planned anyway for the near future as far as I now.		These classes are both basic building structures of the base library which would need to be adapted. But a redesign is planned anyway for the near future as far as I now.

	=== is_equal, copy and the like===		==== is_equal, copy and the like====
	They can be made non generic with added preconditions or have already another solution like the ''~'' operator.		They can be made non generic with added preconditions or have already another solution like the ''~'' operator.

	I also think that the solution by using renaming is ok in the rare cases where a sudden need for covariant argument redefinition occurs. Usually this is a setter of covariant redefined attribute. Other proposals, like the dog proposal, cannot help here either as the need for covariance was not foreseen.		I also think that the solution by using renaming is ok in the rare cases where a sudden need for covariant argument redefinition occurs. Usually this is a setter of covariant redefined attribute. Other proposals, like the dog proposal, cannot help here either as the need for covariance was not foreseen.
	After removing ordinary argument covariance from our libraries we could make the covariant feature redefinition configurable on a per cluster basis to support legacy code.		After removing ordinary argument covariance from our libraries we could make the covariant feature redefinition configurable on a per cluster basis to support legacy code.

Juliant at 05:42, 23 June 2007

2007-06-23T05:42:38Z

← Older revision		Revision as of 05:42, 23 June 2007
Line 5:		Line 5:
	As this only solves the case of generics, another solution has to be used for non-generic types. Again, the general remarks section explaines that another solution is needed to solve the catcall problem of non-generic types as otherwise the expressiveness of the programmer is restricted if the covariantly redefined features (e.g. is_equal) and the features with formal generic parameters (e.g. put) are treated the same.		As this only solves the case of generics, another solution has to be used for non-generic types. Again, the general remarks section explaines that another solution is needed to solve the catcall problem of non-generic types as otherwise the expressiveness of the programmer is restricted if the covariantly redefined features (e.g. is_equal) and the features with formal generic parameters (e.g. put) are treated the same.

	For this reason I suggest using the [[DOG proposal]] for non-generic covariance. Although this may restrict the use of covariance ~~severly~~ as you need to know in advance which features can be used covariantly, it still allows features to declare parameters as <e>like Current</e> and thus implicitly as covariant.		For this reason I suggest using the [[DOG proposal]] for non-generic covariance. Although this may restrict the use of covariance severely as you need to know in advance which features can be used covariantly, it still allows features to declare parameters as <e>like Current</e> and thus implicitly as covariant.


			--[[User:Seilerm\|Seilerm]] 07:41, 23 June 2007 (CEST)

			I find the expressiveness of the [[Usage-site_variance]] quite astonishing. A huge plus is that it solved the agent mechanism flawlessly.

			We identified NUMERIC, COMPARABLE as well as several ANY features like is_equal, copy, ... as the source of argument covariance in ordinary types. NUMERIC and COMPARABLE rely on `like Current'. I would design classes which have a need for argument covariance in the sense of 'like Current' over generics:
			=== NUMERIC / COMPARABLE and the like ===
			class NUMERIC [G]
			feature
			plus alias "+" (a_other: G): G
			deferred
			end
			end

			class INTEGER

			inherit
			NUMERIC [INTEGER]
			feature
			-- ...
			end

			The same is possible for COMPARABLE and makes it even more expressive in conjunction with the ''Usage-site variance''.

			These classes are both basic building structures of the base library which would need to be adapted. But a redesign is planned anyway for the near future as far as I now.

			=== is_equal, copy and the like===
			They can be made non generic with added preconditions or have already another solution like the ''~'' operator.

			I also think that the solution by using renaming is ok in the rare cases where a sudden need for covariant argument redefinition occurs. Usually this is a setter of covariant redefined attribute. Other proposals, like the dog proposal, cannot help here either as the need for covariance was not foreseen.
			After removing ordinary argument covariance from our libraries we could make the covariant feature redefinition configurable on a per cluster basis to support legacy code.

Juliant at 05:30, 23 June 2007

2007-06-23T05:30:18Z

New page

--[[User:Juliant|Juliant]] 07:30, 23 June 2007 (CEST)

As explained in the [[Comparison of catcall solutions#General_remarks|general remarks]] section, you need to be able to express contravariance to be able to correctly model agents and comparator objects. For this reason, I suggest using the [[usage-site variance]] for generics since it is powerful enough to model the agents right.

As this only solves the case of generics, another solution has to be used for non-generic types. Again, the general remarks section explaines that another solution is needed to solve the catcall problem of non-generic types as otherwise the expressiveness of the programmer is restricted if the covariantly redefined features (e.g. is_equal) and the features with formal generic parameters (e.g. put) are treated the same.

For this reason I suggest using the [[DOG proposal]] for non-generic covariance. Although this may restrict the use of covariance severly as you need to know in advance which features can be used covariantly, it still allows features to declare parameters as <e>like Current</e> and thus implicitly as covariant.