>> Your version left just as many methods about author in Utilities as
>> mine.  We're not addressing that right now because we're moving
>> forward gently and incrementally.
>
> If you check those methods, all logic was removed from them, they just
> perform a send to Author. Btw there's a reason why I uploaded 2 packages.
> They have to be loaded one after the other. The first creates the Author and
> initializes the instance with the data from Utilities, the second updates
> the methods in Utilities, so the system will indirectly use Author. Loading
> this stuff in a single step might have unexpected side effects (e.g. loss of
> author information).
>
> I didn't remove the methods from Utilities because I want to deprecate them
> first, but before they are deprecated, the senders from the Trunk packages
> have to be rewritten. I didn't want to rewrite a bunch of methods while the
> API is not stable, because I'd have to keep rewriting those methods while
> the API is changing. And imagine what would have happened if I push 10+
> packages to the Inbox, noone would have taken the time to review them
> thoroughly, even these three seems to be too much.

Yip, I totally got that.

>> My main objection is popping Squeak UI-elements from directly within
>> the domain.  If you don't like Utilities to be the bridge between the
>> Squeak UI and the domain, we can address that next.  But that is
>> independent of having Author be a pure domain.
>
> I think the instance side is the domain, the class side has nothing to do
> with it.

That's fine -- I'm ok with Author *class* taking responsibility for
the initializing the global "current" Author of the System including
popping Squeak UI's to handle that initialization.  I'm not ok with
having that happen in the lazy-initters on the instance-side and then
asking outsiders who want to use the domain use PerSe accessors.

It seems like you're ok with my not-ok.  :)

> Utilities is an "enemy" of modularity, because it's a bunch of unrelated
> methods. I guess it started out as a class to hold utility methods. The
> problems started when they got senders from the image and the situation got
> worse when state was added to it.
>
> Every user of Utilities will depend on it's package and Utilities depend on
> everything it uses (a bunch of packages), so if you use only one thing from
> it (e.g. author information) then your package will depend on a bunch of
> other stuff totally unrelated to your package.

You don't need to defend this.  If I gave the impression that I wanted
to keep Utliities then I miscommunicated.  The remaining
author-methods are there only for the temporary-compatibility /
smooth-transition reasons you said above.  In the meantime I thought
we would consider Compiler or SmalltalkImage or Tools or some other
external manipulator but I agree Author class is just as good if not
the best choice.

>> There's also the notion of having multiple instances instead of the
>> global-variable approach -- are you ok with that?
>
> My original idea was to simply break out the author related stuff from
> Utilities into a single class. Since in the current system there's only a
> single author information maintained it was a straightforward idea to make
> Author a singleton. Colin proposed that multiple instances might be useful,
> though I still don't see any real world use cases for it, but I'm not
> against not overriding #new.

I understand you.  But cool, I'm glad you're ok with that.  I think we
do have a use-case today; "Change the current Author".  We've taken
the trouble to factor out a first-class Author so it's natural to want
to think of it in real-world terms.  Authors are people whose names
don't usually change so it feels like a... "violation" to do that
use-case by updating the inst-vars of the current Author.  Instead the
instance should be swapped and there's no reason to block #new.