[Cuis-dev] A question on same-named methods

[Phil B]

Nicola,

tl;dr version: If you haven't already seen it, I'd suggest watching
https://www.youtube.com/watch?v=jXuoFEkg6UA as it discusses an approach to
dealing with method overrides, adding instvars etc.

On Sat, Aug 14, 2021 at 1:46 PM Nicola Mingotti via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Hi guys,
>
> I have this question for you. I will describe the problem with an example.
>
> I defined a method in my package 'Wunderbar', it is 'readFromString', which
> goes into class 'Json class side' and method category '*Wunderbar-DB'.
>
> Now, suppose a day in the future I upgrade Cuis and 'readFromString'
> is now defined into 'Json class'.
>

While you didn't specifically ask about it, this is a good example of why
you don't want to apply updates to a modified image... behavior is often
undefined.  If you applied updates on top of your loaded code, the updates
would replace your method which usually isn't what you want but you would
not get any warning indicating it happened.  So if you saved your
package after applying updates to a modified image, your version of the
method would disappear and you likely wouldn't discover it until you next
try to rebuild your image.  Or worse, until some point in the future after
that.


> What will happen when i try to load 'Wunderbar' package ?
>

When you load your package, your method will replace the system defined
one.  This is also a good way to have issues if you're not expecting it:
there will often be code elsewhere in the system depending on this new
default behavior which your method may not provide since you wrote your
method before the new one in the core image existed.  This gets back to the
video I recommended at the top of this response... you not only need to
make sure that your code is the last code applied, but also that any
overrides you are doing are to the version of the method you are expecting.
(i.e. you want ensure both your code works as well as any other code in the
image that depended on the old method)

>
> . Do i get an error for method name overlap ?
>

No, there is no overlap.


> . If not, is there any criteria by which one method should be called
> instead of the other
> for example: looking at which method category it belongs to ?
>

The method category (i.e. *<package>) effectively just tells the system
which package 'owns' the method.  However, a given method for a given class
can only exist in one place.  Whoever defined it last wins.


>
> bye
>
> Nicola
>

Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210814/f7e60518/attachment.htm>