Hi Stef, I spoke with Esteban before, however thanks for the clarification. IMHO however the current structure is confusing, and names are misleading. The thing about packages, categories, namespaces and what not has always been not perfect for me, nor in Pharo nor in many other PLs. The way I would have done it, conceptually, independently of Nautilus, Monticello and whatever else is the following: A package is a container used to structure a project, it contains - zero or more classes - zero or more other packages This model would be damn simple, and consistent and you should not explicitly think about how to structure your things.. I can create a package ‘DFlow’ put some classes, then I create another package 'DFlow-Core’ which *automatically* goes into the ‘DFlow’ package because it starts with the same prefix plus the dash, which is somewhat our convention, right? And however we can think of mechanisms to cope with other kind of automatic sub-packaging and/or manual removal (in case our heuristics fail). For me having packages, groups, tags, and categories is too much. Cheers, R On Dec 4, 2013, at 6:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

On Dec 4, 2013, at 4:10 PM, Roberto Minelli <roberto.minelli@usi.ch> wrote:

...

Hi guys,

I recently moved my tool to Pharo 3 and I am experiencing problems with the Nautilus.

Long story sort: Why the argument of Nautilus>>#selectedPackage: aPackage is *not* a package but some weird PackageTreeSelection or subclass of it?

I guess that if you would get simply the rpackage ie the model you would be in trouble if you want to do some ui stuff with the representation of the package. Now if you have a PackageTreeSelection then you can dispatch to the selection and avoid ifs and crawling from rpackage to nautilus.

So have a look at the code it should not be that complex and last time I looked at the code when esteban was writing it, it looks good to me. Less tests, more dispatch.

...

I don’t followed (unfortunately) the evolution of the PackageTreeModel in general.. so I don’t really know how to proceed.. In the end I’ll need the RPackage of the PackageTreeSelection…

Another question: what is a RPackageTag?

Packages contain tag for classes (like old categories but per packages)

...

I am confused.

Cheers and thanks in advance for any answer, R

Hi Stef, On Dec 5, 2013, at 8:31 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

Hi Stef,

I spoke with Esteban before, however thanks for the clarification.

IMHO however the current structure is confusing, and names are misleading. The thing about packages, categories, namespaces and what not has always been not perfect for me, nor in Pharo nor in many other PLs.

The way I would have done it, conceptually, independently of Nautilus, Monticello and whatever else is the following:

A package is a container used to structure a project, it contains - zero or more classes - zero or more other packages

this is the world of "bisounours" welcome to reality.

...

This model would be damn simple, and consistent

and not covering what we want :)

Well, then I do not understand what you want ;) The to models are equivalent in “power"..

...

and you should not explicitly think about how to structure your things.. I can create a package ‘DFlow’ put some classes, then I create another package 'DFlow-Core’ which *automatically* goes into the ‘DFlow’ package because it starts with the same prefix plus the dash,

we do not want to rely on naming conventions. Now this has been discussed during a couple of years. so look for it and esteban spent 5 months on it so do you think that it was that simple?

I never said it is simple. Namespaces, packages & co. is something that no PL has ever solved in a perfect way.

...

which is somewhat our convention, right? And however we can think of mechanisms to cope with other kind of automatic sub-packaging and/or manual removal (in case our heuristics fail).

I can think to a lot of nice solutions but after you should have solutions - scale - migrate - fit people practices

...

For me having packages, groups, tags, and categories is too much.

We are killing categories and I would have removed it completely (not having tags) but people and practice showed that they were needed Then groups is just so handy I use that all the time. Then I do not understand why you bother. The point is that each of these objects should reply polymorphically to the same message probably allClasses, extensions, … if this is not the case then this is also easy we should add these messages.

If you do not have specific entities you are forced to have conditionals and it starts to get ugy and not modular so I do not see your problems.

I am not saying the implementation is not clean or it is implemented in a bad way. I am saying that I *personally* do not like this design.

OO design is your friend but it requires time to deeply understand it.

It’s not about understanding the OO design. It’s clear what you guys did and implemented. The thing that bugs me is the “conceptual model” behind the OO-design. Cheers, R