Hi Stephane,

On Thu, Apr 12, 2018 at 11:46 AM, Stephane Ducasse <stepharo.s...@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.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
>
>


-- 
_,,,^..^,,,_
best, Eliot

Reply via email to