Ken writes:

> > > ...does the primitive for creating ByteArrays work only if a
> > built-in number follows new: ?

	Andreas responds:

> > It could, although right now it doesn't... the failure code for
> > this primitive could handle this failure condition by testing for,
> > and if needed, asking for a primitive number.

	Ken responds:

> If you mean error recovery code that is part of the behavior of #new:
> for ByteArray then why isn't it done? If you mean error recovery code
> by the person who wrote [the sending code] then I think there is a
> problem... If everything treated my version of numbers the same as the
> primitive numbers that they emulate all would be fine. But it doesn't
> seem to work that way and I'm trying understand why it doesn't get
> fixed.
> 
> Now of course you need to bottom out somewhere but this was first
> done in actor languages in the 70s. Behavior is all that should count
> though of course somewhere the implementation has to cheat and see if
> something is primitive or not. But that shouldn't show through.

	Sure; I think it's important to keep in mind that the implementation
provides a certain consistent illusion (of invoking behavior by sending
messages) but that the scope of the illusion necessarily depends on what
senders expect to accomplish. These expectations let the implementation
make certain assumptions, which typically turn into simplifications and
optimizations. So far, the general expectation senders have of
ByteArray>>new: lets the implementation make an assumption about the
parameter (that it's an instance of SmallInteger). If someone comes
along with a different expectation (such as the one you mention),
imposing it on the implementation may expose the underlying assumption.

	This is always true; for any implementation (containing a "cheat"), one
can come along with a different expectation which exposes the assumption
(or "breaks" it). Call it an "incompleteness" property for software,
similiar to the sense of incompleteness in Gödel's theorem. You're
trying to play a new phonograph-killing record. :)  (Hofstadter 1979,
you've probably read it, everyone should...). And you can always come up
with a new cheat the restores the illusion to match the new expectation.
Luckily, we can always do this with Squeak, although perhaps not with
the performance we would like. As you suggest, we can also change the
client to work around the limitations of the implementation, but I agree
that this is undesireable (because it overcomplicates use of the
system).


-C

--
Craig Latta
composer and computer scientist
craig.latta at netjam.org
www.netjam.org
crl at watson.ibm.com
Smalltalkers do: [:it | All with: Class, (And love: it)]