We do not want to go the road of overrides. We want to keep our
engineer task forces.


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

Reply via email to