[squeak-dev] Extracing author information from Utilities
leves at elte.hu
Sat Sep 15 03:41:10 UTC 2012
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
>> 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
> 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
> 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
More information about the Squeak-dev