I know I've asked something similar before, but can't think / find the answer ...
if I have class foo, with 5 methods, each of which returns this-object:
method public foo m1():
return this-object.
end method.
I now have class bar, which inherits foo and adds another method
method public bar dammit():
return this-object.
end method.
this all compiles fine. except that I can't say this
new bar():m1():dammit()
as m1 returns "foo" as an object, not "bar" , so dammit is not found in foo.
is there anyway around this ?
urgh, apart from new bar():cast(m1(),"bar"):dammit()
It is the sort of question which makes me wonder about the nature of the inheritance hierarchy ... whether or not it can be made to work.
tamhas schrieb:
It is the sort of question which makes me wonder about the nature of the inheritance hierarchy ... whether or not it can be made to work.
And the real class names or some exlanation would help to understand that. foo and bar says nothing, Julian. You must have more than two class names in your phone system application...
is there anyway around this ?
CAST
urgh, apart from new bar():cast(m1(),"bar"):dammit()
Don't put class names in quotes! That creates the illusion of dynamic behavior where it's static.
is there anyway around this ?
CAST
urgh, apart from new bar():cast(m1(),"bar"):dammit()
Don't put class names in quotes! That creates the illusion of dynamic behavior where it's static.
I'm not sure if are you questioning my approach, or progress
inheritance in general
On 28 October 2011 17:53, Thomas Mercer-Hursh
In the absence of any more detail than foo and bar, it is your design I wonder about. Inheritance is abused a lot. There is nothing wrong with ABL inheritance, at least starting with 11.0 where we get interface inheritance.
mikefe wrote:
is there anyway around this ?
CAST
CAST is one approach (and +1 for Mike's don't-use-quoted-type-names comment).
Another is to have a builder object that is passed through the (fluent) chain and which updates the relevant object. Especially if you're only returning this-obejct in order to be able to make a fluent call.
BarBuilder(new Bar())
:m1():dammit().
The dammit() method's on a BarBuilder (which inherits from a FooBuilder, which has m1). So now BarBuilder knows about m1 and dammit, and doesn't care about the type
Returning an interface may not help here either (with inheritance or no) since the type being returned doesn't know what members its children implement. This is true regardless of whether the type is a class or an interface.
-- peter
Idea #1 (clunky, but it'll work):
method public foo m1():
super().
return this-object.
end method.
Idea #2:
1) make the current super-class an abstract class w/protected methods that do everything except return the current object
2) give those methods a different name (m1a instead of m1),
3) then implement the class-specific methods for each class.
method public m1 ():
m1a().
return this-object.
end method.
method 1 won't work because you can't override a method with a
different return value.
method 2 would mean defining all the methods that exist in the base
abstract class , so you then might as well simply new() the base class
(i.e. don't do inheritance)
All of which contrivance only adds to the suspicion ... even if it does work.