On Wed, Sep 16, 2009 at 2:40 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Michael van der Gulik wrote:
>
>> And the flamebait: which release has the fewest bugs in the Kernel-* and
>> Collections-* categories?
>>
>
> The latest trunk should be pretty good. Plus, if you can get MC to work,
> you could just merge newer versions.
>
> BTW, are you planning to support namespaces via Monticello? If so, can I
> ask you to talk a little more about what you are planning? Personally, I got
> completely stuck with Monticello's flat representation, i.e., the issue that
> definitions aren't nested. Since a method definition isn't located "inside"
> a class definition it makes it pretty much impossible to determine the
> actual scope of the method definition. For a brief (VERY brief) moment I
> considered rewriting Monticello but I quickly got cured when looking at the
> actual code involved.
>
>
I have no plans to support namespace code management via Monticello. I
looked at Monticello when I was designing them and decided that I didn't
like the design [of version 1.0].

I'll briefly describe what I'm planning below. I haven't started work on
this yet; Namespaces are currently usable but urgently need major
refactoring and then bug-fixing.

Documentation lives on http://gulik.pbwiki.com/Namespaces. Let me know if
anything there is hard to understand and I'll fill it in more.

The core of Namespaces will be the following classes:

Package - subclass of Namespace, forms the root of a namespace hierarchy.
Namespace - subclass of Dictionary mapping #Symbols to other Namespaces,
Classes and global variables.
Class - like it is now, sans source code but including
intermediate-representation of code from compiler as well.
CompiledMethod - like it is now, sans source code, with closures, literals
are strictly read-only.

and other classes to hold the intermediate representation of code, read-only
literals, documentation, meta-class stuff, etc.

The intermediate-representation of code will be generated from the
NewCompiler* with the IR (intermediate-representation) classes borrowed from
there (from memory, I think they were called "IR classes", I forget). When
packages are moved between images, the IR will be serialized and
deserialized in binary form rather than using bytecodes because it is much
easier to verify that IR is secure than bytecodes. Doing it this way also
has some other benefits, such as letting the receiving VM have a completely
different bytecode set.

The source code management will be external to the above. Any source code
management system can be used as long as it generates a valid Package object
structure. The source code tools will need to hold their own mirror objects
of the structure of a package and its source. I'll be making a simple set of
tools based on what I already have, and I hope that at some stage in the
future, other people can make better tools.

(*) the NewCompiler would be an external source code management tool. It
would be completely optional.

Gulik.

-- 
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090916/066b047f/attachment.htm