[Pharo-dev] [Nautilus] Selecting package
roberto.minelli at usi.ch
Thu Dec 5 02:59:47 EST 2013
On Dec 5, 2013, at 8:31 AM, Stéphane Ducasse <stephane.ducasse at 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.
More information about the Pharo-dev