|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> Works great, as long as they're the same type. Try swapping an array of
>> integers with a socket.
>
> Wouldn't it break the code which expects the object to be an array, but
> the object gets suddenly changed to something completely different?
It depends on whether (say) there's some other data structure telling you
what to do with the thing. That, of course, was a rather extreme example
that might in practice never be useful.
Smalltalk used becomes: all the time while running to make variable-size
arrays. Rather than having one object hold the description of the array and
forward all messages to it, instead when the array had to grow, you created
a new array, copied the data into it, and then "becomes:" the new array.
Also, remember that Smalltalk used a process image. There was all kinds of
data in memory even as you're editing code. So if you changed a class to add
an instance variable, the system would find all the existing instances, copy
them to instances of the new class, and have each become: the new version,
even as the system is running.
> (What does Smalltalk do when an inexistent method is called? Runtime error?
It packages up the method invocation as an object of type "Message" (which
gives the selector and arguments, basically) and then sends the original
receiver a message called "doesNotUnderstand:" with the message as an
argument. (Knowing that, rereading the article where they're talking about
hunks pointing to on-disk structures probably makes more sense.)
Technically, in a safe language, there's no such thing as a "runtime error";
they all get translated to something well-defined. And since Smalltalk was
originally also the OS, you had nowhere for a "runtime error" in the SIGSEGV
sense to go.
Now, the top of the inheritance heirarchy is class Object, and Object
implements "doesNotUnderstand:" to (basically) start up the debugger as if
you hit a breakpoint at the address of the original message send. So in that
sense, yes, if you don't catch "doesNotUnderstand" then you have a runtime
error. But the system keeps happily humming along, running other processes,
and you can go back and fix whatever was broken (see above) and then resume
from whichever frame on the stack makes the most sense.
> That's at least what happens in Objective-C, which is based on the same
> principles as Smalltalk, IIRC.)
The language is, but the run-time system is quite different. Smalltalk and
APL both have "workspaces" where things live. With the original Smalltalk,
you'd put your disk in, boot the system, and you'd be back to where you were
when you last shut down, quite a lot like "hibernate" nowadays. The
Smalltalk primitives were the microcode of the CPU while you were running
Smalltalk, and there was no "OS" or "file system" outside the language
interpreter. (Which explains, incidentally, the lack of a need for
destructors - there were no external resources needing to be cleaned up.)
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
![](/i/fill.gif) |