Transposition - Revision history

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

2006-11-13T23:57:25Z

Transposition, repeated inheritance and replication

← Older revision		Revision as of 23:57, 13 November 2006
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.		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====		====Optimization possibilities for transposition====

Konradm at 19:16, 13 November 2006

2006-11-13T19:16:40Z

← Older revision		Revision as of 19:16, 13 November 2006
Line 1:		Line 1:
	[[Category:ECMA]]		[[Category:ECMA]]
			Author: Matthias Konrad
	==Description==		==Description==
	====The new dynamic binding semantics====		====The new dynamic binding semantics====

Konradm: /* Test */

2006-11-08T05:22:02Z

Test

← 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==~~

Konradm: /* Summary */

2006-11-08T05:21:37Z

Summary

← 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==

Manus at 00:33, 27 October 2006

2006-10-27T00:33:31Z

← Older revision		Revision as of 00:33, 27 October 2006
Line 1:		Line 1:
	[[Category:ECMA]]==Description==		[[Category:ECMA]]
			==Description==
	====The new dynamic binding semantics====		====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:		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:

Manus at 00:33, 27 October 2006

2006-10-27T00:33:23Z

← Older revision		Revision as of 00:33, 27 October 2006
Line 1:		Line 1:
	==Description==		[[Category:ECMA]]==Description==
	====The new dynamic binding semantics====		====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:		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:

Manus: /* Summary */

2006-10-27T00:26:09Z

Summary

← Older revision		Revision as of 00:26, 27 October 2006
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.		# 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).		# 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.

Manus: /* Summary */

2006-10-27T00:21:03Z

Summary

← 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.

Manus at 23:56, 26 October 2006

2006-10-26T23:56:20Z

@@ Line 1: / Line 1: @@
 ====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 126: / Line 127: @@
 ====Optimization possibilities for transposition====
 Apart from its power to describe the semantics of the language, transposition is very (maybe too) expensive. It is certainly not acceptable to really transpose every feature. So we need to find criteria to only transpose when really needed. Interestingly this is quite difficult but it is maybe better to have a simple language and complex compilers than the opposite.

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

2006-10-26T23:43:46Z

Transposition, repeated inheritance and replication

← Older revision		Revision as of 23:43, 26 October 2006
Line 121:		Line 121:
	\|}		\|}

	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 ''f''. One of this features calls ''g1'' and the other one calls ''g2''. This is clearly a conflict. Two transposed features should be allowed to have the same name if and only if they are identical.		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 a simpler.

	====Optimization possibilities for transposition====		====Optimization possibilities for transposition====
	Apart from its power to describe the semantics of the language, transposition is very (maybe too) expensive. It is certainly not acceptable to really transpose every feature. So we need to find criteria to only transpose when really needed. Interestingly this is quite difficult but it is maybe better to have a simple language and complex compilers than the opposite.		Apart from its power to describe the semantics of the language, transposition is very (maybe too) expensive. It is certainly not acceptable to really transpose every feature. So we need to find criteria to only transpose when really needed. Interestingly this is quite difficult but it is maybe better to have a simple language and complex compilers than the opposite.