Preserving simple hacking
Last updated at 3:09 am UTC on 22 April 2004
Whatever we do, it must not complicate things for the "weekend hacker".
This is my declaration, and I'm willing to be argued out of it. But here's an example: I would like to be able to write an unqualified global ref like a class name in some little piece of code, and have it work even if it should have a module prefix, provided the system can fund an unambiguous referent. Of course it would be nice if the system offered to add this automatically, but that's another consideration.
Similarly, if I've written a cool project in the old sloppy style, I'd like to be able to make it into a well-behaved package with almost push-button ease. (di)
I have a solution that seems to handle this in a simple way.
This would be to have a 'root' namespace (NS), which includes names from all spaces in the image. We could call it 'root', both because it allows access to everything like a Unix root account, and because it would be the 'root' of the whole NS hierarchy since everything branches out from it.
Within this NS, every name in the image can be ref'd (like you can ref everything today via #Smalltalk), so there everything would work like it does now. (But note that there would be problems with names used in more than one place.)
Moreover, we would associate each "Project" (in the meaning of a working area) with a certain NS, namely the module where you are implementing your application. The default for all projects would then be to simply use the root NS, and allow for free hacking.
We'd also scope tools (workspaces, browsers, etc.), so that they use a certain NS for name resolution. A Project would simply set the NS of new Workspaces and Browsers to the Project's NS. Since the default Project would use the root NS, Workspaces and Browsers would automatically give access to all names. (hg)
> I'm not clear how life in Squeak changes. For instance, for all the various
> ways that one may execute a piece of code, is there an associated module
> context? There must be; is it established at the project level? Or is it
> simply the global, root module level unless using special tools? (di)
I would say bind it at the project level, and by default bind projects to the root module. Tools would likewise bind to the project module, as a changeable default. This seems an optimal balance of flexibility and convenience. I should however look closer at just what a Project really does and is. hg