Difference between revisions of "Talk:Objectless Calls"

Revision as of 21:12, 17 March 2008

Why couldn't the client needing to validate parameters inherit{NONE} from A_VALIDATOR instead of creating an instance?

Also your validation feature doesn't have a postcondition so it's really an incomplete contract. If your validation feature is supposed to ensure something, it needs to state that, otherwise you're just saying, in order to create this object it needs to satisfy this routine which can be overidden and since there's no postcondition, it could be overridden to mean anything including nothing and that's a bug.

Non-polymorphic inheritance shouldn't have a performance hit unless it's not being optimized, by definition they're monomorphic calls so they can be static and inlined.

--Clemahieu 14:43, 14 March 2008 (PDT)

class A_CLIENT
inherit{NONE}
A_VALIDATOR
feature
process (a_value: ?VALUE)
    local
        l_a: A
    do
        if is_valid_value (a_value) then
            create l_a.make (a_value)
            ...
        end
    end

--Peter gummer 04:42, 15 March 2008 (PDT) The redefinition of is_valid_value 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!

--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 do; this is an alternative that you did not propose:

feature -- Access
 
    f: STRING_8
        objectless
        end
 
end

A problem with this is that it precludes the possibility of objectless once functions or objectless externals.

I can think of another possibility: in place of feature. This would be out of step with any other Eiffel keyword; but considering that your whole proposal is out of step with Eiffel's insistence that all calls be targeted to an object, maybe it's appropriate!

objectless -- Access
 
    f: STRING_8
        do
        end
 
end

I think I like this. (In fact, why isn't frozen like this?)

--Ericb 14:01, 16 March 2008 (PDT): Because one can write:

copy, frozen standard_copy (other: like Current)

--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 Current 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 Current 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 do or feature.

--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 TYPE class and related mechanisms may be a worthy substitute: I'm not sure yet.)

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

I'm not on the ECMA committee, but I've always seen static functions as poor design. I still question whether the problems stated are valid. -There is no performance hit from creating A_VALIDATOR because you don't need to create an instance, you can use non-conforming inheritance. -The example strengthens a precondition so any pattern in existing code following type B in this example is questionable. -The "overuse of inheritance" is shown as a problem, I see it as code reuse. I hope the suggestion isn't to make global static functions, more than likely it's suggested to be referenced by a {CLASS}.function in which case you're just using composition rather than inheritance so all inheritance just moves to composition. There shouldn't be a performance hit of dynamic dispatch when using non-conforming inheritance because they're non-polymorphic calls. -There is no double object creation, use non-conforming inheritance, and there should be no dynamic calls to monomorphic non-conforming inheritance features.

• • • • Please tell me if I'm missing why these functions need to by dynamic in non-conforming inheritance!****

Static functions that are part of a class basically are there for namespace reasons since they don't represent operations on an instance of the class; The class name because the namespace of the function, essentially. They don't help create an ADT which is the entire purpose of a pure OO language. --Clemahieu 16:44, 16 March 2008 (PDT)

--Peter gummer 17:54, 16 March 2008 (PDT) To answer Eric's question, "Why not simply call them static routines?": because they are not static routines!

Static routines in C++, C#, Java, etc. cannot be redefined, as I discovered to my dismay when I moved from Delphi to C#. Static routines in those languages are nothing more than class-scoped global routines. Yechh! Evil! What Paul is proposing -- and what I found so useful in Delphi -- are known as class methods in languages that are influenced by Smalltalk. They can be redefined. When assigned to a class reference variable in those languages, they become polymorphic. This is extremely powerful. One thing they were great for in Delphi is in object factories: it took me a long time to figure out why the GoF Design Patterns book was describing in such a long-winded way how to do class factories, until finally I understood that I had been doing them for a long time in Delphi, but with only a line or two of code thanks to the combination of class methods, class references and polymorphic constructors. (Unlike the brain-dead constructors in C++, C# and Java, Delphi constructors can be redefined, just like Eiffel creation routines.)

This is anything but "static"!

I don't know whether objectless routines would fit well within Eiffel, but I would certainly be pleased to see them. It would simplify a lot of code: whole classes would disappear, and ten lines would collapse down to one or two in many cases, especially if the TYPE class turns out to be as useful as class references are in Smalltalk, etc. Bertrand Meyer has written in the past about the dangers of backsliding into procedural code, so maybe there is too much resistance in the Eiffel community. On the other hand, the unwieldiness of the current approach of inheriting SHARED_* classes is probably a deterrent to many prospective Eiffel programmers.

I would recommend studying patterns of usage of class methods in Smalltalk. A bit of googling I've just done also suggests that Ruby might also be worth looking at. But most instructive, perhaps, would be Delphi, which is syntactically closer to Eiffel and is type-safe. (Although Delphi is not, in general, as type-safe as Eiffel, class methods are done in a type-safe manner).

--Ericb 00:59, 17 March 2008 (PDT): In Eiffel, when a feature cannot be redefined, we use frozen, not static. In Eiffel, static is used in opposition to dynamic. For example, dynamic binding vs. static binding. In case of class methods (hmmm, class features I should say!), unless I miss something we would have static binding. I agree that this does not convey the notion of call with no target object, but objectless looks very ugly to me as a keyword.

I'm still waiting for the validity rules to be stated. Here is another example of such rule: an objectless feature cannot be deferred. The same rule applies to frozen features.

--Peter gummer 19:08, 17 March 2008 (PDT) I would want these objectless features to be dynamically bound, Eric. Unless I misread him, I'm sure that's what Paul is asking for too. This would therefore be valid:

feature
 
    frozen i_am_statically_bound
        objectless
        end
 
    i_must_be_defined_in_effected_descendants
        objectless deferred
        end
 
end

Except that I don't like that double-barrelled objectless deferred syntax! Anyway, whatever the syntax, if I remember rightly Delphi allows "abstract class methods", and I see no reason to forbid deferred objectless routines.

Paul's proposed objectless keyword looks ugly to me too, Eric. But I do like the fact that it is explicit about what it is, and I also like that it probably won't conflict with identifiers in existing software. Why does Eiffel always have to invent its own idiosyncratic terminology? Why not just use the keyword that some other languages are already using for this concept: class? It's brief, accurate, won't conflict with identifiers in existing code, and will be instantly understood by thousands of Smalltalk and Delphi programmers. Let's see how it would look:

feature
 
    f: STRING
        class
        end
 
end

Hmmm, looks ok to me. Another possible keyword would be singleton, which apparently is Ruby's keyword for its closest equivalent to Smalltalk class methods.

Another issue: why just routines? Why not deferred objectless attributes? Smalltalk has them, and I think Delphi has them too these days.

You mean global variables? --Clemahieu 23:12, 17 March 2008 (PDT)