On 16 September 2012 02:19, Levente Uzonyi <leves at elte.hu> wrote:
> 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.

Testing that an author's name is correctly added when saving a method
sounds like a good case for allowing multiple instances. (Or more
generally, any kind of test around recording authorship.)

frank

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