Squeak Foundation Board 2007 Candidates

Did you read the paper of benny saedh on my web page on dynamic  
interface?
Because may be this is what you are looking for?

Stef


On 23 févr. 07, at 08:46, Göran Krampe wrote:

Sorry I was terribly busy with my house.
Now should each candidates reply to the questions of ron following  
what craig just did?
I'm confused I thought that we should not but Craig seems to reply to  
all the questions.

Stef

I agree.
This is important to get exposed and I'm sure that todd was not  
implying much but your remark is correct.

I would like to see how we can get more process-aware/thread safe  
libraries

Do you have some pointers to the features you find interesting?

On 21 févr. 07, at 09:24, Todd Blanchard wrote:

Sounds really interesting for small devices. Thanks for the pointer.

>
> So there is lots of great stuff to steal - but not much of it from  
> the mainstream languages - they mostly seem to ape the last  
> generation and then take a little lunge in the direction of Smalltalk.
>
> -Todd Blanchard
>
>

On 21 févr. 07, at 10:10, Stéphane Rollandin wrote:

> Göran Krampe wrote:
>>  I love the fact we got Traits - even though it hasn't taken
>> off yet AFAIK - anyone using them btw?
>
>
> I'm waiting for the tools to be ready...
like everybody else but nobody is helping. too bad. no time.

>
> Stef
>
>

Todd Blanchard a écrit : To be fast, you could rely on message sending

respondsToProtocol: aProtocol
        ^self protocolChecker perform: aProtocol symbolicName

protoclChecker would answer an anonymous subclass of ProtocolChecker
ProtocolChecker would implement doesNotUnderstand as:
- checking if all methods of protocol are understood (needs a link back
to associated class)
- implement a new method (aProtocol symbolicName) answering true or false

In order to inherit protocol, you would have to construct
ProtocolChecker hierarchy like the metaclass one...

Adding or deleting in the methodDictionary would trigger a self
protocolChecker flushCache in all subclasses.

The flushCache should also be invoked whenever a Protocol definition changes

And Andreas, please don't ask how this would mix with Traits!

Of course, this is overkill compared to a simple <Dictionary of Protocol>

Nicolas

Hi Stef,

I would love you have you answer my questions, and all the questions that
appear on the wiki site.  The issue that Craig raised wondered if my
questions had some sort of implied Ron's agenda attached to them.  If you
feel that my questions have some sort of agenda please feel free as Craig
did to point that out in your answer.  

I really think it would have been better to have created an article for
weeklySqueak since we are getting 500-1000 readers a day which is larger
then our community.  I thought it would be good press for us so I threw what
I thought were softball questions which I guess were miss-interpreted.

I certainly understand Craig's point of view considering our private
disagreements about the board, but I didn't intend any agenda, nor did I
have ulterior motives.  I accept the responsibility for the
miss-understanding and apologize if my comments and questions were taken
that way.

I have pretty thick skin, and I know you do too, even if your comments don't
always show that.  Giving that I know you can take some criticism I would
like to add an additional question for you to answer.

Your comments on the wiki site say that if things are not better based on
the first meeting after the election you will resign again.  My question to
you is do you feel that is fair to the board to leave it with only 6 members
because you do not agree with the other board members?  Can you find a way
to stay and work out your differences instead?

Thanks Stef!

Ron Teitelbaum
Squeak Community Member

Andreas. This is true that the Traits implementation could be done  
without traits and be more understandable.
This could be simply done by flattening those traits. The  
implementation is not that complex. At least to me the compiler looks  
more complex.
Traits are simple. Have a look at the master of Adrian.
Monticello is really complex to me I can never find what I should  
extend or call. I read MC2 and this is much simpler to my eyes.
When I program MC I copy and paste since in general I cannot find  
what I have to do (lost in ancestor working copies and the rest).

Stef

On 22 févr. 07, at 09:17, Andreas Raab wrote:

Cees de Groot wrote:
> Beyond that - modules, components, or what you want to call them. I'm
> a Jini adept, and I've seen the power of having a network of
> cooperating components work for you. I also like E a lot, and think
> that some sandboxing system is required to scale Squeak - we must
> clean up the kernel to make it fully capability-based (also something
> that Java got more right than most people assume).

More right, but not right. Fortunately, it's right enough to be fixable by a
layer on top: <http://www.joe-e.org>. Likewise for OCaml
<http://www.hpl.hp.com/techreports/2006/HPL-2006-116.html>. I'd love to see
Squeak evolve to support a similar level of secure cooperation.


--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

J J wrote:
> Interfaces in Java are mostly just a pain IMO.  They provide a few extra
> protections here and there, and give the programmer hints as he browses
> the code, but since you can't add a default implementation to them they
> just enforce a certain level of code duplication.  At least in my
> experience and most of the Java programmers I know (admittedly not the
> whole world).

The main problem is the (mostly) static nature of interfaces in Java.
E.g., declaring them is a pain, otherwise I would disagree. If you want
to share a default implementation use a subclass - one of the big
problems I see with traits is that their interfaces get so specific that
an *alternative* implementation becomes effectively impossible
(therefore completely loosing the point about interfaces as abstractions).

For example, look at TAccessingMethodDictDescription (which is simply
the first in the browser) - it is practically impossible to reimplement
this (or any other) of the current traits for the class kernel in any
way that doesn't exactly follow the current implementation (like if TAMD
is responsible for accessing the method dictionary then we should be
able to reimplement MD access without affecting any other trait, right?).

As I see it, there are *way* too many dependencies between these traits
and interfaces can help to abstract from these dependencies. For sharing
(default or not) implementation, Java (as well as Squeak) has a single
inheritance tree which works for almost all purposes just fine. If you
use delegation instead of inheritance it works for *everything* just
fine and, IMO, typically results in a better set of collaborators
because suddenly these roles become objects themselves.

> So from a usefulness point of view I think Traits already should be
> better, and once the tools support them they will give the same hints
> the Java implementation does at least.

Early on I thought the same way (and this was why we started thinking
down that road when Nathanael interned with us). However, in practice it
seems like Traits are mostly being used as a thinly veiled version of MI
with all the same problems. You have correctly pointed out that Java
interfaces are "nothing but abstract virtual base classes in C++" -
which coincidentally, was the only way that MI ever worked in C++, which
itself has two dozen ways of doing MI wrong and exactly ONE to do it
right (abstract virtual base classes). Java choose a stand on that and
it worked (which is pretty impressive given that it was the first
language that used interface to that extent). Traits seem to reintroduce
a number of ways of using MI wrongly (at least that's the feeling that I
get when I look at the practical example) and that's why I prefer
interfaces.

Cheers,
   - Andreas

Does it have to be this way, or are you looking at a... less then optimal
use of a workable technology.

You asked before if I had used traits, and of course I haven't.  I haven't
felt the need to reach for them so far, and I am under the impression that
the tools aren't ready anyway.

But I have used Type classes in Haskell which is where I am taking my
vantage point from.  For those who may not know, type classes just specify a
specific "interface" (set of functions), and any type that wants to be in
that type class must provide an implementation.  The class definition can
specify default implementations.  For example:

class Eq where
  (==) lhs rhs = not (lhs != rhs)
  (!=) lhs rhs = not (lhs == rhs)

Now, as you notice, the definitions of those functions seem to depend on
each other.  The compiler would detect this and make an error, of course, if
someone tried to use them both.  It is simply a way to ensure that an
instance must supply either one, but they don't have to supply both.

For me, this provides everything that Java interfaces do (including type
safety.  You can say e.g. my new function works on any type, so long as it
implements the Eq class) and more, since the default implementation avoids
so much code duplication [1].

I hear what you are saying about "use a base class", but does my base class
still have to say "implements"?

Either way, this feels to me like another manifestation of a problem I
always had with Java:  implementation inheritance.  I may make 3 totally
different window widgets, and by rights each one would "implement" a draw
API, but I will have to invent another class for them all to inherit to
avoid duplicating a bunch of unrelated code.  People reading my code may
wonder why "3DGameWindow" is in the same tree as "TaskBarClockWidget", but
it is just to save code duplication.

This is what I have hopes that Traits can help me avoid.  I only inherit
when there is an inheritance relationship present, and Traits are for the
code that is in common but only as a coincidence (e.g. a car and a plane can
both drive on a street, but the only thing I see in common are the wheels).

Personally my inheritance trees never get very deep.  Normally just one
level down.

>For example, look at TAccessingMethodDictDescription (which is simply the
>first in the browser) - it is practically impossible to reimplement this
>(or any other) of the current traits for the class kernel in any way that
>doesn't exactly follow the current implementation (like if TAMD is
>responsible for accessing the method dictionary then we should be able to
>reimplement MD access without affecting any other trait, right?).

Is this a problem with the technology (Traits), or the implementation?

>As I see it, there are *way* too many dependencies between these traits and
>interfaces can help to abstract from these dependencies. For sharing
>(default or not) implementation, Java (as well as Squeak) has a single
>inheritance tree which works for almost all purposes just fine. If you use
>delegation instead of inheritance it works for *everything* just fine and,
>IMO, typically results in a better set of collaborators because suddenly
>these roles become objects themselves.

Well that is a good technique.  I don't personally see Traits as hammer or a
silver bullet, but I do think they (at least have potential to) fill a hole
[1].

>Early on I thought the same way (and this was why we started thinking down
>that road when Nathanael interned with us). However, in practice it seems
>like Traits are mostly being used as a thinly veiled version of MI with all
>the same problems. You have correctly pointed out that Java interfaces are
>"nothing but abstract virtual base classes in C++" - which coincidentally,
>was the only way that MI ever worked in C++, which itself has two dozen
>ways of doing MI wrong and exactly ONE to do it right (abstract virtual
>base classes).

Well, C++ was my favorite language for a long time (before I met Smalltalk
:), and I have used it quite a bit.  And I couldn't agree more.  The only
useful purpose I ever saw MI serve was just what you said.

And this is one thing I am paying attention to with the Traits stuff.  There
has been talk of adding variables to Traits and I (strongly) disagree with
this idea.  At that point, IMO it Traits would just be brining in MI through
the back door.  What I always think when I, or anyone else, came up with the
need to do MI is "rethink the design".  In every case I have ever seen, some
other pattern has always been a better choice.

But since Traits can't have variables, I would expect them to be useful in
many of the same ways Haskell type classes are.  I could be wrong, but I
hope I'm not and I can't think of a technical reason Traits must create
fragility.

>Java choose a stand on that and it worked (which is pretty impressive given
>that it was the first language that used interface to that extent). Traits
>seem to reintroduce a number of ways of using MI wrongly (at least that's
>the feeling that I get when I look at the practical example) and that's why
>I prefer interfaces.

I understand your concerns.  I never want to see Smalltalk go down the MI
road either.  But for me, the presence of variables is what differentiates
between MI and "interfaces with default implementations".

My point of view comes from seeing a system that has this and seems to work
very well.  I don't know what your experiences are, but if it's limited to
C++ then I don't wonder at your skepticism. :)

But I also wonder if it is sort of a "hot button" issue.  I mean, there are
things to be frustrated/embarrassed about here (e.g. releasing something
into the image that appears to have no means of maintaining).

[1]  Imagine the situation you would be in in Java if all class that can be
compared for equality must implement this interface!  Every single class
that implemented the interface would have one of those two functions just be
a "not" of the other.  And I don't think your solution of making a base
class is going to work here because we may also want classes like Ord (less
than, greater than) and so on.  You would need a base class for every
possible combination.

Of course the solution is to not have such a class, but is this the right
solution?  Shouldn't we have some fine grained reflective way of knowing if
the class supports a specific protocol like equality?

_________________________________________________________________
Refi Now: Rates near 39yr lows!  $430,000 Mortgage for $1,399/mo - Calculate
new payment
http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-17727&moid=7581

J J wrote:
Of course it doesn't have to be that way. But one of the hardest things
to do is to be honest about how particular features of languages
*actually* work out. It's like MI in C++ - of course there are ways of
using it "right" it's just nobody seems to use it that way (although I
will admit that my experience is dated - after having burned my fingers
several times I never used MI again other than in the Java way, that is
by using abstract virtual base classes).

[... snip ...]
> I hear what you are saying about "use a base class", but does my base
> class still have to say "implements"?

That depends on your particular flavor of interfaces. BTW, I do see your
point about Haskell but note that in your example you have both given
the definition as well as the constraint on a particular interface - in
my understanding this is more like specifying type algebra or pre/post
condition and not as much about actually providing the code for the
implementation.

> Either way, this feels to me like another manifestation of a problem I
> always had with Java:  implementation inheritance.  I may make 3 totally
> different window widgets, and by rights each one would "implement" a
> draw API, but I will have to invent another class for them all to
> inherit to avoid duplicating a bunch of unrelated code.  People reading
> my code may wonder why "3DGameWindow" is in the same tree as
> "TaskBarClockWidget", but it is just to save code duplication.

That's why I mentioned delegation. You could have an object
encapsulating the drawing policy and have your three classes delegate to
it. In which case you not only get the interface but also the ability to
dynamically change the drawing policy - at the cost of (at least) one
slot for the object representing the policy. To me, this is a much
cleaner way of dealing with the problem you are describing while
preserving all of the good properties of objects.

>> For example, look at TAccessingMethodDictDescription (which is simply
>> the first in the browser) - it is practically impossible to
>> reimplement this (or any other) of the current traits for the class
>> kernel in any way that doesn't exactly follow the current
>> implementation (like if TAMD is responsible for accessing the method
>> dictionary then we should be able to reimplement MD access without
>> affecting any other trait, right?).
>
> Is this a problem with the technology (Traits), or the implementation?

There is not enough evidence to draw a conclusion yet. The evidence is
that this implementation seems to have a problem towards that end and
the implementation was strongly driven by the desire to eliminate code
duplication (more so than to structure it into logical aspects). I think
that the attempt to eliminate duplicate code at all costs using traits
may ultimately lead to this effect simply because if you try to squeeze
all the entropy out of the system then the result will be a static
structure.

Interfaces on the other hand, precisely *because* of the overhead they
require tend to be more minimal, therefore more abstract and therefore
more easily to maintain and (re)implement.

> Well that is a good technique.  I don't personally see Traits as hammer
> or a silver bullet, but I do think they (at least have potential to)
> fill a hole [1].

Are we talking about a hole in Java or in Squeak? Your example only
applies to Java, not to Squeak (which has had #=, #==, #~~ and #~= in
Object from its very first day). For that particular problem we didn't
need traits. Now, I'm not saying there aren't places in which traits can
be usefully applied - in fact I am *dying* to see a good use case. One
where they actually help to make things simpler, structures clearer,
more easy to understand.

> But since Traits can't have variables, I would expect them to be useful
> in many of the same ways Haskell type classes are.  I could be wrong,
> but I hope I'm not and I can't think of a technical reason Traits must
> create fragility.

I need to read more about Haskell's type classes - I never looked too
closely at them. Do they actually specify implementation or is it all
type algebra (like in your example before)?

> But I also wonder if it is sort of a "hot button" issue.  I mean, there
> are things to be frustrated/embarrassed about here (e.g. releasing
> something into the image that appears to have no means of maintaining).

Of course it is frustrating. But what is worse is that while the paper
examples all look fine I just haven't been able to find an improvement
in understanding or design when I look at the (admittedly only) example
of a real-world use. If that is the future with traits then it is a
bleak future indeed. And of course it is quite possible that tools are
missing, that early explorations go wrong but at least we should be
honest enough to reflect critically on the artifact that was produced
and see what is right and see what is wrong.

Cheers,
   - Andreas

Well I agree.  When people use something badly we must always ask ourselves
if it was because the feature itself is bad.  And we must be prepared to say
yes.  Two examples would be... the entire C++ language and the entire Perl
language.  It's always funny when people say "this is
unreadable/unmaintainable!" and proponents  simply say "but you *can* write
readable code with it!".

I don't want Squeak/Smalltalk to be laughed at in this way, but at this
point I feel, as you say, we don't have overwhelming evidence yet as my two
examples do.

Well, I don't know what theories the Haskell community may try to place
around what is happening, but I know what it actually does:  it's just code
implementations of those functions.  If you wanted you could override both
of those in your new type to just return False.  The only constraint that
was put in place was the function type signature (takes two of type anything
as arguments and returns a boolean).

In fact you can use type classes to actually do OO, complete with (compile
time) function overrides based on type.  This I know from experience because
I translated my Smalltalk Recurrence rules to Haskell directly, and it
worked. :)

>That's why I mentioned delegation. You could have an object encapsulating
>the drawing policy and have your three classes delegate to it. In which
>case you not only get the interface but also the ability to dynamically
>change the drawing policy - at the cost of (at least) one slot for the
>object representing the policy. To me, this is a much cleaner way of
>dealing with the problem you are describing while preserving all of the
>good properties of objects.

Yes, this is one reason I don't personally do a great deal of inheritance.  
I find that other relationships are often more appropriate.

>>Is this a problem with the technology (Traits), or the implementation?
>
>There is not enough evidence to draw a conclusion yet. The evidence is that
>this implementation seems to have a problem towards that end and the
>implementation was strongly driven by the desire to eliminate code
>duplication (more so than to structure it into logical aspects). I think
>that the attempt to eliminate duplicate code at all costs using traits may
>ultimately lead to this effect simply because if you try to squeeze all the
>entropy out of the system then the result will be a static structure.

Yea, lack of tools are really hurting us here.  Does anyone have a diagram
or something on what traits are in the image, dependencies, etc.?

>Interfaces on the other hand, precisely *because* of the overhead they
>require tend to be more minimal, therefore more abstract and therefore more
>easily to maintain and (re)implement.

But, as in my Eq, Ord example, this overhead may also ensure they are never
used for one of things I think they are most applicable for.

>>Well that is a good technique.  I don't personally see Traits as hammer or
>>a silver bullet, but I do think they (at least have potential to) fill a
>>hole [1].
>
>Are we talking about a hole in Java or in Squeak?

I meant in OO in general.  Not to say OO is flawed, just that this is a
piece that was not part of the concept in the beginning (since it was
probably decided that inheritance can handle all the cases, which is true.  
It's just a question of organization) that probably needs to be.  And I feel
safe saying this given the fact that every (most?) language that supports OO
has some way of doing it.

>Your example only applies to Java, not to Squeak (which has had #=, #==,
>#~~ and #~= in Object from its very first day). For that particular problem
>we didn't need traits.

I would disagree here.  Well, not that you don't *need* traits.  Obviously
Smalltalk wasn't crippled without them, but something that fits this role
(at least the role I envision them filling) does make things clearer IMO.

For example, you mentioned that Squeak has #=, #== etc, and that is true.  
And testing if an object is the same instance as another (#==) does make
sense for all objects.  But does #=?  Are all objects capable of being able
to compared to other objects for equality?  What about #<, #>?

It is a powerful capability Squeak/Smalltalk has to ask an object if it
implements a method.  But in the case where someone asks if an object
implements #=, what they really want to ask is "are you an object that can
be compared to another for equality?".  And that implies not only #=, but at
least unequal as well.

I don't know exactly what Traits have been used for in the image, but I see
them as the solution to the "protocol" question that comes up from time to
time.  You can do the same thing with inheritance but you end up with either
really odd trees (e.g. ObjectWithEquality, ObjectWithoutEquality,
ObjectWithEqualityAndOrdering), or a lot of #shouldNotImplement.

>>But since Traits can't have variables, I would expect them to be useful in
>>many of the same ways Haskell type classes are.  I could be wrong, but I
>>hope I'm not and I can't think of a technical reason Traits must create
>>fragility.
>
>I need to read more about Haskell's type classes - I never looked too
>closely at them. Do they actually specify implementation or is it all type
>algebra (like in your example before)?

My example before was showing the actual implementation.  What you may be
thinking of is that often the default implementation isn't given, just the
type signature.  This would have looked like:

class Eq a where
  (==) a -> a -> Boolean              -- takes any type, followed by another
of that same type
  (!=) a -> a -> Boolean               -- and returns a Boolean.

In that case, you are just specifying what functions must be present, and
giving their type signature.  What I showed above gave two default
implementations (and left out the type signature to be deduced by the
compiler).  That way, if you go against the tide an decide only to implement
(!=) then == will work sensibly (since it just calls not on the results of
your ==).

Well, I think the tools are the problem here.  Either there are not any, or
at least no one seems to know where they are (I know I don't, and I see the
question come on the list just about anytime says "Traits").

And I suppose another problem is, Traits are kind of an advanced feature.  
The case of Eq, Ord and similar are very simple.  But what about Seaside?  
Should render classes all inherit from one, or are they simply unrelated
classes that happen to have a specific trait (the ability to render) in
common?

My take in this would be rendering classes inherit, but classes that get
rendered may just have "renderable" trait since many of them (at least the
ones I make) are complete domain objects that just happen to implement the
#renderOn: message.

But even in this contrived example, we can see that there can be ambiguity
in how they are used, and therefor they can be used wrong.  Whether this is
a "this language is unreadable/unmaintainable!" level issue is something we
will have to discover.

_________________________________________________________________
Play Flexicon: the crossword game that feeds your brain. PLAY now for FREE. 
  http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline

You really ought to look into ObjectiveC's Protocols.  Because they blow interfaces all to hell in terms of flexibility and Java's interfaces are borrowed from that (if one is to believe the Gosling apologists).

On Feb 24, 2007, at 1:21 AM, Andreas Raab wrote:
> It's like MI in C++ - of course there are ways of using it "right"  
> it's just nobody seems to use it that way

You can say that about any 10 features of C++.  It is why I bailed on  
it.

Virtual inheritance BTW, while theoretically available - didn't  
become reliably implemented across compilers until around 1996.  
Considering that I started using C++ in 1992 - I never felt  
comfortable using it as everytime I tried some platform somewhere  
would turn out to have a broken implementation.

Pure abstract virtual base classes was the only thing that worked well.

Templates were like that too - the only ones that worked were the  
ones you could inline.

Ah the memories - must remember to get them wiped.

-Todd Blanchard

Andreas Raab <[hidden email]> writes:
Security I'll give you.  That would be great if Squeak could do that.
Python, incidentally, can do such things with its module system.  We
could have that too, but having it plus also keeping our existing code
running is a really hard pair of features.

Anyway, the rest of Java's modules system I don't like at all.  Let me
mention two major problems.

First, it is troublesome to assemble groups of jar's along with their
dependencies for both compilation and execution.  It takes a while to
track down all the necessary jar's, and it is hard to debug errors
having to do with using the wrong version or with jar's that are only
accessed on some control paths.  To contrast, the ELF loader on Linux
blows it away.  You compile with -lm and get the math library plus its
dependencies.  You then run the resulting executable, with no extra
arguments at all.  Why doesn't Java work like that?  Is C technology
too advanced?


Second, linking jar's of different versions gives a lot of spurious
errors.  Package Universes for Squeak has a big advantage over the
same thing for Scala in that department.  It is rare for a Scala
package to remain usable for longer than a couple of months, because
the packages it links against keep getting changes in the signatures
and the Java type checker complains.  To contrast, some of the
packages in the 3.9 stable universe are over a year old.

It is to the point that Scala users periodically request on the list
that its version of package univeres use a non-JAR format.  I wish I
had time to design one, because I think they are right.  JAR is an
awkward format.

-Lex

Hi Lex -

Your criticism is well received and understood but unless you have an
alternative it is also utterly pointless. We can discuss the various
flaws in the Java module system to death but it doesn't change the fact
that it is there and it actually works. If you do know of any
alternatives that allow for scalable and reasonably secure deployment of
code in effectively unknown environments, I'll happily look at them. If
they are better than Java, great. It's just ... that so far there are so
damn few (if any) alternatives.

In short: What impresses me about the Java solution is not that it's
flawless - what impresses me is that it works, that people actually use
it to deploy code and this code actually works in the way intended.

Cheers,
   - Andreas

Lex Spoon wrote:

>
> Security I'll give you.  That would be great if Squeak could do that.
> Python, incidentally, can do such things with its module system.

Can you explain more lex?

Stef

On Fri, Feb 23, 2007 at 10:35:35PM -0800, Andreas Raab wrote:
Forgive me, but I am not familiar with "All the problems
Multiple Inheritance got wrong". I will be testing out how
Multiple Inheritance works in Squeak, since I have made it my
top priority to get ThingLab [1] working in a recent Squeak
system. ThingLab adds multiple inheritance [2] and a constraint
solver to Smalltalk, and both have at least a good theoretical
reason to be there, but I cannot test the implementation yet,
since such a change currently breaks squeak. Multiple
Inheritance has at least a solid theory; I have not had much
experience with an implementation.

[1] http://wiki.squeak.org/squeak/607
    Links to ThingLab papers and code.

[2] http://www.2share.com/thinglab/ThingLab%20-%20Chapter%203.html
    Chapter 3 of the ThingLab paper. Section 2 contains a
    defense of ThingLab's multiple inheritance.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

On 1 mars 07, at 06:59, Andreas Raab wrote:

But do you think that VW, VA code does not work once deployed? I  
would like to understand why Jar are better than parcels for example.
May be I should post to VW to see what are the problem with deployed  
code in VW.
A parcel in VW has dev and depl prerequisites and it seems to work too.

Stef