[ANSI-Smalltalk] #contents on <collectionStream> (was: #contents on WriteStream)

[Richard O'Keefe]

On 21 Oct 2008, at 6:44 am, Bruce Badger wrote:
> Or perhaps there needs to be a family of stream classes each with
> obvious behaviour.  It would be nice to have as much consistency as
> possible, but things like >>contents will inevitably be different
> depending on the underlying 'collection'

The *implementation* will be different.
It is far from clear that the *semantics* should be different.
It certainly isn't *inevitable* that the semantics differ;
the standard says it shouldn't, and in my library it doesn't.
> .
>
>> But if major implementations haven't caught up with the
>> 1998 standard yet, then maybe they won't ever.
>
> Heh - perhaps they have left it behind and it's the standards work
> that needs to catch up.

The standard was basically an agreement between a bunch of
people, including people from Gemstone, ParcPlace-Digitalk,
and IBM.  It was a minimal standard.  Implementations of
the day had very different GUI kits, so there is no GUI.
Many specifications were drastically weakened, for example,
#add: and #addAll: are defined to return their argument in
the Blue Book, but have UNSPECIFIED results in the standard,
presumably to accommodate implementors who wanted to return
something else.

If implementations don't conform 10 years later to such a
minimal standard, it suggests that implementors have seen
no value in conformance.  Implementations *have* adopted
the interchange format, but not, for example, the ANSI
methods for opening file streams, which ought to be pretty
easy to add.

It's not clear that there is much point in revising the
standard unless there is serious intent among _some_
implementors to offer some degree of support for it.

It is beyond dispute that back in 1998 existing
implementations were chock full of good stuff that
programmers would have loved to see in the standard.
(Why, for example, is Heap not in the standard?)
Today there is vastly more.  Much of it differs, and
implementors have no intention of abandoning their
customers.

A standard Smalltalk binding to the ECMA data base interface
(an extended version is known as ODBC) would be a nice thing
to have, no?

In other correspondence on another topic, I've pointed out
that if you are the major player in a market, standards you
do not control are not to your advantage.  It's the minor
players who benefit from standards.  All Smalltalks put
together count as a minor player.  A larger standard that
people can develop to should mean a larger Smalltalk market.

though it is,
grasp