Talk:Objectless Calls - Revision history

Paulb: Added comment.

2008-10-01T22:58:54Z

Added comment.

Peter gummer at 07:34, 19 March 2008

2008-03-19T07:34:25Z

Clemahieu at 01:25, 19 March 2008

2008-03-19T01:25:27Z

Peter gummer at 23:38, 18 March 2008

2008-03-18T23:38:51Z

Peter gummer at 22:24, 18 March 2008

2008-03-18T22:24:57Z

Peter gummer at 22:24, 18 March 2008

2008-03-18T22:24:11Z

Peter gummer at 21:59, 18 March 2008

2008-03-18T21:59:53Z

Peter gummer at 21:45, 18 March 2008

2008-03-18T21:45:13Z

Paulb at 15:50, 18 March 2008

2008-03-18T15:50:02Z

Paulb at 15:41, 18 March 2008

2008-03-18T15:41:03Z

← Older revision		Revision as of 22:58, 1 October 2008
Line 185:		Line 185:

	:--[[User:Peter gummer\|Peter gummer]] 00:34, 19 March 2008 (PDT) Paul mentions the word "optimize" twice in the article: it's only a potential bonus of his proposal, not the principal motivation. And his proposal isn't for "static methods" (although it does provide a mechanism for them: a frozen objectless routine would be equivalent to a "static method", I suppose). Your "implicit class" idea is interesting, but it's not clear to me how it addresses the concerns that Paul raised.		:--[[User:Peter gummer\|Peter gummer]] 00:34, 19 March 2008 (PDT) Paul mentions the word "optimize" twice in the article: it's only a potential bonus of his proposal, not the principal motivation. And his proposal isn't for "static methods" (although it does provide a mechanism for them: a frozen objectless routine would be equivalent to a "static method", I suppose). Your "implicit class" idea is interesting, but it's not clear to me how it addresses the concerns that Paul raised.
		+
		+	:-----[[User:Paulb\|paulb]] 15:58, 1 October 2008 (PDT)
		+	Actually any call made using the Eiffel static calling convention would be performed statically instead of dynamic dispatch. In that case objectless calls need not be marked <e>frozen</e> in order to benefit from performance gains. And, although performance is not the generalized issue here, I would like objectless calls to be implemented for performance reasons also. There is a dramatic increase in performance when using static calls as apposed to dynamic dispatch.

@@ Line 159: / Line 159: @@
 ----
+--[[User:Clemahieu|Clemahieu]]
 I think a generic definition of the problem case, where people like to use static functions, is a situation like one I ran in to.  I wanted a way to convert an integer to an array of bytes to send over a network.<br/><br/>Most people would say, create a static function int_to_bytes(i: INTEGER): ARRAY[NATURAL_8].  The English phrasing of this: you're applying a function INTEGER -> ARRAY[NATURAL_8] to your variable `i'. This could be put in a new class INT_UTILITY and statically accessed or inherited from.<br/><br/> A more correct and object oriented way would be to edit the INTEGER class and add this feature in.  The English phrasing of this: you are asking this instance of INTEGER to convert itself to ARRAY[NATURAL_8].<br/><br/>Two issues can arise with this, if this is a pre-existing library you need to edit a class that is supposed to be consumed unmodified.  The other issue is the number of permutation of this in infinite.  There are an infinite number of ways to manipulate INTEGER and most are problem domain specific, so if in fact you could add this to the INTEGER class, there would be an unlimited number of additions to this class which is not feasible.<br/><br/>Evidently a solution to this was brought up at ECMA before, as I discovered when I posted http://dev.eiffel.com/Implicit_class  What we're looking to do is add features to an existing class without modifying the class.  A statically-checkable downcast would allow you to use a new feature on an existing class in an object oriented way new.f instead of a functional way new(f).<br/><br/>  I like the solution of an implicit class, or whatever it could be called, for a couple other reasons.  It cleans up the renaming definition of multiple generic constraints and would allow multiple actual generic parameters like LIST[{COMPARABLE, HASHABLE}].  Wasn't it Bertrand that said the most elegant solutions solve multiple problems?<br/><br/>As for the original rationale of a performance issue.  If you allow redefinition with the same power Eiffel allows in other places, we'd run in to issues of dynamic calls.<br/><br/>We English speakers also have an issue of differentiating between one and anything more than one.  We want *the* number PI, not an instance of REAL that is close to 3.14159265.  We want to #define this so we are sure that *the* version of it is used everywhere.  This is a misnomer because ever though we call it static and think there is only one version, it's still one version within the domain of the executing process.  If we start another instance of the program, it's no longer the only copy.  Information hiding and creating abstract data types is the primary purpose of moving to OO languages.  Attaching semantics to the class as opposed to an instance of a class, an object, makes it one instance of something accessible to everything instead of operating on a specific instance of something.<br/><br/>The issue of the singleton object like PI is actually a compiler optimization issue.  We could optimize all (create {NATURAL}.make(3.141592)) to be one object, created at compile time and put in to the image of the executable, but our compiler writers are too busy writing implementation of new language specifications to do this!  We should be able to write:
 <e>
@@ Line 183: / Line 183: @@
 </e>
 This could be optimized at compile time instead of making a manifest array construct in the language definition, but I digress.<br/><br/>Creating new language features to solve specific optimization problems isn't always a good idea, that's what caused the C preprocessor.  I see a need for adding features to a class without modifying the class and I see it should be done differently than static methods.

← Older revision		Revision as of 01:25, 19 March 2008
Line 157:		Line 157:

	:--[[User:Peter gummer\|Peter gummer]] 15:24, 18 March 2008 (PDT) I wouldn't want '''deferred objectless attributes''', because of the possible type hole that I mentioned above. But why not '''objectless attributes'''? These are not global variables, although they would be very close to them when called statically, as in <e>{A}.f</e>. Even then they differ from global variables in two respects: they are scoped within class A (like static variables in C#, Java, etc.); and they are read-only except within descendants of class A (thanks to Eiffel's normal rules of encapsulation). When called dynamically, as in <e>a.f</e>, they acquire a new power due to Eiffel's redefinition mechanisms.		:--[[User:Peter gummer\|Peter gummer]] 15:24, 18 March 2008 (PDT) I wouldn't want '''deferred objectless attributes''', because of the possible type hole that I mentioned above. But why not '''objectless attributes'''? These are not global variables, although they would be very close to them when called statically, as in <e>{A}.f</e>. Even then they differ from global variables in two respects: they are scoped within class A (like static variables in C#, Java, etc.); and they are read-only except within descendants of class A (thanks to Eiffel's normal rules of encapsulation). When called dynamically, as in <e>a.f</e>, they acquire a new power due to Eiffel's redefinition mechanisms.
		+
		+	----
		+
		+	I think a generic definition of the problem case, where people like to use static functions, is a situation like one I ran in to. I wanted a way to convert an integer to an array of bytes to send over a network.<br/><br/>Most people would say, create a static function int_to_bytes(i: INTEGER): ARRAY[NATURAL_8]. The English phrasing of this: you're applying a function INTEGER -> ARRAY[NATURAL_8] to your variable `i'. This could be put in a new class INT_UTILITY and statically accessed or inherited from.<br/><br/> A more correct and object oriented way would be to edit the INTEGER class and add this feature in. The English phrasing of this: you are asking this instance of INTEGER to convert itself to ARRAY[NATURAL_8].<br/><br/>Two issues can arise with this, if this is a pre-existing library you need to edit a class that is supposed to be consumed unmodified. The other issue is the number of permutation of this in infinite. There are an infinite number of ways to manipulate INTEGER and most are problem domain specific, so if in fact you could add this to the INTEGER class, there would be an unlimited number of additions to this class which is not feasible.<br/><br/>Evidently a solution to this was brought up at ECMA before, as I discovered when I posted http://dev.eiffel.com/Implicit_class What we're looking to do is add features to an existing class without modifying the class. A statically-checkable downcast would allow you to use a new feature on an existing class in an object oriented way new.f instead of a functional way new(f).<br/><br/> I like the solution of an implicit class, or whatever it could be called, for a couple other reasons. It cleans up the renaming definition of multiple generic constraints and would allow multiple actual generic parameters like LIST[{COMPARABLE, HASHABLE}]. Wasn't it Bertrand that said the most elegant solutions solve multiple problems?<br/><br/>As for the original rationale of a performance issue. If you allow redefinition with the same power Eiffel allows in other places, we'd run in to issues of dynamic calls.<br/><br/>We English speakers also have an issue of differentiating between one and anything more than one. We want the number PI, not an instance of REAL that is close to 3.14159265. We want to #define this so we are sure that the version of it is used everywhere. This is a misnomer because ever though we call it static and think there is only one version, it's still one version within the domain of the executing process. If we start another instance of the program, it's no longer the only copy. Information hiding and creating abstract data types is the primary purpose of moving to OO languages. Attaching semantics to the class as opposed to an instance of a class, an object, makes it one instance of something accessible to everything instead of operating on a specific instance of something.<br/><br/>The issue of the singleton object like PI is actually a compiler optimization issue. We could optimize all (create {NATURAL}.make(3.141592)) to be one object, created at compile time and put in to the image of the executable, but our compiler writers are too busy writing implementation of new language specifications to do this! We should be able to write:
		+	<e>
		+	class PI
		+	inherit
		+	REAL
		+	create
		+	default_create
		+	feature
		+	default_create is
		+	do
		+	make(3.14159265)
		+	end
		+	</e> The compiler should be able to see that only one version of this is ever creatable, create it at compile time and put it in to the executable image as an optimization. This optimization could be applied to any object that's created from basic types in the language, integers, strings. In fact arrays could have been done this way instead of manifest arrays.<br/>
		+	<e>
		+	local
		+	list: ARRAY[INTEGER]
		+	do
		+	create list.make(1, 2)
		+	list[1] := 8
		+	list[2] := 73
		+	end
		+	</e>
		+	This could be optimized at compile time instead of making a manifest array construct in the language definition, but I digress.<br/><br/>Creating new language features to solve specific optimization problems isn't always a good idea, that's what caused the C preprocessor. I see a need for adding features to a class without modifying the class and I see it should be done differently than static methods.

← Older revision		Revision as of 23:38, 18 March 2008
Line 65:		Line 65:

	::[[User:Paulb\|Paulb]] 08:50, 18 March 2008 (PDT) What about if I wanted an objectless once, deferred and even though it is redundant because it's implicit, an external?		::[[User:Paulb\|Paulb]] 08:50, 18 March 2008 (PDT) What about if I wanted an objectless once, deferred and even though it is redundant because it's implicit, an external?
		+
		+	:::--[[User:Peter gummer\|Peter gummer]] 16:38, 18 March 2008 (PDT) Yes, I suppose '''objectless once''' would be useful; and people would definitely want '''objectless external'''; and although '''objectless deferred''' may be dangerous, as mentioned below, the syntax should not preclude its possibility in the future. I think that your '''objectless do''' syntax proposal may be the best, although we would might format it with '''objectless''' on its own line (like <e>obsolete</e>) or even on the same line as the feature names (like <e>assign</e>). Maybe it would fit into the grammar somewhere near <e>obsolete</e>, before the header comment. Then it would probably work for objectless attributes too.

	----		----

← Older revision		Revision as of 22:24, 18 March 2008
Line 154:		Line 154:
	--[[User:Clemahieu\|Clemahieu]] 23:12, 17 March 2008 (PDT)		--[[User:Clemahieu\|Clemahieu]] 23:12, 17 March 2008 (PDT)

−	:--[[User:Peter gummer\|Peter gummer]] 15:24, 18 March 2008 (PDT) I wouldn't want ''deferred objectless attributes''', because of the possible type hole that I mentioned above. But why not ''objectless attributes'''? These are not global variables, although they would be very close to them when called statically, as in <e>{A}.f</e>. Even then they differ from global variables in two respects: they are scoped within class A (like static variables in C#, Java, etc.); and they are read-only except within descendants of class A (thanks to Eiffel's normal rules of encapsulation). When called dynamically, as in <e>a.f</e>, they acquire a new power due to Eiffel's redefinition mechanisms.	+	:--[[User:Peter gummer\|Peter gummer]] 15:24, 18 March 2008 (PDT) I wouldn't want '''deferred objectless attributes''', because of the possible type hole that I mentioned above. But why not '''objectless attributes'''? These are not global variables, although they would be very close to them when called statically, as in <e>{A}.f</e>. Even then they differ from global variables in two respects: they are scoped within class A (like static variables in C#, Java, etc.); and they are read-only except within descendants of class A (thanks to Eiffel's normal rules of encapsulation). When called dynamically, as in <e>a.f</e>, they acquire a new power due to Eiffel's redefinition mechanisms.

@@ Line 148: / Line 148: @@
 ::What I'm most interested in, however, is in being allowed to call <e>c.f</e>, where <e>c</e> is attached to an object conforming to <e>TYPE [A]</e>. The question arises, then, of what would happen if <e>c</e> were attached to an object of type <e>TYPE [A]</e>, where <e>f</e> is deferred in class A? The answer isn't nice: calling <e>c.f</e> would produce a ''run-time error''. Ok, I bet I'm scaring people now: I'm poking another little hole into the Eiffel type system which you guys have been working so hard for a decade or more to construct on more solid foundations. But having seen the power of this facility in Delphi, I'd love to have it in Eiffel.
-::Maybe the best thing to do would be '''forbid deferred objectless features'''. This would avoid the need for the compiler to detect the trivial validity error in <e>{A}.f</e>; it would prevent the nasty type hole in <e>c.f</e>; and it would save us all the effort of trying to figure out what the best syntax for declaring a feature '''objectless deferred''' might be. At some future date, someone might discover that objectless deferred features can be added without jeopardising the integrity of the type system; in the meantime, I believe it's best to forbid them.
+::Maybe the best thing to do would be '''forbid deferred objectless features'''. This would avoid the need for the compiler to detect the trivial validity error in <e>{A}.f</e>; it would prevent the nasty type hole in <e>c.f</e>; and it would save us all the effort of trying to figure out what might be the best syntax for declaring a feature '''objectless deferred'''. At some future date, someone might discover that objectless deferred features can be added without jeopardising the integrity of the type system; in the meantime, I believe it's best to forbid them.
 ----
 You mean global variables?
 --[[User:Clemahieu|Clemahieu]] 23:12, 17 March 2008 (PDT)

@@ Line 142: / Line 142: @@
 ::--[[User:Peter gummer|Peter gummer]] 14:45, 18 March 2008 (PDT)
-::I imagine that <e>{A}.f</e> would be an invalid call if <e>f</e> is deferred in class A. Because <e>{A}.f</e> is a statically bound, the compiler can report this as an error.
+::I imagine that, if <e>f</e> is deferred in class A, then <e>{A}.f</e> would be an invalid call. Because <e>{A}.f</e> is statically bound, the ''compiler'' can report this error. That's the trivial case.
-::
-::That's the trivial case. The case of calling <e>a.f</e> where <e>a</e> is attached to an object descending from A is also clear.
+::The case of calling <e>a.f</e> where <e>a</e> is attached to an object descending from A is dynamically bound. Because <e>a</e> cannot, by Eiffel's existing validity rules, be attached to a deferred type, this case is type-safe and the semantics are clear.
-::
-::What I'm most interested in, however, is in being allowed to call <e>c.f</e>, where <e>c</e> is attached to an object conforming to <e>TYPE [A]</e>. If <e>f</e> is deferred in class A, then calling <e>c.f</e> would produce a run-time error if <e>c</e> were attached to an object of type <e>TYPE [A]</e>. Ok, I bet I'm scaring people now: I'm poking another little hole into the Eiffel type system which you guys have been working so hard for a decade or more to construct on more solid foundations. But having seen the power of this facility in Delphi, I'd love to have it in Eiffel.
+::What I'm most interested in, however, is in being allowed to call <e>c.f</e>, where <e>c</e> is attached to an object conforming to <e>TYPE [A]</e>. The question arises, then, of what would happen if <e>c</e> were attached to an object of type <e>TYPE [A]</e>, where <e>f</e> is deferred in class A? The answer isn't nice: calling <e>c.f</e> would produce a ''run-time error''. Ok, I bet I'm scaring people now: I'm poking another little hole into the Eiffel type system which you guys have been working so hard for a decade or more to construct on more solid foundations. But having seen the power of this facility in Delphi, I'd love to have it in Eiffel.
-::
-::Maybe the best thing to do would be '''forbid deferred objectless features'''. This would avoid the need for the compiler to detect the trivial validity error in <e>{A}.f</e>; it would prevent the nasty type hole in <e>c.f</e>; it it would save us all the effort of trying to figure out what the best syntax for declaring a feature '''objectless deferred''' might be.
+::Maybe the best thing to do would be '''forbid deferred objectless features'''. This would avoid the need for the compiler to detect the trivial validity error in <e>{A}.f</e>; it would prevent the nasty type hole in <e>c.f</e>; and it would save us all the effort of trying to figure out what the best syntax for declaring a feature '''objectless deferred''' might be. At some future date, someone might discover that objectless deferred features can be added without jeopardising the integrity of the type system; in the meantime, I believe it's best to forbid them.
 ----
 You mean global variables?
 --[[User:Clemahieu|Clemahieu]] 23:12, 17 March 2008 (PDT)

@@ Line 29: / Line 29: @@
 ----
 --[[User:Peter gummer|Peter gummer]] 04:42, 15 March 2008 (PDT) The redefinition of <e>is_valid_value</e> is strengthening the precondition. This is contrary to Design by Contract. I think you have a valid point, Paul, but you need to come up with a decent example!
 --[[User:Peter gummer|Peter gummer]] 05:19, 15 March 2008 (PDT) I don't like your preferred placement of the '''objectless''' keyword, Paul, in front of the feature name. I think I would prefer it in the place of the <e>do</e>; this is an alternative that you did not propose:
@@ Line 61: / Line 63: @@
 ::--[[User:Peter gummer|Peter gummer]] 17:54, 16 March 2008 (PDT) Ha, good point, Eric! That is useful. So Paul's preferred notation would be advantageous only if someone can see any useful reason to have two synonyms for a routine, one object-oriented and the other class-oriented. Sounds like a very bad idea to me, because <e>Current</e> would be meaningless in an objectless routine (unless Eiffel specified that it be a reference to the enclosing class, as Delphi and Smalltalk do for '''self''' in ''class methods''; but Eiffel does not have class reference variables, so this won't work in Eiffel; and it would be a pretty stupid idea anyway, for the meaning of <e>Current</e> to change like that within the same routine). Methinks this would be a defect, then, in Paul's preferred notation! This leaves two possible places for the proposed '''objectless''' keyword: to replace or qualify either <e>do</e> or <e>feature</e>.
 ----
 --[[User:Peter gummer|Peter gummer]] 05:33, 15 March 2008 (PDT) Paul, you wrote, "Unlike other languages, it should be possible to redefine any objectless routine." Uh, ''which'' other languages? Well ok, I know exactly which languages you are thinking of: C#, etc. I just want to point out that there are other languages out there that ''do'' allow redefinition of objectless routines. The obvious one is the big grandma of OO languages, Smalltalk, where polymorphic class methods are common (or so I believe, never having programmed in Smalltalk myself). Another is Delphi, which I programmed in for about 6 years, and polymorphic class methods are the biggest thing that I miss from the Delphi language. They are incredibly powerful when used in combination with class reference variables (which is something else that Eiffel lacks, although the new <e>TYPE</e> class and related mechanisms may be a worthy substitute: I'm not sure yet.)
 ----
 --[[User:Ericb|Ericb]] 14:14, 16 March 2008 (PDT): Paul, you said that this was overlooked when defining the ECMA standard. I attended the ECMA meetings and I don't share your opinion. The fact that it is not in the current version of the ECMA standard does not mean that it has been overlooked. That being said, I'm glad you wrote this wiki page so that the topic can be brought back again at ECMA. However there is something that is desperately missing in your proposal: where are the validity rules? There is only one which states that we can redefine an objectless routine (BTW, why not simply call them static routines?) to a non-objectless routine. Personally I think that it should be the reverse, but it's hard to be sure since you don't put down the other validity routines. For example, what should be the conditions that a routine should satisfy in order to be valid to declare it as objectless? My first impression is that it should not use 'Current' nor call non-objectless features, to the very least.
 ----

@@ Line 7: / Line 7: @@
 --[[User:Clemahieu|Clemahieu]] 14:43, 14 March 2008 (PDT)
-::[[User:Paulb|Paulb]] 08:40, 18 March 2008 (PDT) Yes, the client class could inherit A_VALIDATOR but I used the model to indicate a latter point.
+:[[User:Paulb|Paulb]] 08:40, 18 March 2008 (PDT) Yes, the client class could inherit A_VALIDATOR but I used the model to indicate a latter point.
-In regards to the postconditions, this we me trying to be quick. We are polishing our release off and we are all busy. I just wanted to get something going in the domain of objectless calls.
+:In regards to the postconditions, this we me trying to be quick. We are polishing our release off and we are all busy. I just wanted to get something going in the domain of objectless calls.
 <e>