Hi Stef, On Dec 5, 2013, at 8:31 AM, Stéphane Ducasse <[email protected]> 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
