Hi Sean, On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <s...@clipperadams.com> wrote:
> Stephane Ducasse-3 wrote > > You see. You pushed this idea and at then end we will have to handle the > > mess. > > I do not see why we cannot simply support *. > > I'm surprised by this resistance. The *Xyz was always an ugly hack, part of > Squeak's overloading the same mechanism for both system categorization and > packaging, and exposing and limiting protocols as "just dumb strings", all > of which IMHO makes the system much less understandable (no real "private" > tagging, extension methods can't show up in proper protocol, etc). We're > not > in a feature freeze, so what is the problem with tackling part of this mess > now? Sure, maybe the UI support can be improved, but let's focus on some > concrete suggestions. > > Denis and I just happened to be talking about this larger issue the other > day. Here are a few snippets I dug up during that conversations of some of > my many posts about this over the years… > > > we have overloaded system categories to package code for SCM. System > > categories should be tags (preferably multiple allowed) > > which offer a logical view of the system. Packages, the POV we show now, > > are orthogonal and much less useful for users. > (edited) > and another: > > I feel more and more that the standard "Package" pane is only useful > > for... packaging, and when one takes off the dependency management hat > and > > puts the user hat on (i.e. most of the time), what you really want there > > is a logical view of the system. So I see three use cases: > - Logical view of the system - I guess this was the original intention of > Categories, but has been hijacked by Monticello > - By project - which, as you just showed, we have now, yay! > - By package - the least useful, but primary (up til now), view > (edited) > and regarding Nautilus' tree package pane (when it first arrived): > I noticed that right now, separate packages within the same project are not > collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will > be siblings in the tree, instead of both under MyProject. It seems like it > would be more useful to have > - MyProject > - Core > - Platform > in the tree > If you and Denis are "going radical" and going to do the right thing then please also give thought to overrides and unloading. Allowing a package to override a set of methods on load is a useful facility, fraught with difficulties (being able to browse the overridden versions being the main one). Having things organized so that the overridden versions are saved, don't get lost when source is rewritten, etc, etc (made much easier by keeping source in methods), but most importantly, get restored in the right order when packages are unloaded. I believe it's as simple as associating the methods that are overridden with the packages to which they belong, and maintaining a load order (so that if PkgA B & C implement C>>foo, and are loaded in the order A, B, C, then we can compute easily that unloading C restores PkgB's C>>foo, and that unloading B does not affect C>>foo). > > > it seems that the tree is primarily about chunking information into > > manageable pieces. > > A primary difficulty here is that packages are often divided for reasons > that have nothing to do with the domain model, e.g. the ubiquitous > MyPackage-Platform, which is an artifact of Metacello that is not all that > relevant to a user wanting to understand the system. > > From the naive user perspective, if I'm exploring from the top level of the > system, I want to see things like: > - CodeImport > - Collections > - Compiler > > From this perspective, the 14 entries for Collections, multiplied by a few > dozen top-level categories make the list unwieldy and only marginally less > daunting than the flattened list we used to have (see > http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two ) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- _,,,^..^,,,_ best, Eliot
