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.

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.

There's also the notion of having multiple instances instead of the
global-variable approach -- are you ok with that?



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
>