goran.hultgren@bluefish.se wrote:
Projects vs Modules
I have read the stuff on the Swiki and my naive view is this:
A Module is a published piece of code.
Right, an abstract (piece of a) program with no reference whatsoever to how it is represented, run, or anything. Effectively a sort-of-mathematical abstraction.
It is not a "binary deliverable". But you can download/load/activate them in your environment. I think it is good that they are not binary and I think it would be much harder to build such a system with the functionality that Henrik have put in there if they were binary. Being non binary also makes it possible to manipulate these things more easily. On the other hand the repository is a pluggable component so that we can have different kinds of repositorys. For example, we could have a repository implementation that uses ImageSegments or something to increase loading speed.
A Project is more of a published binary deliverable. It surely can/could contain one or more modules but it also contains live instances etc. It is in my eyes analogous to the "binary download" you see everywhere on the Internet - just click and go. Typically not used by developers when they need a module to use in their own project but more for Squeak endusers "surfing for content".
I would like to distinguish Projects from Components--a Component is a concrete representation of the code in a Module, that can be dynamically loaded and unloaded. (Components also imply dynamic hook-up and such, which is a much smaller problem in Smalltalk than in e.g. C++, which has no standard representation for program meta-objects. Smalltalk already has all/most of that.) So a Component = a Module or Modules as concretely represented in Squeak (class and compiledmethod objects, etc.).
A Project is more than just this.
A Project is more of a published binary deliverable. It surely can/could contain one or more modules but it also contains live instances etc.
I assume what you read was http://minnow.cc.gatech.edu/squeak/2058.
Importantly, Projects have contents, as in "content provider", not just code (but it may contain code). This is what you call live instances, and I think this is the essential difference between Projects and Components.
What projects really are today is kind of vague, but the best notion I've been able to come up with is "the kind of thing Alan wants kids to create with their DynaBooks". But Alan/SqC also seems to have frequently changed their mind about^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H refined the notion of what Projects are.
I proposed Creation as the best name I could come up with instead of Project, which is extraordinarily vague and generic for such a specific use, and gives poor hints to what this "thing" is and does. A Creation is a collection of "hand-made" objects that someone has created (with a nod to Koestler with the colored planes). See the above page for a discussion of this.
As I see it, as concepts, Components are layered on top of/incorporate Modules, and Creations extend Components to include hand-made objects. Eventually.
_____ a Creation ( ) ¨¨|¨¨ _____ Components ( ) * (0 or more) ¨¨|¨¨ _____ Module(s) ( ) + (1 or more) ¨¨¨¨¨
Example:
I write a cool Morphic game including classes for general animation. The code is composed of a Module representing the Game itself with 2 more general submodules for Animation and Sound. They are not really blessed to go into the "base image" so I put everything in "People/gh/CoolGame". Ok, I upload it all onto the virtual module server (more on that later) so that people easily can load this module.
Yes, this is enough if all your objects can be programmatically generated by your code.
But I also set up a Project where I start the Game up with a centered window and I also type in a todo-list in an open Workspace. Finally I smack in a nice looking background image and then publish the Project onto Bobs superswiki AND also to another superswiki in Sweden containing only Morphic games (just fantasy).
These are "hand-made" (ie. non-programmatically generated) objects, which code isn't sufficient for creating (without taking extreme measures). At least code isn't convenient for creating them. You need the ability to conveniently (distribute and) load _objects_. This is the added role I assign to Creations. I think Creation also implies this having to do with "hand-made" objects (vs. code-generated).
So, developers typically load the module to get to the code and perhaps reuse my Animation module or just check out how the game was done.
Right, just to get the code, Modules are enough. Components/image segments may be convenient (think the 1MB refactoring browser).
End users typically find the project and loads that - it probably is faster and they get a "just point and click" experience. They get the modules with the project, but that is just a bonus.
Right, this to get the non-code objects too.
In general, I think Repositories should be a general facility for conveniently storing and accessing anything Squeak-related, including e.g. Projects/Creations, so that you can just give a path to a Project, or help pages, or you personal preferences file, or whatever, and Squeak will be able to locate the files for you.
regards, Göran
So what we really need is for SqC to agree with this ;-)
Henrik