Objectless Calls - Revision history

Conaclos: Syntax update

2013-05-08T20:01:19Z

Syntax update

← Older revision		Revision as of 20:01, 8 May 2013
Line 16:		Line 16:
	feature {NONE} -- Initialization		feature {NONE} -- Initialization

	make (a_arg: ?VALUE)		make (a_arg: detachable VALUE)
	require		require
	a_arg_is_valid_value: is_valid_value (a_arg)		a_arg_is_valid_value: is_valid_value (a_arg)
Line 25:		Line 25:
	feature -- Query		feature -- Query

	is_valid_value (a_value: ?VALUE): BOOLEAN		is_valid_value (a_value: detachable VALUE): BOOLEAN
	-- Determines if an argument is valid		-- Determines if an argument is valid
	do		do
Line 41:		Line 41:
	feature -- Query		feature -- Query

	is_valid_value (a_value: ?VALUE): BOOLEAN		is_valid_value (a_value: detachable VALUE): BOOLEAN
	-- Determines if an argument is valid		-- Determines if an argument is valid
	do		do
Line 61:		Line 61:
	feature {NONE} -- Initialization		feature {NONE} -- Initialization

	make (a_arg: ?VALUE)		make (a_arg: detachable VALUE)
	require		require
	a_arg_is_valid_value: is_valid_value (a_arg)		a_arg_is_valid_value: is_valid_value (a_arg)
Line 72:		Line 72:
	A client now has to create an instance of <e>A_VALIDATOR</e> in order to create an instance of <e>A</e>. The result is a performance hit because of an additional object creation and heap allocation.		A client now has to create an instance of <e>A_VALIDATOR</e> in order to create an instance of <e>A</e>. The result is a performance hit because of an additional object creation and heap allocation.

	<e>process (a_value: ?VALUE)		<e>process (a_value: detachable VALUE)
	local		local
	l_a: A		l_a: A
Line 94:		Line 94:
	feature {NONE} -- Initialization		feature {NONE} -- Initialization

	make (a_arg: ?VALUE)		make (a_arg: detachable VALUE)
	do		do
	...		...
Line 101:		Line 101:
	feature -- Query		feature -- Query

	is_valid_value (a_value: ?VALUE): BOOLEAN		is_valid_value (a_value: detachable VALUE): BOOLEAN
	-- Determines if an argument is valid		-- Determines if an argument is valid
	do		do
Line 118:		Line 118:
	feature -- Query		feature -- Query

	is_valid_value (a_value: ?VALUE): BOOLEAN		is_valid_value (a_value: detachable VALUE): BOOLEAN
	-- Determines if an argument is valid		-- Determines if an argument is valid
	do		do
Line 141:		Line 141:
	feature {NONE} -- Initialization		feature {NONE} -- Initialization

	make (a_arg: ?VALUE)		make (a_arg: detachable VALUE)
	require		require
	a_arg_is_valid_value: is_valid_value (a_arg)		a_arg_is_valid_value: is_valid_value (a_arg)
Line 204:		Line 204:
	feature {NONE} -- Initialization		feature {NONE} -- Initialization

	make (a_arg: ?VALUE)		make (a_arg: detachable VALUE)
	require		require
	a_arg_is_valid_value: is_valid_value (a_arg)		a_arg_is_valid_value: is_valid_value (a_arg)
Line 213:		Line 213:
	feature -- Query		feature -- Query

	objectless is_valid_value (a_value: ?VALUE): BOOLEAN		objectless is_valid_value (a_value: detachable VALUE): BOOLEAN
	-- Determines if an argument is valid		-- Determines if an argument is valid
	do		do
Line 226:		Line 226:
	For clients wanting to create an instance of <e>A</e>, the following code can now be written and guaranteed. There is no need for pulling up the feature <e>is_valid_value</e> into a separate validation class, or the creation of the validation class to perform prospective argument validation.		For clients wanting to create an instance of <e>A</e>, the following code can now be written and guaranteed. There is no need for pulling up the feature <e>is_valid_value</e> into a separate validation class, or the creation of the validation class to perform prospective argument validation.

	<e>process (a_value: ?VALUE)		<e>process (a_value: detachable VALUE)
	-- Processes a value node.		-- Processes a value node.
	local		local

Peter gummer: /* A Proposal */

2008-03-15T11:54:09Z

A Proposal

← Older revision		Revision as of 11:54, 15 March 2008
Line 169:		Line 169:
	Due to objectless calls being a language mechanism rather than a run-time attribute (such as a once's process/thread status) a new keyword is going to be required, minimizing possible conflicts with feature names used in existing systems. For this proposal the author suggests ''objectless'', indicating a objectless call.		Due to objectless calls being a language mechanism rather than a run-time attribute (such as a once's process/thread status) a new keyword is going to be required, minimizing possible conflicts with feature names used in existing systems. For this proposal the author suggests ''objectless'', indicating a objectless call.

	Objectless class should be permitted on ~~function~~, both regular and once functions. It is up to debate to indicate if procedures and class attributes are permitted to be objectless		Objectless class should be permitted on functions, both regular and once functions. It is up to debate to indicate if procedures and class attributes are permitted to be objectless.

	The '''objectless''' keyword should appear as a routine modifier, as with the <e>frozen</e> keyword. Just as the use of <e>frozen</e> is used to dictate to subclasses a routine cannot be redefined/undefined, '''objectless''' has a similar standing when being called, indicating (not dictating) to clients to use the static calling convention. Secondary to the argument, such placement is clear to a reader the call is objectless. The only alternative foreseeable placement for an '''objectless''' keyword would be a prior to a routine's type keyword (<e>do, once, deferred, external</e>), however in the case of the previous arguments of readability, it's the author's opinion the keyword should not appear there. There may be a suggestion to using a routine's <e>note</e> clause to indicate objectless status but this is a bad idea, not only for readability but because note clauses are informative structures that should not change routine convention.		The '''objectless''' keyword should appear as a routine modifier, as with the <e>frozen</e> keyword. Just as the use of <e>frozen</e> is used to dictate to subclasses a routine cannot be redefined/undefined, '''objectless''' has a similar standing when being called, indicating (not dictating) to clients to use the static calling convention. Secondary to the argument, such placement is clear to a reader the call is objectless. The only alternative foreseeable placement for an '''objectless''' keyword would be a prior to a routine's type keyword (<e>do, once, deferred, external</e>), however in the case of the previous arguments of readability, it's the author's opinion the keyword should not appear there. There may be a suggestion to using a routine's <e>note</e> clause to indicate objectless status but this is a bad idea, not only for readability but because note clauses are informative structures that should not change routine convention.

Peter gummer: /* A Proposal */

2008-03-15T11:53:15Z

A Proposal

← Older revision		Revision as of 11:53, 15 March 2008
Line 167:		Line 167:
	In order to complete this document the author indicates a proposal for such a mechanism for permitting objectless calls.		In order to complete this document the author indicates a proposal for such a mechanism for permitting objectless calls.

	Due to objectless calls being a language mechanism rather than a run-time attribute (such as a once's process/thread status) a new keyword is going to be required, minimizing possible conflicts with feature names ~~use~~ in existing systems. For this proposal the author ~~suggest~~ ''objectless'', indicating a objectless call.		Due to objectless calls being a language mechanism rather than a run-time attribute (such as a once's process/thread status) a new keyword is going to be required, minimizing possible conflicts with feature names used in existing systems. For this proposal the author suggests ''objectless'', indicating a objectless call.

	Objectless class should be permitted on function, both regular and once functions. It is up to debate to indicate if procedures and class attributes are permitted to be objectless		Objectless class should be permitted on function, both regular and once functions. It is up to debate to indicate if procedures and class attributes are permitted to be objectless

Peter gummer: /* The Performance Problem */

2008-03-15T11:49:33Z

The Performance Problem

← Older revision		Revision as of 11:49, 15 March 2008
Line 160:		Line 160:
	After indicating the problems with the object creation and overuse of inheritance, the issues of performance can be indicated with context.		After indicating the problems with the object creation and overuse of inheritance, the issues of performance can be indicated with context.

	The problem related to creation performance has already been indicated, doubling the object creation, or more conservatively the ~~expensive~~ of an attribute access, just to query argument validity. The problem is exacerbated by making a dynamic call to the validation routine even though none is needed.		The problem related to creation performance has already been indicated, doubling the object creation, or more conservatively the expense of an attribute access, just to query argument validity. The problem is exacerbated by making a dynamic call to the validation routine even though none is needed.

	On that last remark, there are performance ~~implication~~ using shared objects to access a singleton object. All the calls are ~~called~~ on an instance so ~~required~~ the overhead to access the instance, in addition the calls cannot be optimized by the compiler and so are dynamically dispatched - far more expensive on performance than a single static call, which the Eiffel compiler could generate with use of an objectless language addition.		On that last remark, there are performance implications in using shared objects to access a singleton object. All the calls are on an instance, and so require the overhead to access the instance; in addition the calls cannot be optimized by the compiler and so are dynamically dispatched - far more expensive on performance than a single static call, which the Eiffel compiler could generate with the use of an objectless language addition.

	== A Proposal ==		== A Proposal ==

Peter gummer: /* Overuse of Inheritance */

2008-03-15T11:44:40Z

Overuse of Inheritance

← Older revision		Revision as of 11:44, 15 March 2008
Line 153:		Line 153:

	== Overuse of Inheritance ==		== Overuse of Inheritance ==
	Due to the lack of an objectless routine mechanism in the Eiffel language there is tenancy to overuse inheritance because it is required. There is a need to use "shared" objects which expose a single instance of a class through a once function. If there was an objectless mechanism classes could just use the a objectless once function. The Eiffel compiler and EiffelStudio IDE make heavy use of shared classes, prefixed <e>SHARED_</e>. In a recent code review <e>FEATURE_I</e> inherits 24 parent classes, only 6 are actual affecting the model and functionality of the class. That is 18 classes inherited for shared access alone!		Due to the lack of an objectless routine mechanism in the Eiffel language there is tenancy to overuse inheritance because it is required. There is a need to use "shared" objects which expose a single instance of a class through a once function. If there was an objectless mechanism classes could just use the a objectless once function. The Eiffel compiler and EiffelStudio IDE make heavy use of shared classes, prefixed <e>SHARED_</e>. In a recent code review <e>FEATURE_I</e> inherits 24 parent classes, of which only 6 are actual affecting the model and functionality of the class. That is 18 classes inherited for shared access alone!

	The use of inheritance causes another problem, performance degradation.		The use of inheritance causes another problem, performance degradation.

Peter gummer: Typos

2008-03-15T11:34:31Z

Typos

← Older revision		Revision as of 11:34, 15 March 2008
Line 82:		Line 82:
	end</e>		end</e>

	Apart from the fragmentation and additional creation, it seems like the problem is solved. However, take the following adjustments, likely to transpire when an developer other than the original (maybe even the original developer) subclasses <e>A</e> to create a new type <e>B</e>:		Apart from the fragmentation and additional creation, it seems like the problem is solved. However, take the following adjustments, likely to transpire when a developer other than the original (maybe even the original developer) subclasses <e>A</e> to create a new type <e>B</e>:

	<e>class B		<e>class B
Line 109:		Line 109:
	end</e>		end</e>

	The ~~affect~~ isn't completely obvious. This is a common scenario and is actually a bug in <e>B</e>. The implementation does not follow the existing model of <e>A</e>, that is to say fragment and implement an additional class <e>B_VALIDATOR</e>. The real implementation needs to be:		The effect isn't completely obvious. This is a common scenario and is actually a bug in <e>B</e>. The implementation does not follow the existing model of <e>A</e>, that is to say fragment and implement an additional class <e>B_VALIDATOR</e>. The real implementation needs to be:

	<e>class B_VALIDATION		<e>class B_VALIDATION

Paulb at 21:27, 14 March 2008

2008-03-14T21:27:19Z

← Older revision		Revision as of 21:27, 14 March 2008
Line 1:		Line 1:
	~~{{UnderConstruction}}~~		[[Category:ECMA]]
			Author: [[User:Paulb\| Paul Bates]]

	In this proposal the author highlights some of the advantages of adding a new language mechanism to Eiffel, permitting objectless (known as static in C/C++ and derivative languages) calls of Eiffel implementation. The introduction of objectless calls in Eiffel resolves issues regarding contract guarantees, creation contracts, overuse of "shared" inheritance and can solve a performance related issue where the Eiffel compiler cannot optimize calls because dynamic dispatch.		In this proposal the author highlights some of the advantages of adding a new language mechanism to Eiffel, permitting objectless (known as static in C/C++ and derivative languages) calls of Eiffel implementation. The introduction of objectless calls in Eiffel resolves issues regarding contract guarantees, creation contracts, overuse of "shared" inheritance and can solve a performance related issue where the Eiffel compiler cannot optimize calls because dynamic dispatch.

Paulb: /* Extensions */

2008-03-14T21:26:37Z

Extensions

← Older revision		Revision as of 21:26, 14 March 2008
Line 237:		Line 237:

	=== Extensions ===		=== Extensions ===
	One extension to the proposal and possible advantage over languages with a similar mechanism is the possibility to redefine a objectless routine. The semantics of this have clear rules that govern the behavior of calls and the calling convention used. This extension requires consideration now because of impacts on user code in the future if the language is to adopt the extension.		One extension to the proposal and possible advantage over languages with a similar mechanism is the possibility to redefine a objectless routine. The semantics of this have clear rules that govern the behavior of calls and the calling convention used. This extension requires consideration now because of possible impacts on user code in the future, if the language is to adopt the extension.

			Unlike other languages, it should be possible to redefine any objectless routine.

	For the purpose of explaining the semantics of redefinition, the following classes are used.		For the purpose of explaining the semantics of redefinition, the following classes are used.
Line 295:		Line 297:
	end</e>		end</e>

	In instance redefinition, when ~~call~~ <e>{A}.f</e> the version from <e>A</e> will be taken because a client called <e>f</e> using the static calling convention. However, attempting to call <e>{B}.f</e> will result in a compile-time error because <e>f</e> is not accessible statically, since it has been redefined as an instance routine.		In instance redefinition, when calling <e>{A}.f</e>, the version from <e>A</e> will be taken because a client called <e>f</e> using the static calling convention. However, attempting to call <e>{B}.f</e> will result in a compile-time error because <e>f</e> is not accessible statically, since it has been redefined as an instance routine.

	==== Instance Call Semantics ====		==== Instance Call Semantics ====
	When calling <e>f</e> on an attached entity, of type <e>A</e> or a subtype, the call semantics behave in the same way as every other call - using dynamic dispatch. If an instance of <e>B</e> is polymorphically assigned to an instance of <e>A</e> and <e>B</e> redefines <e>f</e>, ~~either~~ objectlessly or otherwise, the call is made on the dynamic type of the attached entity, in this case <e>B</e>.		When calling <e>f</e> on an attached entity, of type <e>A</e> or a subtype, the call semantics behave in the same way as every other call - using dynamic dispatch. If an instance of <e>B</e> is polymorphically assigned to an instance of <e>A</e> and <e>B</e> redefines <e>f</e>, objectlessly or otherwise, the call is made on the dynamic type of the attached entity, in this case <e>B</e>'s version.

	From within the confines of <e>A</e>, or a subclass of it, an an unqualified call to <e>f</e> the call should be treated in the same way as using an attached entity <e>Current.f</e>, that is, the call is dynamically dispatched. This behavoir can be overridden using the static access calling convention.

	For example, when <e>B</e> redefines <e>f</e>, in <e>A</e>, it can be written <e>{A}.f</e> to ensure the version of <e>f</e> in <e>A</e> is called. Conversely in <e>A</e> calling <e>f</e> unqualified will dispatch the call, resulting in <e>f</e>'s implementation in <e>B</e> being called.		From within the confines of <e>A</e>, or a subclass of it, an an unqualified call to <e>f</e> the call should be treated in the same way as using an attached entity <e>Current.f</e>, that is, the call is dynamically dispatched. This behavior can be overridden using the static access calling convention. For example, when <e>B</e> redefines <e>f</e>, in <e>A</e>, it can be written <e>{A}.f</e> to ensure the version of <e>f</e> in <e>A</e> is called. Conversely in <e>A</e> calling <e>f</e> unqualified will dispatch the call, resulting in <e>f</e>'s implementation in <e>B</e> being called.

Paulb at 21:19, 14 March 2008

2008-03-14T21:19:55Z

← Older revision		Revision as of 21:19, 14 March 2008
Line 1:		Line 1:
	{{UnderConstruction}}		{{UnderConstruction}}
	In ~~the~~ proposal the author ~~highlight~~ some of the advantages of adding a new mechanism to ~~the~~ Eiffel ~~language to permit~~ objectless (known as static in C/C++ and derivative languages) calls. The introduction of objectless calls in Eiffel resolves issues regarding contract guarantees, creation contracts, overuse of "shared" inheritance and can solve a performance related issue ~~using~~ dynamic dispatch.		In this proposal the author highlights some of the advantages of adding a new language mechanism to Eiffel, permitting objectless (known as static in C/C++ and derivative languages) calls of Eiffel implementation. The introduction of objectless calls in Eiffel resolves issues regarding contract guarantees, creation contracts, overuse of "shared" inheritance and can solve a performance related issue where the Eiffel compiler cannot optimize calls because dynamic dispatch.

	It is in the author's opinion that objectless calls are a necessary addition for the continued improvement of the Eiffel language, and were overlooked when defining the ECMA standard.		It is in the author's opinion that objectless calls are a necessary addition for the continued improvement of the Eiffel language, and were overlooked when defining the ECMA standard.
Line 33:		Line 33:
	Here there is the classic chicken and egg problem; A client needs to validate any prospective creation argument to create an instance of <e>A</e> but requires an instance of <e>A</e> in order to validate it.		Here there is the classic chicken and egg problem; A client needs to validate any prospective creation argument to create an instance of <e>A</e> but requires an instance of <e>A</e> in order to validate it.

	There is a solution, but it is far from elegant, fragments class design and opens avenues to bugs. The solution is to refactor and pull up <e>is_valid_value</e> into a validation "helper" class ~~to assist~~ <e>A</e>:		There is a solution but it is far from elegant, fragments class design and opens avenues to bugs. The solution is to refactor and pull up <e>is_valid_value</e> into a validation helper class, assisting <e>A</e>:

	<e>class A_VALIDATION		<e>class A_VALIDATION
Line 47:		Line 47:
	end</e>		end</e>

	Now there has been a ~~validator~~ class defined, with implementation that actually belongs in <e>A</e>, <e>A</e> can now be defined as:		Now there has been a validation class defined, with implementation that actually belongs in <e>A</e>, <e>A</e> can now be defined as:

	<e>class A		<e>class A
Line 80:		Line 80:
	end</e>		end</e>

	Apart from the fragmentation and additional creation, it seems like the problem is solved. However, take the following adjustments likely to transpire when an developer other than the ~~orginal~~ (maybe ~~event~~ the ~~orginal~~ developer) subclasses <e>A</e> to create a new type <e>B</e>:		Apart from the fragmentation and additional creation, it seems like the problem is solved. However, take the following adjustments, likely to transpire when an developer other than the original (maybe even the original developer) subclasses <e>A</e> to create a new type <e>B</e>:

	<e>class B		<e>class B
Line 107:		Line 107:
	end</e>		end</e>

	The affect isn't ~~that~~ obvious. This is a common scenario and is actually a bug ~~because the~~ implementation does not follow the existing model of <e>A</e>, that is to say fragment and implement an additional class <e>B_VALIDATOR</e>. The real implementation ~~should have been~~:		The affect isn't completely obvious. This is a common scenario and is actually a bug in <e>B</e>. The implementation does not follow the existing model of <e>A</e>, that is to say fragment and implement an additional class <e>B_VALIDATOR</e>. The real implementation needs to be:

	<e>class B_VALIDATION		<e>class B_VALIDATION
Line 124:		Line 124:
	end</e>		end</e>

	Now there has been a ~~validator~~ class defined, with implementation that actually belongs in <e>B</e>, <e>B</e> can now be defined as:		Now there has been a validation class defined, with implementation that actually belongs in <e>B</e>, <e>B</e> can now be defined as:

	<e>class B		<e>class B
Line 148:		Line 148:
	end</e>		end</e>

	Only now can a client safely create an instance of <e>B</e>, but this time using <e>B_VALIDATOR</e>. So for a simple two class model there now exists four classes and an additional ~~performace~~ hit for the creation (or instance access of using a once function) ~~for~~ the validator ~~instance~~.		Only now can a client safely create an instance of <e>B</e>, but this time using <e>B_VALIDATOR</e>. So for a simple two class model there now exists four classes and an additional performance hit for the creation (or instance access of using a once function) of the validator instances.

	== Overuse of Inheritance ==		== Overuse of Inheritance ==
Line 158:		Line 158:
	After indicating the problems with the object creation and overuse of inheritance, the issues of performance can be indicated with context.		After indicating the problems with the object creation and overuse of inheritance, the issues of performance can be indicated with context.

	The problem related to creation performance has already been indicated, doubling the object creation, or the expensive of an attribute access, just to query argument validity. The problem is exacerbated by making a dynamic call to the validation routine even though none is needed.		The problem related to creation performance has already been indicated, doubling the object creation, or more conservatively the expensive of an attribute access, just to query argument validity. The problem is exacerbated by making a dynamic call to the validation routine even though none is needed.

	On that last remark, there are ~~serious~~ performance implication using shared objects to access a singleton object. All the calls are called on an instance so required the overhead to access the instance, in addition the calls cannot be optimized by the compiler and so are dynamically dispatched - far more expensive on performance than a single static call, which the Eiffel compiler could generate with use of an objectless language addition.		On that last remark, there are performance implication using shared objects to access a singleton object. All the calls are called on an instance so required the overhead to access the instance, in addition the calls cannot be optimized by the compiler and so are dynamically dispatched - far more expensive on performance than a single static call, which the Eiffel compiler could generate with use of an objectless language addition.

	== A Proposal ==		== A Proposal ==
Line 169:		Line 169:
	Objectless class should be permitted on function, both regular and once functions. It is up to debate to indicate if procedures and class attributes are permitted to be objectless		Objectless class should be permitted on function, both regular and once functions. It is up to debate to indicate if procedures and class attributes are permitted to be objectless

	The '''objectless''' keyword should appear as a routine modifier, as with the <e>frozen</e> keyword. Just as the use of <e>frozen</e> is used to dictate to subclasses a routine cannot be redefined/undefined, '''objectless''' has a similar standing when being called, indicating (not dictating) to clients to use the static calling convention. Secondary to the argument such placement is clear to a reader the call is objectless. The only alternative foreseeable placement for an '''objectless''' keyword would be a prior to a routine's type keyword <e>do, once, deferred, external</e>, however in the case of the previous arguments of readability, it's the author's opinion the keyword should not appear there. There may be a suggestion to using a routine's <e>note</e> clause to indicate objectless status but this is a bad idea, not only for readability but because note clauses are informative structures that should not change routine ~~semantics~~.		The '''objectless''' keyword should appear as a routine modifier, as with the <e>frozen</e> keyword. Just as the use of <e>frozen</e> is used to dictate to subclasses a routine cannot be redefined/undefined, '''objectless''' has a similar standing when being called, indicating (not dictating) to clients to use the static calling convention. Secondary to the argument, such placement is clear to a reader the call is objectless. The only alternative foreseeable placement for an '''objectless''' keyword would be a prior to a routine's type keyword (<e>do, once, deferred, external</e>), however in the case of the previous arguments of readability, it's the author's opinion the keyword should not appear there. There may be a suggestion to using a routine's <e>note</e> clause to indicate objectless status but this is a bad idea, not only for readability but because note clauses are informative structures that should not change routine convention.

	<e>class A		<e>class A
Line 189:		Line 189:
	end</e>		end</e>

	Using '''objectless''' is an indication to client, use the static calling convention is permitted but is not necessary. Making the same call on an attached entity will make		Using '''objectless''' is an indication to client, use the static calling convention is permitted but is not necessary. Making the same call on an attached entity as a client will make the same call, as long as the entity is attached.

			=== Solving the Creation Problem ===

	~~=== Solving~~ the Creation Problem ~~===~~		To indicate how objectless calls can solve the issue highlighted in [#The_Creation_Problem The Creation Problem], consider the following code.

	<e>class A		<e>class A
Line 221:		Line 222:
	end</e>		end</e>

	For clients wanting to create an instance of <e>A</e>, the following code can now be written and ~~guarenteed~~.		For clients wanting to create an instance of <e>A</e>, the following code can now be written and guaranteed. There is no need for pulling up the feature <e>is_valid_value</e> into a separate validation class, or the creation of the validation class to perform prospective argument validation.

	<e>process (a_value: ?VALUE)		<e>process (a_value: ?VALUE)
Line 236:		Line 237:

	=== Extensions ===		=== Extensions ===
	One extension to the proposal and possible advantage over languages with a similar mechanism is the possibility to redefine a objectless routine. The semantics of this have clear rules that govern the ~~behavoir~~ of calls and the calling convention used. This extension requires consideration now because of impacts on user code in the future if the language is to adopt the extension.		One extension to the proposal and possible advantage over languages with a similar mechanism is the possibility to redefine a objectless routine. The semantics of this have clear rules that govern the behavior of calls and the calling convention used. This extension requires consideration now because of impacts on user code in the future if the language is to adopt the extension.

	For the purpose of explaining the semantics of redefinition, the following classes are used.		For the purpose of explaining the semantics of redefinition, the following classes are used.

Paulb: /* The Performance Problem */

2008-03-14T19:05:23Z

The Performance Problem

← Older revision		Revision as of 19:05, 14 March 2008
Line 156:		Line 156:

	== The Performance Problem ==		== The Performance Problem ==
			After indicating the problems with the object creation and overuse of inheritance, the issues of performance can be indicated with context.

			The problem related to creation performance has already been indicated, doubling the object creation, or the expensive of an attribute access, just to query argument validity. The problem is exacerbated by making a dynamic call to the validation routine even though none is needed.

			On that last remark, there are serious performance implication using shared objects to access a singleton object. All the calls are called on an instance so required the overhead to access the instance, in addition the calls cannot be optimized by the compiler and so are dynamically dispatched - far more expensive on performance than a single static call, which the Eiffel compiler could generate with use of an objectless language addition.

	== A Proposal ==		== A Proposal ==