On 8 January 2014 20:16, Chris Muller <asqueaker at gmail.com> wrote:
>> That's pretty much the opposite of what I was saying.
>> #removeFromSystem: is something wired fairly deeply into the guts of
>> the system.
>
> Not very deep, and there aren't that many senders.  They could be
> changed to use the new #primRemoveFromSystem:; but how much would you
> like to bet they don't expect there to be subclasses.  IOW, eToys or
> Kedama generating classes dynamically, and then later removing those
> classes as part of an app function; they are not creating subclasses
> of *those*.  I don't think any sender of removeFromSystem: wants to
> keep subclasses.  If they do, I'll be interested to understand why.
>
> It's wrong to have a method which leaves the domain (in this case, the
> class model) in an invalid state be named what the first thought
> someone would have, looking for such API.  #removeFromSystem: is the
> correct name for the behavior users expect.  #prim is the appropriate
> prefix for the behavior users don't expect; that potentially leaves
> the domain in a partial or invalid state.  The #prim method should be
> private.

I can see your argument. I'm not 100% convinced yet, but perhaps my
hindbrain will be persuaded by the time we get to the start of 4.6.

>> But OK, try it out with unloading MC packages. Let's see
>> if it blows up. (I anticipate seeing a bunch of unexpected behaviour
>> resulting from MCClassDefinitions having their classes ripped out from
>> under them, and possibly weird behaviour from classes being #unload-ed
>> multiple times during the unload process.
>>
>> Specifically, given
>>
>> Object subclass: #Foo.
>> Foo subclass: #Bar.
>> Bar subclass: #Baz.
>
> Sure, please try it out and if anything blows up or is otherwise wrong
> in some way, we'll either fix or abandon this idea.
>
>> I expect to see Foo unloaded once, Bar unloaded twice, and Bax
>> unloaded three times. That does not seem right to me.
>
> I agree it would be wrong if it were true, but I'm not seeing how it
> is.  What do you mean "unloaded three times"?  Are you saying you
> think #unload will be called three times on Baz?  If that's true,
> you'll get no argument from me about that needing fixed.

I responded too quickly to the mail. You're right, the class won't
receive multiple #unload sends because of the guard. I still don't
like the multiple #removeFromSystem: calls subclasses would get during
package removal. Seems messy.

>> But I repeat: I think it's a great idea to have cmd-X say "yep, that
>> class is gone" and "oh hey, do you want to remove the class and all
>> these here subclasses?" (a bit like like removing a method does) in
>> the tools.
>
> There is already a short and sweet message warning about there being
> subclasses.  Your proposal to list every subclass would turn that into
> a large and elaborate confirmation pop-up.  It would be presenting
> information that was directly under it in the original
> HierarchyBrowser, and better viewed there anyway.  So, the user who
> didn't know what they're doing will most likely just press "No" and
> see it there.

My main concern is just someone doing something apparently innocuous,
and not realising they're about to obsolete half the classes in their
image. I don't seriously propose that anyone would cmd-X ProtoObject,
but think of that as the worst-case-taken-to-ridiculous-extremes
scenario,

> Pop-ups are evil.  Until we can eliminate them entirely, I prefer to
> keep them as low-profile as possible.

I _like_ the remove-selector popup, but then (a) "don't mode me in"
and (b) you're more experienced in the UX thing, so I'll accept this
:)

frank