[Omake] Not hoisting from method exports, when the head variable is already shadowed?

[Aleksey Nogin]

Jason,

I've checked in an experimental implementation of the idea I proposed 
last week. As I said in the commit message, feel free to revert if you 
think it's a wrong thing to do.

Aleksey

On 19.07.2007 15:23, Aleksey Nogin wrote:

> On 19.07.2007 14:51, Jason Hickey wrote:
> 
>> We get the conflict when the head variable is the same as a definition 
>> in the body.
>>
>>   foo. =
>>      boo() =
>>         foo = 1
>>         export
>>
>>   foo.boo()
>>   # What is foo?
>>
> I would propose the following semantics - when we do "foo = 1", we have 
> essentially shadowed the previous foo definition. Semantically the 
> "export" both hoists and shadows - first hoists "this" into foo, next 
> updates the "foo" binding to point to 1. However, the former action is 
> invisible as there is no way to access it's result.
> 
> Another way to think about this semantics is that the hoisting updated 
> the "old foo", but that "old foo" is no longer accessible, as the "new 
> foo" have shadowed it. Yet another way - direct update has higher 
> priority that indirect one. Or - that binding of a name to a value is 
> stronger that the binding of a name to its object namespace.
> 
> Implementationally this would probably mean something like.
>  - first do the normal functional export
>  - next, see if the value of the head variable is == to its original value
>  - if so, hoist the "this" into it.
> 
> Aleksey

-- 
Aleksey Nogin, Research Scientist
Advanced Technologies Department, Information & System Sciences Lab
HRL Laboratories, LLC, Malibu, CA
-------------- next part --------------
An embedded message was scrubbed...
From: nogin at metaprl.org (Aleksey Nogin)
Subject: [Omake] SVN Commit: OMake Build System [0.9.8.x] (Rev. 11448)
Date: Thu, 26 Jul 2007 09:30:29 -0700
Size: 2595
Url: http://lists.metaprl.org/pipermail/omake-devel/attachments/20070726/f69c0d25/OMakeBuildSystem0.9.8.xRev.mht