[squeak-dev] Overrides in newest Monticellos?

> Is there any new Monticello which deals with overrides right? 1.5?  
> 2.0?
>
> I just published my packages and again incorrectly because some  
> methods
> are overridden in extensions of another package. If you do that in
> current MC, you loose those methods in an original package. Bad!
>
> I'm willing to migrate to such MC immediately if available. I think
> working with overrides is such a powerful feature (not to mention that
> VisualWorks have that) that Squeak needs the proper support as soon as
> possible.

>> I'm willing to migrate to such MC immediately if available. I think
>> working with overrides is such a powerful feature (not to mention that
>> VisualWorks have that) that Squeak needs the proper support as soon as
>> possible.
>
> MC2 doesn't have a concept of overrides as such, but it does allow
> packages to overlap, and uses versioning history to determine which of
> the two versions of a method should be used.
>
> I'm doing the final clean up for the first release, which will be Real
> Soon Now™.

>
> 2008/7/13 Janko Mivšek <[hidden email]>:
>> Dear all,
>>
>> Is there any new Monticello which deals with overrides right? 1.5? 2.0?
>>
>> I just published my packages and again incorrectly because some methods
>> are overridden in extensions of another package. If you do that in
>> current MC, you loose those methods in an original package. Bad!
>>
>> I'm willing to migrate to such MC immediately if available. I think
>> working with overrides is such a powerful feature (not to mention that
>> VisualWorks have that) that Squeak needs the proper support as soon as
>> possible.
>>
>> Best regards
>> Janko
>>
>> --
>> Janko Mivšek
>> AIDA/Web
>> Smalltalk Web Application Server
>> http://www.aidaweb.si
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>

> Philippe Marschall wrote:
>> http://gbracha.blogspot.com/2008/03/monkey-patching.html
>
> I agree with Gilad that extensions and specially overrides (aka monkey
> patching) are dangerous thing to do if you aren't aware of
> consequences, but on the other hand he also concluded that there isn't
> better and established way to solve the problem.
>
> I myself try to follow two rules:
>
> - never override stuff from other,
> - do overrides only of my own stuff, in my control and in my images.
>
> That means that I make overrides only in end packages, for instance
> customer specific ones, which are at the end of chain, not overriden
> with any more package.
>
> That way clashes with others overriding the same stuff are more or
> less avoided while advantages of overrides are preserved.
>
> Janko

> Hi Colin,
>
> Colin Putney wrote:
>
>>> I'm willing to migrate to such MC immediately if available. I think
>>> working with overrides is such a powerful feature (not to mention  
>>> that
>>> VisualWorks have that) that Squeak needs the proper support as  
>>> soon as
>>> possible.
>> MC2 doesn't have a concept of overrides as such, but it does allow  
>> packages to overlap, and uses versioning history to determine which  
>> of the two versions of a method should be used.
>> I'm doing the final clean up for the first release, which will be  
>> Real Soon Now™.
>
> That means if I extend some method in another package and it happens  
> that the method has the same name (this is regarded as override in  
> VW for nistance), MC2 will deal with that situation right and won't  
> change an original package as that this method is removed there?

>
> On 13-Jul-08, at 1:01 PM, Janko Mivšek wrote:
>
>> Hi Colin,
>>
>> Colin Putney wrote:
>>
>>>> I'm willing to migrate to such MC immediately if available. I think
>>>> working with overrides is such a powerful feature (not to mention  
>>>> that
>>>> VisualWorks have that) that Squeak needs the proper support as  
>>>> soon as
>>>> possible.
>>> MC2 doesn't have a concept of overrides as such, but it does allow  
>>> packages to overlap, and uses versioning history to determine  
>>> which of the two versions of a method should be used.
>>> I'm doing the final clean up for the first release, which will be  
>>> Real Soon Now™.
>>
>> That means if I extend some method in another package and it  
>> happens that the method has the same name (this is regarded as  
>> override in VW for nistance), MC2 will deal with that situation  
>> right and won't change an original package as that this method is  
>> removed there?
>
> Right, more or less.
>
> There's really no distinction between "orignal package" and  
> "overriding package." Only one variant of the method can be loaded  
> at a time, but both packages will consider the method to be part of  
> the package.
>
> A common case will be wanting to change a method in another package.  
> Say I have a web app in AIDA/Web, and I want to change on of the  
> base methods. I add the method to my package, and make my change.  
> When I save a snapshot of my web app, it'll include the history of  
> that method, and as long as the base version doesn't change, my  
> version will supersede it. But if you then change the method in AIDA/
> Web, I'll get a conflict when I load my web app, which I'll have to  
> resolve, by choosing your new version, my existing version, or some  
> new version that I write taking both into account.

>>  Personally I cant understand how anyone
>> actually uses squeak for anything serious without it.
>>
>> The best way to load MC1.5 is with LPF see:
>> http://installer.pbwiki.com/LevelPlayingField
>>
>> Keith
>
> How about because some of us consider overrides evil and avoid them like the
> plague, including avoiding using packages that use them when we're aware of
> it.  Extensions are ok, but if I see a package overriding stuff, I just
> don't trust it.

>>  Personally I cant understand how anyone
>> actually uses squeak for anything serious without it.
>>
>> The best way to load MC1.5 is with LPF see:
>> http://installer.pbwiki.com/LevelPlayingField
>>
>> Keith
>>    
>
> How about because some of us consider overrides evil and avoid them like the
> plague, including avoiding using packages that use them when we're aware of
> it.  Extensions are ok, but if I see a package overriding stuff, I just
> don't trust it.
>  

> Ramon Leon wrote:
> >>  Personally I cant understand how anyone
> >> actually uses squeak for anything serious without it.
> >>
> >> The best way to load MC1.5 is with LPF see:
> >> http://installer.pbwiki.com/LevelPlayingField
> >>
> >> Keith
> >>    
> >
> > How about because some of us consider overrides evil and
> avoid them like the
> > plague, including avoiding using packages that use them
> when we're aware of
> > it.  Extensions are ok, but if I see a package overriding
> stuff, I just
> > don't trust it.
> >  
> So the question remains how do you achieve anything?
>
> Keith

> Ramon Leon wrote:
> >>  Personally I cant understand how anyone
> >> actually uses squeak for anything serious without it.
> >>
> >> The best way to load MC1.5 is with LPF see:
> >> http://installer.pbwiki.com/LevelPlayingField
> >>
> >> Keith
> >>    
> >
> > How about because some of us consider overrides evil and avoid them like the
> > plague, including avoiding using packages that use them when we're aware of
> > it.  Extensions are ok, but if I see a package overriding stuff, I just
> > don't trust it.
> >  
> So the question remains how do you achieve anything?
>