Avi wrote:
> On Fri, 6 Dec 2002, Stephen Pair wrote:
> 
> > >  - IVAP modifies Parser and Compiler; to mirror Daniel 
> and Andreas' 
> > > argument, why not use #compilerClass and a subclass?
> >
> > Because I felt that there is no reason to have a separate 
> parser and 
> > compiler to support this small feature.  Subclasses should 
> do bigger 
> > things than this (IMO) and I can't see why the standard 
> > parser/compiler shouldn't support it.
> 
> To me it's more a modularity issue - if these changes are 
> adopted as part of the base compiler, great.  Otherwise, they 
> shouldn't be modifying Parser's methods if they can easily 
> avoid doing so; it'll just cause maintenance problems down 
> the road.  We can disagree on this, but I'm not going to have 
> Seaside depend on modifications to system methods unless I 
> absolutely have to.

Well, I'm torn between subclassing and changing the existing stuff.  The
Parser/Compiler code is a bit messy as it is, so even if it were done as
a subclass, the chances of future changes to Parser/Compiler *not*
having any impact on its subclasses is very slim.  So in terms of
maintenance, I don't see there being much difference either way.  One
thing I did do is have the SAR installation run a sanity Sunit test upon
loading...if something is broken, it'll be immediately apparent
(especially if you've got a nightly build job that always builds
everything up from a base image).

But, if you require it as a subclass before you'll consider using in
Seaside, then I'll make that change...better to have one solution to
this problem than two; having two different solutions is definitely a
maintenance issue.

- Stephen

P.S.  In general I tend not to subclass based solely on a maintenance
concern.  I prefer instead to subclass only when it makes sense for the
problem domain.  In my experience, the decision to subclass or not has
much less of an impact on maintenance than people tend to think.  And,
with the wonderful tools were getting now (DVS, Monticello, SqueakMap,
etc), maintenance is becoming a lot easier.

P.P.S.  What about putting this into the base Squeak (or rather the
compiler package)?  Guides?