<div dir="ltr"><div>This is pretty much my beef with OOP (however, I do see its benefits and Gambas is great language!). More you rely on OOP features (in contrast to example features of procedural languages), more you make your code invisibly language specific. There doesn't seem to be proper common OO language standards and the "rules" are not intuitive nor derivable. IE it is not clear what superficially the semantically same code does in two different OO languages.<br></div><div><br></div><div>Thus I would suggest not to add features that lack de facto standards, unless they are really powerful and widely useful.<br></div><div><br></div><div><br></div>Jussi<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 14, 2019 at 1:41 PM Tobias Boege <<a href="mailto:taboege@gmail.com">taboege@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 11 Jun 2019, Yeshua Rodas wrote:<br>
> Thank you. All is more clear for me now.<br>
> <br>
> However, I'm facing an issue that I'm not sure how to handle it.<br>
> <br>
> I have a basic class with a method:<br>
> <br>
> Public Function doSomething(param as SomeBaseClass) as String<br>
>   ' Some stuff<br>
> End<br>
> <br>
> <br>
> And a derivated class that I need to call some specialized method<br>
> <br>
> Public Function doSomething(param as SomeDerivatedClass) as String<br>
>   ' Some stuff<br>
>   param.childMethod()<br>
>   ' More stuff<br>
> End<br>
> <br>
> <br>
> But this rise "Symbol is badly overridden" error.<br>
> I think that on overriding would be useful to override the type for an<br>
> inherited type. The actual constraint model is squeezing my brain.<br>
> <br>
<br>
Allowing that seems sensible to me. You'll have to get Benoît's attention<br>
to have it implemented though.<br>
<br>
But note that Gambas does not have polymorphic methods, so with the above<br>
you will essentially forbid someone to use the derived class's doSomething<br>
like they could with the parent class, because the signature is irrevocably<br>
more constrained. To me, this seems like a violation of Liskov's substitution<br>
principle, which you may care about or not.<br>
<br>
Also note that you can put an object of type B into a variable typed A<br>
*and get it out again* into a variable typed B, provided that the actual<br>
type of the object is B and B inherits A. An object does not lose its<br>
"true type" by being placed in a typed variable. A variable's type acts<br>
mostly like a method lookup table for the contained object, which you<br>
can switch out as long as they are compatible via inheritance.<br>
<br>
  Public Function doSomething(param As SomeBaseClass) As String<br>
    Dim der As SomeDerivatedClass = param<br>
    der.childMethod()<br>
  End<br>
<br>
in SomeDerivatedClass will work right now without raising the<br>
"badly overridden" error. Put in a Try and a call to Super.doSomething<br>
and you have manually constructed a method that is polymorphic along<br>
class lineage. The other solution that works right now would be to name<br>
the new method differently.<br>
<br>
Regards,<br>
Tobi<br>
<br>
-- <br>
"There's an old saying: Don't change anything... ever!" -- Mr. Monk<br>
<br>
----[ Gambas mailing-list is hosted by <a href="https://www.hostsharing.net" rel="noreferrer" target="_blank">https://www.hostsharing.net</a> ]----<br>
</blockquote></div>