hi andreas

You are right, I guess.

in Store, Envy or parcel where packages are really entities you can 
have a method belonging
to different packages in the database. Then when you load the code only 
one method (usually the last installed) will take precedence over the 
other ones. In classBoxes you have multiple methods even after load as 
classbox works as namespace.

in fact in Store a class has a home package: where it is defined (you 
can have multiple one in the database) but
normally you have only one in memory (even if parcel allows you to do 
that: we go really strange bug playing with that because Store was 
losing the fact that we were redefining class definition (bad bad idea 
but we needed it). I guess that sotre was losing that because parcel 
allows it but not store so we were at the limit of the model. Then a 
class knows a list of package that extends it ie define a method into 
the class.

Normally even with Store or Envy (may be I'm wrong because I forgot,
and with parcel a lot is possible),  while browsing simply the code you 
cannot see two definitions of the same methods.
The load order is then important and the last one wins. Still this 
would be good to have real packages.

Stef


On Lundi, oct 13, 2003, at 20:10 Europe/Zurich, Andreas Raab wrote:

> Hi Guys,
>
>> Yes, I was proposing that we prevent overrides at load time,
>> but perhaps that's being too restrictive.  But how else would
>> you prevent a method from being in two packages if you allow
>> overrides?
>
> Check me on this - if I understand PackageInfo correctly then it 
> determines
> which package a method belongs to by looking at the category. Since a 
> method
> can only be in one category at any given time it is impossible to have 
> it in
> two packages (if we use PI that is). So if you modify a method you've 
> got
> two choices - either leave it in the one it was in or move it into one 
> of
> yours.
>
> In case a) you essentially "patch" the method inplace and it still 
> belongs
> to where it was originally. In case b) you take ownership of it. I 
> won't
> comment on how useful either one is but it seems to me that we really 
> can't
> have methods in multiple packages.
>
> Cheers,
>   - Andreas
>
>
>