[ANN] Another namespaces approach.

Igor Stasenko siguctua at gmail.com
Sat Sep 22 22:57:13 UTC 2007


On 22/09/2007, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
> Hi Michael,
>
> I think your approach sounds great and I will definitely try it out.
>
> I can help integrate this with Monticello.
>
> I can see this potentially help in moving the kernel forward, since new
> kernel module implementations
> can co-exist with the old ones in the transition. I like the idea that
> when no one uses the old package it can simply disappear. (bye bye
> FileDirectory!)
>
> For simple kernel class extensions and overrides, it is probably
> simplest to copy the whole class into the package. Lets call this the
> "copy and modify" approach.
>
> However this could get difficult, since a package like Magma adds
> serialization methods to cover a lot of classes in the system, and these
> serialization methods do need access to all instVars. To support this
> there would have to be some notion of "Package A which is trusted to
> make extensions to Package B".... but what if I load Magma with the
> intention of extending all users of String, but actually users of
> My.String will miss out on those extensions. Also if you look at magma,
> you will find some classes which have method contributions from
> *magma-server, and contributions from *magma-client. There is a
> dovetailing of packages to make a whole. Perhaps this could be solved by
> having a specialized form of a class with is not a complete copy, but a
> wrapper around the original, with the extension methods. I call this the
> "link-to and extend" idea. Perhaps the additional methods could be
> defined in the form of a deltastream.
>

You pointed to interesting problem.
Lets consider, how should be Magma loaded into image with namespaces enabled:
- any extensions to existing packages (like Kernel) should be done
with 'copy and modify' approach.
'Copy and modify' can be done in two ways:
- we can create a new version of base package and add new behavoirs
there. Then Magma imports these modified packages, which in same turn
importing old non-modified packages.
Like following:
Magma -> Kernel(MagmaMod) -> Kernel

Another way, we can simply copy and modify behaviors to Magma package
itself and any non-modified behaviors are still visible via imports.
So, magma will contain own version of, say Collection class, and don't
need to change imports list.

And now most interesting thing: serializing objects.
First, to make use of Magma, you need to add it to imports list in
your project package. And thus, you could see all changes to base
packages done by Magma.

Second, I don't think that we need to support serialization of every
object in image! Personally, i think its more useful and safe to
enable serialization only of those objects which used by Magma and
which you making serializeable by importing Magma package into your
own.
In fact, since only your package knowns how to work with magma (by
importing it), only this package should be granted to use
serialization.
Any attempt so serialize objects, which not belong to package(s) Magma
imports branch should be considered as erroneous (and in fact this
will lead to errors due to DNU's, because of use non-modified Kernel
behaviors which installed by Magma).

Maybe this is wrong or impossible? Time will say. But i think things
should be done in that way. I can see how this approach helping to
prevent from appearing any objects, unrelated to your project, in
Magma DB and thus could indicate design flaws.

I'm very interesting in what Michael will say. I can presume, that he
strongly against enabling image-wide serialization because its
obviously a security issue. And in Secure Squeak such things should be
impossible.

> So it looks like we need a new paradigm for class extensions. If we
> could use deltastreams then we can have the idea of class extensions as
> a patch queue.
>
> I also thought that if there is a  nominated "master" repository for
> each namespace, then the master repository could be updated with EVERY
> users adaptation.
>
> So if I were the owner of Kernel.Foo and other people include Kernel.Foo
> in their namespaces, whenever they "copy and modify" Kernel.Foo within
> their namespace, my Kernel.Foo repository gets a copy of the changed
> version! That way I can make an effort to integrate any additions.  If
> users "link to and extend" my Kernel.Foo, then my repository would get a
> copy of the delta-stream that defines the extension.
>
> I think that some social tools like this could help avoid the
> fragmentation that Göran hopes to avoid by only having one
> non-hierarchical namespace
>
> Keith
>


-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Squeak-dev mailing list