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

[Nicola Mingotti]

Thank you Phil,

the video is instructive. I will try to put a summary in the CookBook
as soon as possible.

bye
Nicola




On 8/14/21 8:18 PM, Phil B wrote:
> Nicola,
>
> tl;dr version: If you haven't already seen it, I'd suggest watching 
> https://www.youtube.com/watch?v=jXuoFEkg6UA 
> <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 <mailto: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/20210815/487f4e73/attachment.htm>