I want to give priority of a class' hierarchy's bindings over that of (self environment) when the latter defaults to the Smalltalk global dictionary (as is the case today in most images).
Attached is a patch which supports SharedPool as it was introduced in
- http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/058391.html
But with the patch the scope of global variables is now as follows:
1] classPool 2] sharedPools 3] environment if ~~ Smalltalk 4] superclass 5] Smalltalk (or equivalently, nil environment)
Without the patch and as is today, item 5] takes precedence over the superclass hierarchy item 4] whenever (aClass environment == Smalltalk) is the default. With the patch inheritance has priority. It can for example be made possible to "shadow" any global variable by using a SharedPool and class initialization code, and that is now inherited.
Feedback is appreciated; also if you want see the patch in the next release.
/Klaus
On 2/27/08, Klaus D. Witzel klaus.witzel@cobss.com wrote:
I want to give priority of a class' hierarchy's bindings over that of (self environment) when the latter defaults to the Smalltalk global dictionary (as is the case today in most images).
Attached is a patch which supports SharedPool as it was introduced in
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/058391.html
The patch looks good to me. I especially like how you refer to Smalltalk as "nil environment".
I modified this code to get Namespaces resolving right.
Gulik.
On Thu, 28 Feb 2008 09:12:10 +0100, Michael van der Gulik wrote:
On 2/27/08, Klaus D. Witzel wrote:
I want to give priority of a class' hierarchy's bindings over that of (self environment) when the latter defaults to the Smalltalk global dictionary (as is the case today in most images).
Attached is a patch which supports SharedPool as it was introduced in
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/058391.html
The patch looks good to me. I especially like how you refer to Smalltalk as "nil environment".
:)
I modified this code to get Namespaces resolving right.
Did you mean this like, you adapted it to your Namespaces. If not, can you elaborate a bit, TIA.
Gulik.
On 2/28/08, Klaus D. Witzel klaus.witzel@cobss.com wrote:
On Thu, 28 Feb 2008 09:12:10 +0100, Michael van der Gulik wrote:
On 2/27/08, Klaus D. Witzel wrote:
I want to give priority of a class' hierarchy's bindings over that of (self environment) when the latter defaults to the Smalltalk global dictionary (as is the case today in most images).
Attached is a patch which supports SharedPool as it was introduced in
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/058391.html
The patch looks good to me. I especially like how you refer to Smalltalk as "nil environment".
:)
I modified this code to get Namespaces resolving right.
Did you mean this like, you adapted it to your Namespaces. If not, can you elaborate a bit, TIA.
Actually, on closer inspection, I didn't modify the method except to remove shared pools, which can be implemented using Namespaces anyway.
In my Namespaces, "aClass environment" returns the local namespace.
Gulik.
On Fri, 29 Feb 2008 05:26:20 +0100, Michael van der Gulik wrote:
On 2/28/08, Klaus D. Witzel wrote:
On Thu, 28 Feb 2008 09:12:10 +0100, Michael van der Gulik wrote:
On 2/27/08, Klaus D. Witzel wrote:
I want to give priority of a class' hierarchy's bindings over that of (self environment) when the latter defaults to the Smalltalk global dictionary (as is the case today in most images).
Attached is a patch which supports SharedPool as it was introduced in
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/058391.html
The patch looks good to me. I especially like how you refer to
Smalltalk as "nil environment".
:)
I modified this code to get Namespaces resolving right.
Did you mean this like, you adapted it to your Namespaces. If not, can you elaborate a bit, TIA.
Actually, on closer inspection, I didn't modify the method except to remove shared pools, which can be implemented using Namespaces anyway.
In my Namespaces, "aClass environment" returns the local namespace.
Ah :) Then, do you have a special browser (or patched) which evaluates a class definition in scope? What I found in .images, use of #defineClass:notifying: is insufficient for defining a class in scope other than global root Smalltalk :(
Whatever you already have for this, I'd like to use it :)
/Klaus
Gulik.
On Fri, 29 Feb 2008 08:51:51 +0100 "Klaus D. Witzel" klaus.witzel@cobss.com wrote:
Actually, on closer inspection, I didn't modify the method except to remove shared pools, which can be implemented using Namespaces anyway.
In my Namespaces, "aClass environment" returns the local namespace.
Ah :) Then, do you have a special browser (or patched) which evaluates a class definition in scope? What I found in .images, use of #defineClass:notifying: is insufficient for defining a class in scope other than global root Smalltalk :(
Whatever you already have for this, I'd like to use it :)
My NamespaceBrowser is available on the PackageUniverse for 3.10 under "Tools". It should install the dependencies that it needs, including Namespaces. Don't use it on an important image!
Note that this is still all very unstable and in development. Bug reports would be useless :-).
Gulik.
On Sat, 01 Mar 2008 00:18:31 +0100, Michael van der Gulik wrote:
On Fri, 29 Feb 2008 08:51:51 +0100 "Klaus D. Witzel" wrote:
Actually, on closer inspection, I didn't modify the method except to remove shared pools, which can be implemented using Namespaces anyway.
In my Namespaces, "aClass environment" returns the local namespace.
Ah :) Then, do you have a special browser (or patched) which evaluates a class definition in scope? What I found in .images, use of #defineClass:notifying: is insufficient for defining a class in scope other than global root Smalltalk :(
Whatever you already have for this, I'd like to use it :)
My NamespaceBrowser is available on the PackageUniverse for 3.10 under "Tools". It should install the dependencies that it needs, including Namespaces. Don't use it on an important image!
Ok so the squeak-dev .image loads it, nice, thanks :)
Note that this is still all very unstable and in development. Bug reports would be useless :-).
Nah, won't send no report :)
Gulik.
squeak-dev@lists.squeakfoundation.org