> From: "Andreas Raab" <Andreas.Raab at gmx.de>
>
> It could, although right now it doesn't. It's true that the object
> creation primitive through #new: expects a "primitive number" (more
> accurately a primitive integer) but the failure code for this primitive
> could handle this failure condition by testing for, and if needed,
> asking for a primitive number. So it depends on how you look at it - the
> object creation primitive cannot deal with a "non-primitive number" but
> the behavior of #new: could still be well-defined for those. BTW, it
> should be noted here that at some point you need to get down to
> "primitive numbers" in order to do stuff like allocating the object. So
> handling those non-primitive numbers in the error-recovery code seems
> pretty reasonable to me.
>

Hi. Thanks for the informative response.

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 code that contained the fragment

(ByteArray new: five)

where five acts just like 5 then I think there is a problem. Suppose I come
along with some great debugger or program analysis tool that works as
follows. I define variants of all the built-in types like numbers that
maintain a data structure of the history of the messages they receive and
also forward all messages along to the primitive object. I want to use my
version of numbers to used while running arbitrary Smalltalk code. 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.

Best,

-ken kahn ( www.toontalk.com )