<br><br><div><span class="gmail_quote">On 9/23/07, <b class="gmail_sendername">Igor Stasenko</b> <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 22/09/2007, Keith Hodges <<a href="mailto:keith_hodges@yahoo.co.uk">keith_hodges@yahoo.co.uk</a>> wrote:<br>> Hi Michael,<br>><br>> I think your approach sounds great and I will definitely try it out.<br>
><br>> I can help integrate this with Monticello.</blockquote><div><br><br>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.
<br><br>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.
<br></div><div><br><snip - Keith pointing out that my approach doesn't do methods overrides><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>You pointed to interesting problem.</blockquote><div><br><br>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.
<br></div><br>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.
<br><br>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.
<br><br>You could use wrapper objects. In fact, wrappers will be a common and important pattern that you would use when writing secure code.<br><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Lets consider, how should be Magma loaded into image with namespaces enabled:<br>- any extensions to existing packages (like Kernel) should be done<br>with 'copy and modify' approach.<br>'Copy and modify' can be done in two ways:
<br>- we can create a new version of base package and add new behavoirs<br>there. Then Magma imports these modified packages, which in same turn<br>importing old non-modified packages.<br>Like following:<br>Magma -> Kernel(MagmaMod) -> Kernel
</blockquote><div><br><br>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.<br>
</div><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>> I also thought that if there is a nominated "master" repository for
<br>> each namespace, then the master repository could be updated with EVERY<br>> users adaptation.</blockquote><div><br><br>This would likely happen but would be done manually by developers. </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> So if I were the owner of Kernel.Foo and other people include Kernel.Foo<br>> in their namespaces, whenever they "copy and modify" Kernel.Foo within<br>> their namespace, my Kernel.Foo repository gets a copy of the changed
<br>> version! That way I can make an effort to integrate any additions. If<br>> users "link to and extend" my Kernel.Foo, then my repository would get a<br>> copy of the delta-stream that defines the extension.
</blockquote><div><br><br>I'm not quite this far ahead yet. This could certainly be implemented by tools if you want. </div></div><br>Gulik.<br><br clear="all"><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">
http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a>