Forget / Keep Mechanism - Revision history

Manus at 10:15, 11 April 2007

2007-04-11T10:15:31Z

← Older revision		Revision as of 10:15, 11 April 2007
Line 1:		Line 1:
	[[Category:ECMA]]		[[Category:ECMA]]
	{{~~Warning\|'''Warning''': Article under development~~}}		{{UnderConstruction}}

	==Introduction==		==Introduction==

Juliant: /* Consequences */

2007-02-24T07:48:40Z

Consequences

← Older revision		Revision as of 07:48, 24 February 2007
Line 881:		Line 881:

	In class <e>SNAKE</e> the feature <e>feed_a</e> of class <e>ANIMAL</e> will become invalid by the redefinition of the feature <e>a</e>.		In class <e>SNAKE</e> the feature <e>feed_a</e> of class <e>ANIMAL</e> will become invalid by the redefinition of the feature <e>a</e>.

			===Information hiding===

			Consider the following implementation:
			<e>
			class ANIMAL

			feature

			eat (f: FOOD)

			gain_weight
			do
			weight := weight + 3
			end

			end
			</e>

			And the use of class <e>ANIMAL</e>:
			<e>
			local
			a: ANIMAL forget eat
			do
			-- all ok
			a.gain_weight

			end
			</e>

			If now the implementation changes that another feature uses the <e>eat</e> in it's implementation, the type <e>ANIMAL forget eat</e> will loose more features depending on the implementation.

			New implementation:
			<e>
			gain_weight
			do
			eat (food)
			end
			</e>

			<e>
			local
			a: ANIMAL forget eat
			do
			-- this will not work anymore
			a.gain_weight

			end
			</e>

			===Uniqueness of forget types===

			In general, the notion of <e>TYPE forget f</e> may not be unique. If a feature <e>f</e> uses a feature <e>g</e> and vice-versa, the types <e>TYPE forget f</e> and <e>TYPE forget g</e> are equivalent since both have to forget <e>f</e> and <e>g</e>.

			'''''Solution for uniqueness''''': All (public) features which are forgotten have to be named explicitly. Thus if you write <e>TYPE forget f</e> this is not valid until you list all features which are affected. This still leaves the problem of information hiding. You need to know which features use another feature in order to list it in a specific feature in a forget clause. And if later the implementation changes, you have to adapt your forget clauses.

	==Conclusion==		==Conclusion==

Juliant at 01:20, 23 February 2007

2007-02-23T01:20:11Z

← Older revision		Revision as of 01:20, 23 February 2007
Line 801:		Line 801:

	'''''Solution''''': Introduce the <e>inherit {NONE}</e> construct since most declarations of the type <e>export {NONE} all</e> are actually meant as non-conforming inheritance in the first place. Since no conformance between parents from a <e>inherit {NONE}</e> clause exists anyway, the ''forget / keep mechanism'' is not applied to these cases.		'''''Solution''''': Introduce the <e>inherit {NONE}</e> construct since most declarations of the type <e>export {NONE} all</e> are actually meant as non-conforming inheritance in the first place. Since no conformance between parents from a <e>inherit {NONE}</e> clause exists anyway, the ''forget / keep mechanism'' is not applied to these cases.

			===agents===

			...

	===Algorithms===		===Algorithms===

Juliant: /* The Java solution */

2007-02-22T03:39:11Z

The Java solution

← Older revision		Revision as of 03:39, 22 February 2007
Line 730:		Line 730:

	[http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf Official Sun tutorial (PDF)]		[http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf Official Sun tutorial (PDF)]

			[http://mindprod.com/jgloss/generics.html Another tutorial]

	[http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ304 An example]		[http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ304 An example]

Juliant: /* The Java solution */

2007-02-22T03:38:42Z

The Java solution

← Older revision		Revision as of 03:38, 22 February 2007
Line 728:		Line 728:

	With Java 1.5, generics were introduced in the language. A mechanism to prevent cat-calls with generics was introduced as well:		With Java 1.5, generics were introduced in the language. A mechanism to prevent cat-calls with generics was introduced as well:

	~~[http://mindprod.com/jgloss/generics.html A tutorial]~~

	[http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf Official Sun tutorial (PDF)]		[http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf Official Sun tutorial (PDF)]

Juliant: /* COMPARABLE */

2007-02-22T03:35:27Z

COMPARABLE

← Older revision		Revision as of 03:35, 22 February 2007
Line 774:		Line 774:

	With the ''forget mechanism'' this means that when a class inherits from <e>COMPARABLE</e>, no subtype will conform to this class anymore, unless all the compare features are forgotten.		With the ''forget mechanism'' this means that when a class inherits from <e>COMPARABLE</e>, no subtype will conform to this class anymore, unless all the compare features are forgotten.

			'''''Solution''''': Change the class to take a generic arugment and be able to compare to this argument (<e>COMPARABLE [G]</e>)

	===export {NONE} all===		===export {NONE} all===

Juliant: /* Consequences */

2007-02-22T03:34:40Z

Consequences

← Older revision		Revision as of 03:34, 22 February 2007
Line 768:		Line 768:

	'''''Solution''''': Remove the <e>like Current</e> arguments from <e>ANY</e>. Change the argument of <e>is_equal</e> and <e>copy</e> to type <e>ANY</e>. Then either introduce a precondition to require conformance of argument and object or add a type checks to the actual implementation of the features. This is actually done in the ECMA standard but not yet implemented in EiffelBase.		'''''Solution''''': Remove the <e>like Current</e> arguments from <e>ANY</e>. Change the argument of <e>is_equal</e> and <e>copy</e> to type <e>ANY</e>. Then either introduce a precondition to require conformance of argument and object or add a type checks to the actual implementation of the features. This is actually done in the ECMA standard but not yet implemented in EiffelBase.

			===COMPARABLE===

			In the class <e>COMPARABLE</e> all features are defined with a <e>like Current</e> argument.

			With the ''forget mechanism'' this means that when a class inherits from <e>COMPARABLE</e>, no subtype will conform to this class anymore, unless all the compare features are forgotten.

	===export {NONE} all===		===export {NONE} all===

Juliant: /* The Java solution */

2007-02-22T01:23:35Z

The Java solution

← Older revision		Revision as of 01:23, 22 February 2007
Line 726:		Line 726:

	===The Java solution===		===The Java solution===

			With Java 1.5, generics were introduced in the language. A mechanism to prevent cat-calls with generics was introduced as well:

	[http://mindprod.com/jgloss/generics.html A tutorial]		[http://mindprod.com/jgloss/generics.html A tutorial]

Juliant: /* The Java solution */

2007-02-22T01:22:22Z

The Java solution

← Older revision		Revision as of 01:22, 22 February 2007
Line 728:		Line 728:

	[http://mindprod.com/jgloss/generics.html A tutorial]		[http://mindprod.com/jgloss/generics.html A tutorial]

	[http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf Official Sun tutorial (PDF)]		[http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf Official Sun tutorial (PDF)]

	[http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ304 An example]		[http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ304 An example]

Juliant: /* Generics */

2007-02-22T01:22:08Z

Generics

← Older revision		Revision as of 01:22, 22 February 2007
Line 724:		Line 724:
	...		...
	</e>		</e>

			===The Java solution===

			[http://mindprod.com/jgloss/generics.html A tutorial]
			[http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf Official Sun tutorial (PDF)]
			[http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ304 An example]

	==Consequences==		==Consequences==