Jecel Assumpcao Jr jecel@merlintec.com wrote:
On Friday 22 February 2002 23:38, Anthony Hannan wrote:
- A Smalltalk expression now knows, via the selectors it calls, which
protocols and corresponding default behaviors it depends on. So starting from a Smalltalk expression we can trace selectors and methods recursively and load all default behaviors that will be needed.
Two slight problems:
- #perform:
perform: will have to take a selector object that already knows its protocol instead of just a symbol. The selector's protocol will be loaded at runtime when the perform is triggered.
- if #foo is used in only one protocol in your system, you don't
have to say which one that is, right? Now imagine that you send your module to me and I load it into my system which also has a #foo in only one protocol, but it happens to be a different protocol from yours!
The compiled method will have the selector object "foo" in its literals which knows its protocol, not the symbol #foo. So if you send the compiled method to another image (via image segments) then the protocol will go with it. If you just send the source code, your right, "foo" will be looked up in the new environment. But this is the same problem we have with globals now. How do I know "String" in my image means the same as "String" in your image?
Cheers, Anthony
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Anthony Hannan Sent: Saturday, February 23, 2002 9:21 AM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Behaviors vs Modules
Jecel Assumpcao Jr jecel@merlintec.com wrote:
On Friday 22 February 2002 23:38, Anthony Hannan wrote:
- A Smalltalk expression now knows, via the selectors it calls,
which
protocols and corresponding default behaviors it depends on. So starting from a Smalltalk expression we can trace selectors and methods recursively and load all default behaviors that will be needed.
Two slight problems:
- #perform:
perform: will have to take a selector object that already knows its protocol instead of just a symbol. The selector's protocol will be
loaded
at runtime when the perform is triggered.
Exactly.
A given selector <Symbol> instance in SmallScript is always associated with a namespace. I.e., a symbol consists of a selector familyName, a selector scope (namespace), and a family-group-selector (for var-args).
Where an interface is a class, and classes are namespaces. So a symbol can have its scope/namespace be an interface. Which is what gives you the callsite (callers) desired "protocol".
-- Dave S. [SmallScript Corp]
SmallScript for the AOS & .NET Platforms David.Simmons@SmallScript.com | http://www.smallscript.org
- if #foo is used in only one protocol in your system, you don't
have to say which one that is, right? Now imagine that you send your module to me and I load it into my system which also has a #foo in
only
one protocol, but it happens to be a different protocol from yours!
The compiled method will have the selector object "foo" in its
literals
which knows its protocol, not the symbol #foo. So if you send the compiled method to another image (via image segments) then the
protocol
will go with it. If you just send the source code, your right, "foo" will be looked up in the new environment. But this is the same
problem
we have with globals now. How do I know "String" in my image means
the
same as "String" in your image?
Cheers, Anthony
Jecel Assumpcao Jr jecel@merlintec.com wrote:
On Friday 22 February 2002 23:38, Anthony Hannan wrote:
- A Smalltalk expression now knows, via the selectors it calls, which
protocols and corresponding default behaviors it depends on. So starting from a Smalltalk expression we can trace selectors and methods recursively and load all default behaviors that will be needed.
Two slight problems:
- #perform:
perform: will have to take a selector object that already knows its protocol instead of just a symbol. The selector's protocol will be loaded at runtime when the perform is triggered.
Yes. I think this is related to Dave S's response, but this is also desirable (nay necessary) for any program to do a decent job of type inference.
- Dan
PS: GO, you guys!
squeak-dev@lists.squeakfoundation.org