On Thu, 21 Jun 2001, Michael Rueger wrote:

> Stephane Ducasse wrote:
> > 
> > Thanks for exactness
> > 
> > I did not check this one! But My intention was to show the impact of been
> > free to extend class (which I like) in a uncontrolled manner.
> > 
> > > While I too like classes that are small enough to understand,
> > > this specific claim is untrue.  String>>asHtml uses only Collection
> > > methods.  The HtmlEntities table it refers to lives in String.
> 
> Which you still did. If your application does not use HTML, what do you
> need a HTMLEntities table in String for.

Well there's a difference in having a method that couples two classes (or
a class and a small group of classes) together and having methods
that one may not use, plus a small amount of associated data, in a class.

The table is around 100 entries of short strings to characters. I'm not
bugged by that bloat ;)

Yes...I know...it's not any *one* chunk of fat, it's that once you've
tasted *one* the urge for more and more is strong and then everybody's
doing it anyway and what's one more and you end up with a huge mound of
uncontrolled blubber melting all over the place!!!

So there is an impact of #asHtml, but it's not *that* big. The main
problem with it, as far as I can tell offhand, is that it's not a very
good method :) Kind of awkwardly named, not very often used, doesn't solve
or easily point the way to solving, the general issue of entities and
encodings...

But lets take another example of a String>>asFoo method (after all, String
is vulnerable this way, there being a lot of String representations of
various sorts of objects so it's natural to pop an #asFoo method into
String to make converstion convenient): String>>asUrl.

Now *this* method couples String to some other classes (the Url hierarchy,
in fact). I tend to use it since I've found it a bit easier to use than
Url absoluteFromText: 'http://www.foo.com/'. Ok that's not the happiest
selector, but even Url readFrom: 'http://www.foo.com/' doesn't seem so
great. Hard to say. I could get used it, I suppose.

Perhaps a better way would be to have a generic readTable that classes
could register with when they have string parsing/writing methods. 

ANYway, my point is that there are a lot of things to trade off. One thing
I'd generally *not* like to trade off is the richness of the
environment. I'll take a bit of bloat for that. (And of course, bloat can
stifle fecundity, so dealing with it sensibly is necessary)

Cheers,
Bijan Parsia.