April 12, 2018
9:17 p.m.
Hi Stephane, On Thu, Apr 12, 2018 at 11:46 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote: > Eliot > > We do not want to go the road of overrides. We want to keep our > engineer task forces. > There are overrides anyway. In general overrides are unavoidable in some circumstances. The issue is not whether they exist, it's whether they work reliably. Right now they don't; they rely on changes file technology that is extremely fragile. Sean and Denis' move to reimplement extensions is an opportunity to implement overrides correctly. > > Stef > > On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda <eliot.miranda@gmail.com> > wrote: > > Hi Sean, > > > > On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <sean@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 > > -- _,,,^..^,,,_ best, Eliot