On 9/23/07, Igor Stasenko <siguctua at gmail.com> wrote:
>
> 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 tried and gave up - Monticello seems designed with a global
SystemDictionary in mind and it feels like a kludge to try to make it
compatible with namespaces.

Matthew Fullmer gave me a great idea on IRC yesterday; I could manually put
together .mcz files. I've already got code that files out a package in chunk
format, so with a bit of extra work it's possible to make a Monticello file
out of it.

<snip - Keith pointing out that my approach doesn't do methods overrides>

>
> You pointed to interesting problem.



It's interesting that you find the biggest weakness of my approach with such
speed. I really don't know how to solve this, so I'm ignoring this problem
until some inspiration occurs.

The main issue is that one package should not be able to directly modify
another package, for security reasons, and because you lose the guarantee
that packages are deployed into the same environment they were coded in.

I've thought about having some fancy technique similar to ClassBoxes, where
an object has one behaviour when appearing to one client, and another
behaviour when appearing to another client, but that approach is likely to
open a big can of Pandora's boxes.

You could use wrapper objects. In fact, wrappers will be a common and
important pattern that you would use when writing secure code.


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



This is a possibility, but it has a big weakness. Often you want to use
instances that are passed to your package from somewhere else, and these
would not be instances of your overridden class.



> > 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.



This would likely happen but would be done manually by developers.

> 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'm not quite this far ahead yet. This could certainly be implemented by
tools if you want.

Gulik.


-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070923/5804183a/attachment.htm