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
|