New source pointers: does anyone know what is happening in ClassDescription>fileOutChangedMessages:on:moveSource:toFile: ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

New source pointers: does anyone know what is happening in ClassDescription>fileOutChangedMessages:on:moveSource:toFile: ?

timrowledge
I see a very puzzling method.  The class organisations name is  
checked to see if it starts with '*' and ends with '-override'. Does  
anyone know why?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Sic faciunt omnes. = Everyone is doing it.



Reply | Threaded
Open this post in threaded view
|

Re: New source pointers: does anyone know what is happening in ClassDescription>fileOutChangedMessages:on:moveSource:toFile: ?

brad fowlow

That looks like Monticello trickery.

A package can modify methods in classes that are owned by other  
packages.
(An application package can override something in a core class,
without taking on ownership of the full core class.)

When you unload the package that has the override method, the  
original is restored.
So there's probably funny business afoot to keep the original  
recoverable.

-brad

> I see a very puzzling method.  The class organisations name is  
> checked to see if it starts with '*' and ends with '-override'.  
> Does anyone know why?
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Sic faciunt omnes. = Everyone is doing it.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: New source pointers: does anyone know what is happening in ClassDescription>fileOutChangedMessages:on:moveSource:toFile: ?

Bert Freudenberg
In reply to this post by timrowledge
Am 05.11.2006 um 06:59 schrieb tim Rowledge:

> I see a very puzzling method.  The class organisations name is  
> checked to see if it starts with '*' and ends with '-override'.  
> Does anyone know why?

Hah! It only assures correct working of the even more puzzling  
PackageInfo>>changeRecordForOverriddenMethod: method after condensing ;)

See

        http://bugs.impara.de/view.php?id=2514

The proper test would be using PackageInfo>>isOverrideMethod:, but  
that would introduce a cross-package dependency. Also, it should only  
preserve the most recent versions of each overriding package, but I  
couldn't be bothered to implement this, so I simply retain all the  
history.

Anyway, if you dabble in that are, a comment might be in order ...

- Bert -