[Squeakfoundation]RE: Your stewardship(s)

Andreas Raab andreas.raab at gmx.de
Mon Mar 10 10:12:51 CET 2003


> > With SM, we need a more declarative style that tells both, 
> > clients and framework developers which methods can be relied
> > upon and which can't.
> > Without this, maintaining a package simply becomes a nightmare.
> Are you sure? I mean, don't you think a little bit of 
> documentation on a package might suffice? So that it is
> obvious what classes/messages are meant to be used from
> outside? And if we combine this with a more unit
> test centric model perhaps it would be enough.

Honestly, I doubt it. The working style doesn't go that way. If you are a
user of some package you need to read the documentation first. That's fine
as far as it goes. But then you start screwing around and see that "perfect
method" which solves your problem immediately. And so you use it. There's
nothing in the _code_ that tells you "don't use me, I am private to that
package and using me means you're doomed to fail a couple of releases down
the road". The same on the other end. If you're a package developer you have
to constantly go to a different place and update your documentation. And
naturally, you will forget to do this because it's awkward. If you want to
solve this problem by documentation then this documentation must be
intrinsically linked to the code involved. And once you do that it _is_
essentially a more declarative style of programming - even if you would put
it into comments (which I wouldn't).

Also, the big issue with "all remote senders" which you were proposing is
not the fact that you can find those senders. Again, that's fine but the
problem is you can't _fix_ them. And that means you have to rely on the
implementors of that other package that they only use what you have declared
to be the "public API" which brings us back to the above issue. At this
point you could in fact say that everyone who uses any "private messages" to
that package be screwed but you can carefully phase out obsolete public
messages without the fear to break anything that has been written according
to your design (e.g., using public messages).

The key issue is that both implementors and clients of a framework need to
be able to tell what interfaces exactly they can rely on. If you can't tell
this, handling large decentralized packages _will_ be a nightmare before
long. We cannot expect people to lock-step in the development if those
packages are individually developed, we cannot rely on having that "large
synchronized base" (e.g., monolithic image). If we want to allow evolution
then we must find a model of determining what we promise to support "long
term" (e.g., across minor versions) and what we don't.

  - Andreas

More information about the Squeakfoundation mailing list