On Sat, 15 Sep 2012, Chris Muller wrote:

> 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.

>
> 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.

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.

>
> 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.


Levente

>
>
>
> On Fri, Sep 14, 2012 at 10:41 PM, Levente Uzonyi <leves at elte.hu> wrote:
>> On Fri, 14 Sep 2012, Chris Muller wrote:
>>
>>> Hi guys!  Levente, thanks for pushing this forward!
>>>
>>>> My feeling is that "Author current" should be the only place where we
>>>> lazily initialize by asking the user. Then Author>>initials would just
>>>> be a normal accessor, and Author class>>initials would go through
>>>> #current. The tricky bit with that idea is that we'd need a slightly
>>>> more elaborate UI, so let the user fill in both initials and username.
>>>>
>>>> One idea would be to get rid of #username for now, and have Author
>>>> objects with just initials. Then in 4.5 we we'd flesh things out a bit
>>>> more.
>>>
>>>
>>>> The way these methods behave is similar to how Utilities works. The
>>>> *PerSe
>>>> methods are just simple accessors and the accessor looking methods ensure
>>>> that they are initialized.
>>>>
>>>> What about removing the *PerSe methods from the instance side and update
>>>> boths sides so that only the class side accessor looking methods request
>>>> the
>>>> initialization of the data? E.g.:
>>>>
>>>> Author initials. "this will request the initials if they are not set"
>>>> Author current initials. "just returns the initials"
>>>> Author initialsPerSe. "just returns the initials"
>>>> Author current intialsPerSe "MNU"
>>>>
>>>> This would make the behavior of the instance and the class side
>>>> different,
>>>> which might be surprising.
>>>>
>>>> Another idea is to not try to make the new implementation resemble the
>>>> old
>>>> one, just ensure the compatibility via the methods in Utilities.
>>>
>>>
>>> Say, would y'all mind if we think of Author as a *pure domain object*
>>> and NOT couple any Squeak-specific UI behaviors to it whatsoever?  We
>>> all know doing that is bad practice so how about letting Utilities
>>> take responsibility for ensuring a there is a well-formed "current
>>> Author".
>>>
>>> That frees Author to just "be" a simple and regular kind object of
>>> which there can be multiple instances.  Its just that the "current"
>>> one is the one which the rest of the system recognizes as the one
>>> authoring (saving code, etc).
>>>
>>> Real people's names don't usually change, so let's not treat "Author
>>> current" like a global variable and temporarily maul someone's name
>>> just to accomodate some test process.  Besides, then we'd have to
>>> worry about Mutexes and multi-process updating, etc..
>>>
>>> I submitted an update to the inbox that takes this tact.  With this,
>>> applications that are ok to be integrated with Squeak UI elements can
>>> use:
>>>
>>>   Utilities authorInitials
>>>
>>> and it will make sure the Author current initials is set.  Meanwhile,
>>> applications that just want to access the current value and possibly
>>> set it in their own way can simply check
>>>
>>>  Author current initials
>>>
>>> and take action in their own way if they want.
>>>
>>> What do you think?
>>>
>>>
>>
>> I don't like the idea to keep methods about author in Utilities. My plan
>> is/was to rewrite all users in the image when the Author implementation is
>> there and deprecate all author related methods in Utilities.
>> So IMHO the class side of Author is a much better place for those methods.
>>
>>
>> Levente
>>
>