I agree that packages should be promoted to real objects vs. the result of clever (ab)use of category names. That said, I frequently use a general-to-specific naming scheme for related classes on the grounds that it seems to help me when I get an alphabetical view of names. With that same logic, I suppose one could argue for just about any of the options described here :) Sorry.
In addition to reified packages, I would like to float the idea of allowing multiple method categories to apply to any given method. That has been very useful in Dolphin. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [EMAIL PROTECTED] Tel: (352) 273-6785 FAX: (352) 392-7029 >>> [EMAIL PROTECTED] 9/11/2008 3:09 AM >>> I understand the problem and I did not explain well but the solution of the Graphics package seems great : Graphics-Text Graphics-Files and GraphicsTests-Text GraphicsTests-Files Other packages like Graphics : CollectionTests-*, KernelTests-*, ... Packages with other naming conventions that do not seem great : File-Tests, Tests-*, Monticello-Tests Sure, a system that does not rely on string maching would be better. #Luc 2008/9/11 Stéphane Ducasse <[EMAIL PROTECTED]> > > On Sep 11, 2008, at 9:35 AM, Luc Fabresse wrote: > > the convention <category>Tests[<-subcategory>] seems great IMO. >> e.g. Graphics-Text -> GraphicsTests-Text >> >> With this naming pattern it is possible to have 2 monticello packages : >> <category> and <category>Tests >> And it is possible to not load Tests packages in a deployed image. >> > > Yes it does not work if Graphics is composed of several subpackages > > With this I cannot have > > Collections-OrderedCollection > and > Collections-OrderedCollection-Tests > > separated from > > Collections-Set > and > Collections-Set-Tests > > For me I want to have packages that I can load independently and the tests > should be attached to the package (to be eventually not load with it). > >> >> > I really hate the fact that we feel everywhere category and string > matching. > > Stef > > > >> Luc >> >> 2008/9/11 Alexandre Bergel <[EMAIL PROTECTED]> >> Having a package name without any - will prevent Monticello from being >> confuse on some point. >> Stef and I already experienced that... >> >> I was never happy in inserting a - in a package name. >> >> Alexandre >> >> >> >> On 11 Sep 2008, at 07:23, Damien Cassou wrote: >> >> On Wed, Sep 10, 2008 at 9:32 PM, Stéphane Ducasse >> <[EMAIL PROTECTED]> wrote: >> Hi >> >> I noticed that we have CollectionsTests-Ordered >> kind of package name and I would prefer to get Collections-Ordered-Tests >> What do you think. I bit of regularity would help. >> >> Collections-Test-* categories belong to the Collections-Test package >> on monticello. If you rename it to Collections-Ordered-Tests, you will >> put everything in the Collections package (because there is no >> Collections-Ordered monticello package). >> >> >> -- >> Damien Cassou >> Peter von der Ahé: «I'm beginning to see why Gilad wished us good >> luck». (http://blogs.sun.com/ahe/entry/override_snafu) >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
