[squeak-dev] Extracing author information from Utilities
hannes.hirzel at gmail.com
Fri Sep 14 22:15:34 UTC 2012
On 9/14/12, Chris Muller <asqueaker at gmail.com> 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
>> 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
>> 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
>> which might be surprising.
>> Another idea is to not try to make the new implementation resemble the
>> 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?
More information about the Squeak-dev