When I mentioned Seaside I was not thinking explicitly in terms of Top- Purpose... What I like is that you have package but you have a kind of modules = object-oriented I would like to have Collections-Kernel Collections-Kernel-Tests Collections-Arrayed Collections-Arrayed-Tests Network-Kernel Network-Kernel-Tests ... So that I can get all the packages with their tests if I want. Also when I browse the package I see the tests and the other points grouped togethe
(Purpose-)Rest
where
Purpose = Tests, Examples, .. Rest = Kernel, Collections, Network, ...
Note that this is the *package* structure (what you see in MC), not the class category structure. The latter could be more fine grained at the lower level (e.g., Tools-Debugger, Tools-Inspector, ... as it is structured now).
The consequence would be that we have packages like
Kernel Collections Tools ... Tests-Kernel Tests-Collections Tests-Tools
I'm not convinced that this is the right structure, though, as we end up with lots of Test-xyz packages.
As an alternative, I can imagine the package scheme
Top-Rest
where we have a very coarse grained Top level. For instance, we would have the following Top items:
Kernel Graphics Libraries Tools Tests
This means, we would have packages like
Kernel-Numbers Kernel-Traits Kernel-Compiler ... Libraries-Collections Libraries-Regex Libraries-Network ... Tests-Kernel Tests-Libraries ...
I'm curious if there are other ideas around. One way or the other, we need to clean this up. Right now it is a mess. E.g., there is a top level package MethodFinder, while all other tools are in the Tools package.
INdEeD :)
Cheers, Adrian
stef
On Jan 31, 2009, at 10:51 AM, Stéphane Ducasse wrote:
I like the seaside organization
Top-(Purpose-)(Platform-)Rest
* Seaside-Canvas contains he canvas implementation. * Seaside-Squeak-Canvas contains the platform specific code of the canvas implementation. * Seaside-Examples-Canvas contains example code showing off the canvas implementation. * Seaside-Tests-Canvas contains the tests for the canvas implementation. * Seaside-Tests-Squeak-Canvas contains the platform specific tests of the canvas implementation.
On Jan 30, 2009, at 3:54 PM, Adrian Lienhard wrote:
On Jan 30, 2009, at 15:33 , Michael Rueger wrote:
Stéphane Ducasse wrote:
so what are the organizations we can use? Ideally I would like to have the test associated with their packages.
XXX XXXTests
The problem with that naming scheme is that then the tests would always be loaded together with their tests because of the simple string matching Monticello does. Which isn't something you want when doing application/runtime builds.
That's why I proposed the Plugin-* and Tests-* naming schemes.
+1
Adrian _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project