|
 |
Darren New <dne### [at] san rrcom> 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?
(What does Smalltalk do when an inexistent method is called? Runtime error?
That's at least what happens in Objective-C, which is based on the same
principles as Smalltalk, IIRC.)
--
- Warp
Post a reply to this message
|
|
|
|
>> 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?
One would presume so, yes. Depends what you decide to replace it with.
> (What does Smalltalk do when an inexistent method is called? Runtime error?
> That's at least what happens in Objective-C, which is based on the same
> principles as Smalltalk, IIRC.)
Does calls #doesNotUnderstand:, which is a regular method. BY DEFAULT
this throws an exception, but you can override it to do... whatever you
want.
Darren's original article describes using it to load objects from disk
the first time somebody tries to access them, for example.
I saw somebody else describe overriding it to implement multiple
dispatch. (Smalltalk itself supports only single dispatch, like most OO
languages.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
|
|
Warp <war### [at] tagpovrayorg> wrote:
> (What does Smalltalk do when an inexistent method is called? Runtime error?
> That's at least what happens in Objective-C, which is based on the same
> principles as Smalltalk, IIRC.)
If I understood the article right, then Smalltalk calls some "doesNotUnderstand"
method of the object (which, of course, may default to raising a runtime error I
guess).
Post a reply to this message
|
|
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> 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
|
|
