Integrating Modules with Projects
Last updated at 2:36 pm UTC on 16 January 2006
>I think I've had problems with "getting" Projects since they mix a few
>different concepts: projects to disk, name spaces, change isolation,
>publishing & the SuperSwiki, when they are "meant to be" a specific desktop
>configuration (as the class comment says), or really, your current working
>state. (I say this because I think this means that others will have similar
>problems. That's how self-centered I am :-) I see our venture very much as
>an opportunity for consolidation, to simplify things. (hg)
Well, I don't know that I could get this all right from the start, but yes, we do need to specify what is the real purpose of projects. The comment about desktop configuration is very old, and Alan dynamited it recently by insisting on multiply active projects. While it's not good to mix things for no reason, it's always nice if mixing them makes things simpler.
In spite of all the history and possible reasons for projects being what they are now, it might be better to take projects as browsable active content on the web, and work back to the simplest possible architecture that supports this.
So I think of Projects as being Squeak's component unit. What they are now, plus hooking up the environment instVar so that it is really used for project-local "globals" (including, natch, any Players and Player classes local to that Project (and here again we need a plan for migration)). Plus the requisite logic for loading order of interdependent project content. (di)
> 4. We define a package or component strategy/architecture built around
> projects. I haven't thought this through, but I really want to end up with
> stored projects that are loadable (ultimately fast with imageSegments), as we
> do now from BSS, but with dependence help from modules, and with name space
> help as well. di
I think we could profitably think of projects as managing "contents" (in the vein of "content provider" and such terms), i.e. objects that contain things that someone has created, note that this is a dimension most other languages don't deal with in the same manner, they leave it up to the programmer so to speak. But projects, publishing, the BSS and all of that are really quite well described as Squeak's vehicle for "content distribution".
This is versus modules as managing "programs" or code. I.e projects vs modules is contents vs. "just" code. And of course code may be a natural part of "contents", but programmers usually just produce "code".
> I think you are nearly there already, if we simply associate a module with a
> project, but I'd like to hear how you would do it. Something I'm not quite
> clear about is when one would want to distribute stuff as a project and when
> simply as a module.
I think the above distinction works here, Whisker, RefactoringBrowser, etc. are pure code. But when you would distribute content objects as well, that would be a project. It is a problem to use the term "Projects" like Squeak currently does (as "eToy kids' projects", cf. science projects) because it is such a generic term. I mean, also Whisker is certainly a project too in the usual sense.
So to call a piece of active content a Project is not very clear language. When I think about it, this can be defined as "the kind of thing Alan wants kids to create with their DynaBooks". So surely he must have thought about a name for this ;-). Or we should make him think about it now... it would be "good marketing" to use a term that clearly evokes its relation with DynaBooks here. Opus, Creation or Artwork (artifact?) were the best my thesaurus could come up with, a little too pompous all of them. Except perhaps Creation which could work.
Why am I rambling about this? Because if we can find a good term, then it will be clearer to us as well as to others how to think about Projects and how they should be implemented... hg
