Transposition - Revision history

Konradm: /* Transposition, repeated inheritance and replication */

2006-11-13T23:57:25Z

‎Transposition, repeated inheritance and replication

2006-11-13T19:16:40Z

2006-11-08T05:22:02Z

‎Test

2006-11-08T05:21:37Z

‎Summary

2006-10-27T00:33:31Z

2006-10-27T00:33:23Z

2006-10-27T00:26:09Z

‎Summary

2006-10-27T00:21:03Z

‎Summary

2006-10-26T23:56:20Z

2006-10-26T23:43:46Z

‎Transposition, repeated inheritance and replication

@@ Line 125: / Line 125: @@
 The unfolded form of class ''B'' has two features with name ''f'', since both of them are the same they can just be joined. The unfolded form of class ''D'' also has two features with name ''g''. One of this features calls ''f1'' and the other one calls ''f2''. This is clearly a conflict. Two transposed features should be allowed to have the same name if and only if they are identical.
-This is all there is to say about replication. Again, the fact, that we have a definite set of features for every class makes things a simpler.
+This is all there is to say about replication. Again, the fact, that we have a definite set of features for every class makes things simpler.
 ====Optimization possibilities for transposition====

@@ Line 1: / Line 1: @@
 [[Category:ECMA]]
 ==Description==
 ====The new dynamic binding semantics====

← Older revision		Revision as of 05:22, 8 November 2006
Line 138:		Line 138:
	# The semantics get clearer since by just looking at the text of a class you know which feature will be called (no need for you to perform a mental incremental transposition).		# The semantics get clearer since by just looking at the text of a class you know which feature will be called (no need for you to perform a mental incremental transposition).
	# In real life, there are few occurrences of repeated inheritance that need a select.		# In real life, there are few occurrences of repeated inheritance that need a select.
−	~~==Test==~~

← Older revision		Revision as of 05:21, 8 November 2006
Line 138:		Line 138:
	# The semantics get clearer since by just looking at the text of a class you know which feature will be called (no need for you to perform a mental incremental transposition).		# The semantics get clearer since by just looking at the text of a class you know which feature will be called (no need for you to perform a mental incremental transposition).
	# In real life, there are few occurrences of repeated inheritance that need a select.		# In real life, there are few occurrences of repeated inheritance that need a select.
		+	==Test==

@@ Line 1: / Line 1: @@
-[[Category:ECMA]]==Description==
+[[Category:ECMA]]
 ====The new dynamic binding semantics====
 With the ECMA Eiffel Standard, the dynamic binding semantics of the Eiffel language are almost clearly defined. This new or clarified semantics have some interesting consequences. The following system shows the difference between how the dynamic semantics were (and still are) implemented and how they are specified in the ECMA standard:

@@ Line 136: / Line 136: @@
 # If we use the semantics of the Eiffel Software compiler, transposition only needs to be done for replicated features, thus simplifying the work for compiler writers.
 # The semantics get clearer since by just looking at the text of a class you know which feature will be called (no need for you to perform a mental incremental transposition).
-# In real life, there are few repeated inheritance that needs a select.
+# In real life, there are few occurrences of repeated inheritance that need a select.

← Older revision		Revision as of 00:21, 27 October 2006
Line 133:		Line 133:
	* The new dynamic binding semantics forces every class to perform a transposition of all its inherited features (with little space for optimization, see [[Transposition#Optimization_possibilities_for_transposition\|above]])		* The new dynamic binding semantics forces every class to perform a transposition of all its inherited features (with little space for optimization, see [[Transposition#Optimization_possibilities_for_transposition\|above]])

−	Given the above, one could ask whether the new dynamic binding rules ~~makes~~ sense. If we use the semantics of the Eiffel Software compiler, transposition only needs to be done for replicated features.	+	Given the above, one could ask whether the new dynamic binding rules make sense:
		+	# If we use the semantics of the Eiffel Software compiler, transposition only needs to be done for replicated features, thus simplifying the work for compiler writers.
		+	# The semantics get clearer since by just looking at the text of a class you know which feature will be called (no need for you to perform a mental incremental transposition).
		+	# In real life, there are few repeated inheritance that needs a select.