On 24 nov. 2009, at 18:17, Stéphane Ducasse wrote:
What is strange adrian is that before we did not
encounter this
problem in moose.
May be something changes and we did not notice it.
Keeping in line with the saying "to clean up your own back yard", I
think it's more related to a change in the Moose importer, especially
dealing with the package cache. I changed some parts of the package
importer in September (but it does not look to change this aspect to
me).
Now my memory is a bit fuzzy, so I cant track down at which point the
last Pharo import worked (this summer?)
Sorry, it's a bit off topic for the Pharo ML :)
Stef
On Nov 23, 2009, at 10:31 PM, Adrian Lienhard wrote:
Hi Simon,
There is no such method. But it would be easy to add (just send
"aPackage classes select: #isTrait"). The reason for returning traits
with the classes is that clients of PackageInfo typically expect
"compilation units", i.e., a collection including traits. The naming,
of course, is not optimal, and should be fixed in the long run. The
problem is to do so without breaking the clients of PackagInfo.
Cheers,
Adrian
On Nov 23, 2009, at 16:28 , Simon Denier wrote:
Hi there
When I run PackageInfo>>classes, I get both classes and traits
defined
in the package. So I can understand the need for a method retrieving
all 'compilation units' (or behaviors) from a package, but is
there no
method to just retrieve the regular classes? Especially since
there is
a #externalTraits method.
--
Simon
_______________________________________________
Pharo-project mailing list
Pharo-project(a)lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project(a)lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project(a)lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Simon