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 :)
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?
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. OO design is your friend but it requires time to deeply understand it.