[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    Re: [eros-arch] EROS Mistake #1: No Object Perimeters
From:       "Lex Spoon" <lex () cc ! gatech ! edu>
Date:       2003-12-31 17:18:44
Message-ID: E1Abn1L-0007do-00 () logrus ! dnsalias ! net
[Download RAW message or body]

(Over Christmas break, I finally have time to read these meaty posts! 
Sorry if they are stale for some of you; I've been dying for a chance to
really look at them and am only just now responding.)


"Jonathan S. Shapiro" <shap@eros-os.org> wrote:
> As you ponder this, consider the analogy to the fatal smalltalk problem:
> it is not possible in smalltalk to draw any line between the runtime
> environment and the application. For this reason, revision control is
> fundamentally broken in smalltalk images. This is not a conceptual flaw
> in smalltalk -- indeed it was a deliberate design choice. However, it is
> an empirically fatal impediment to scalable software engineering when
> the software is based in smalltalk.
> 

This is strange, because I was about to point out that Smalltalk is
emperically successful despite your theoretical concerns.

On the issue of saving objects, Squeak users routinely exchange object
graphs with each other.  There are two separate approaches Squeak uses, and
they both seem effective.  First, its SmartRefStream allows objects to
be stubbed out when you do an export, and for the stubs to be hooked
back up in when you reload the objects into a new image.  For example,
any reference to World, the global graphics context, is replaced by a
stub; when you reload the object graph, you hook that stub up to the
World of the image that is doing the loading.  Second, its ImageSegments
can compute the "shadow" of an object that are only reachable from the
root.  That is, you mark the root object and then run the mark phase of
the garbage collector; everything that is not marked must be part of the
shadow.  Anything pointer from within the shadow to outside the shadow
is stubbed out just like with SmartRefStream.



On the other issue, the issue of revision control and software development,
let me just point out that the emperical evidence points flatly in the other
direction.  Smalltalk developers are quite successful at building large programs,
and they certainly do use revision control on the larger ones.  They are so
successful that there has been a trend of a few years now that new software development
approaches often come from Smalltalk developers and are then adapted to other
languages.


On both issues, experience has shown that these theoretical problems are
fine in practice.


Now to discuss principles, consider that while having some sort of external typed files
will give you some amount of object portability, note also that you have moved the pain
of portability to every single application that wants to persist an object.  The object-soup
approach limits the pain to applications that actually want to transmit an object.  Furthermore,
note that there really is no such thing as an object perimeter until an application
writer bothers to define one; in fact, the same object can have different perimeters depending
on the context.  All in all, the object soup approach seems like a big step forward.  It
would be nice to support *optional* object perimiters, but requiring a perimiter for every
object seems to be hacking down a tree that was difficult to grow in the first place.


Lex
_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch
[prev in list] [next in list] [prev in thread] [next in thread]