Talk:Objectless Calls

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