Method Scoping and Runtime Envinronments

Derek Brans brans at nerdonawire.com
Fri Feb 7 22:39:51 UTC 2003


On Friday, February 7, 2003, at 01:52 PM, Stephen Pair wrote:

> Derek Brans wrote:
>> It would be so nice to call a function in a piece of code and
>> instead of
>> the call travelling up the class hierarchy in search of an
>> implementor,
>> it could also travel through some other scoping hierarchy similar to
>> that of Runtime Environments.
>
> You can use blocks to accomplish this result.  The code might look like:
>
> Env at: #someName put: [ self doSomething ]
>
> Then, later you could access and evaluate the block with:
>
> (Env at: #someName) value

Neat.  I might override "perform:" on Object to make it less verbose.

>
> But, I'm curious why you'd want to do this rather than just invoke a
> method of an object in your dynamic scope.

In some cases I don't want the sender to care who is implementing the 
method, as in the class hierarchy.
I think what I'm suggesting is a bit like adding a superclass or trait 
at runtime.

>
>> It would be even cooler if you could just call
>> functionName
>> and the system would search self first and then Env for an
>> implementor.
>
> This idea touches on layers and perspectives.
>
I'll have to research that.

Nerd on a Wire: Web and Information Solutions
Website Design - Database Systems - Site Hosting
604.874.6463
mailto:info at nerdonawire.com
For more information, visit http://nerdonawire.com



More information about the Squeak-dev mailing list