Eliot We do not want to go the road of overrides. We want to keep our engineer task forces.
Stef On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda <eliot.mira...@gmail.com> wrote: > 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
