> 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.
