On Sun, 16 Sep 2012, Frank Shearar wrote:

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

Creating another instance is still possible (#shallowCopy), I wrote the 
tests that way, so they remain future proof in case someone adds more data 
to Author.


Levente

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