Package naming Scheme

Currently pharo packages are named differently:

 - either "MyPackage" and "Tests-MyPackage" for the tests
 - or "MyPackage" and "MyPackage-Tests" for the tests
 - or something completely different like "GraphicsTests-Text"

First one is used more often but not very good when
using the "alphabetize" functionality in the context
menu of the standard browser ;)

Since the package naming scheme also affects
 - the monticello repo layouts
 - removal/shrink scripts (see ScriptLoader>>cleanupForProduction)
 - and method category names for extensions

we should agree on at least one to use.

Were the pros and cons of the different naming
schemes already discussed? If so is there any docu around?
I remember Lukas suggested to use the one from Seaside...

Thx
Torsten
--
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

El dom, 30-08-2009 a las 22:27 +0200, Torsten Bergmann escribió:
I vote for the Seaside convention, summarized on:

http://code.google.com/p/seaside/wiki/PackageNaming

At leas, in my projects is the one I use and it sorts correctly on the
package browsers and in the Monticello repos.


>
> Were the pros and cons of the different naming
> schemes already discussed? If so is there any docu around?
> I remember Lukas suggested to use the one from Seaside...
>
> Thx
> Torsten
--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Torsten

Yes, this has been discussed previously on this list. There were two  
main points of view:
- keeping all tests together in the same package as the classes they  
test
- packaging the tests in the package 'Tests' organized in  
subcategories Tests-A, Tests-B, etc.

The rationale for the latter is to be able to cleanly unload the tests  
when you don't need them (e.g., when you create an image for  
deployment).

Recently, I reorganized tests following the principle that all tests  
can be unloaded without making existing packages dirty. Therefore, the  
second case you describe below, 'MyPackage-Tests', does not exist  
anymore (with the exception of 'SUnit-Tests', which is ok) [1]. What I  
did is something in between the two solutions. In a further step we  
can merge packages like 'GraphicsTests' into 'Tests' (i.e., 'Tests-
Grapchics') where appropriate.

Adrian

[1] (TestCase allSubclasses collect: #category) asSet  
asSortedCollection explore


On Aug 30, 2009, at 22:27 , Torsten Bergmann wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project