Good interfaces gone bad

Bijan Parsia bparsia at
Fri Jun 22 20:04:04 UTC 2001

On Fri, 22 Jun 2001, Noel J. Bergman wrote:

> > it's natural to pop an #asFoo method into String to make converstion
> convenient
> If String>>as<X> was taken any further than it is (and ideally a few of them
> should be moved), it would be a good example of a bad implementation
> pattern.  It increases the surface area of String, coupling it to more and
> more classes.

Is this an implementation problem or a design problem? 

> Instead, X>>fromString: would serve the exact same purpose,

Well I did mention this pattern and pointed out that it sometimes feels

> semantically
> represent the encapsulated behavior in the proper place, and leave the
> surface area of String at a minimum.

Yes, well, I suspect that this argument could be carried further. Why make
each X know how to parse string representations? It certainly leads to
problems with printing (set the various formatting and PrintPolicy

> For example, could one seriously suggest that "Color fromString: '#FFCCAA'"
> is unclear or inconvenient compared to '#FFCCAA' asColor",

Yes, though I wouldn't argue this one.

> or that it would
> be worth polluting the String interface for the perceived convenience, were
> someone so inclined?

Sure. If the former than the latter. "Polluting" is just a noise word
there, the burden of proof is on you to show the larger costs of such

And frankly, perceived convenience is often as important as
"real" convenience. If it makes me inclined to use something and use it
correctly and that leads to better overall code with fewer errors, then
perceived convenience is extraordinarily valuable.

> Don't focus too much on String.  String is just an example, inspired by the
> "it's natural" comment above, but the point is that it should not be a
> responsibility of String to convert itself to/from the myriad of other
> objects.

Why not? You've not given an argument for that and a lot of systems go the
other way.

While natural, I'm not saying it's always *right* to pop in an asFoo
method. The reason it's natural is that is seems to work well for some
cases (example that drives me nuts: people seem to want 'c:\foo'
asFilename. or 'foo.txt' readStream. (like visualworks), I find this
crazy...yet I like '' asUrl. Go figure!

I suspect it's because I use asUrl in workspaces. e.g.,
	'http:\\' asUrl retrieveContents content inspect.
The alternative (even with the easier #readString:) is not as useful,
	Url fromString: 'http:\\' "oh damn, have to put parens
	(Url fromString: 'http:\\') retrieveContents content

It's not just having to type a few extra characters, it's changing the
entire syntax of the expression, that's burdensome in this case.

Of course, if we had a canonical Url literal, it wouldn't be an issue:

	#<http:\\> retrieveContents content inspect
works for me. But surely that's not a general solution (polluting the
language with more and more literals! ;)))

>  And if something isn't an object's responsibility, it shouldn't be
> in the interface.

Hmm. Out of a comp.lang.lisp thread of #allInstances, I gleaned or
imagined the following distincting: system functions/methods and
"tool" ones. System one's are the kind of thing you'd want in a standard
and to be able to use portably, etc. Tool ones tend to be vendor dependent
and use more *ad hocly*. I think it's important to keep in mind that the
objects in a squeak system get manipulated from a number of different
perspectives, including direct manipulation, munging from inspectors,
etc. yet use the same mechanisms (mostly) (i.e., messages and
methods). There's bound to be some clashes ;)
> And when did we get away from the notion of responsibility, anyway?


If we get back to the original point, #asHtml introduces no coupling. All
it's bits are inside String. It still may be nasty in several ways, but
it's clearly a good example of large scale design grunginess. (And it's
not even clear that #asHtml *doesn't* belong in string, as the system now
stands, as several sorts of encoding are already handled by it.

Bijan Parsia.

More information about the Squeak-dev mailing list