On 22 November 2013 16:37, Chris Muller <ma.chris.m at gmail.com> wrote:
> We're talking about two things here.  1) Whittling Utilities down by
> removing AuthorInitials and AuthorName so Utilities can approach it's
> demise.  We all agree on this.
>
> And, 2) Where to put them.
>
> Given Levente's reminder that we do in fact, have TWO fields, not just one,
> I suppose that pushes me over the edge from Smalltalk authorInitials to a
> new SystemAuthor singleton afterall.  I wouldn't want to have Smalltalk
> authorInitials AND Smalltalk authorName.
>
> WAIT!  Let's consider one final option.  *Removal* of authorName.  When I
> look at senders I see users that are mostly app-specific.  Etoys, saving a
> TextStyle or Postscript object...  That seems pretty weak to me for
> inclusion in a core image plus the introduction of a new SystemAuthor class.
>
> What do you guys think?

I would not cry if we removed authorName, or made it simply an alias
for authorInitials. I do want it a separate class though, because it's
a separate entity. It's not just a string, after all: it's a string
with setup logic, and asking the user for stuff. I've made classes for
less than that, many times.

frank

> On Fri, Nov 22, 2013 at 10:09 AM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
>>
>> On 21 November 2013 23:05, Chris Muller <asqueaker at gmail.com> wrote:
>> > Back when Levente approached this, we had a detailed discussion about
>> > it.  I think we should all go back and read that before introducing a
>> > SystemAuthor class.
>> >
>> > Personally, I wouldn't mind just having
>> >
>> >    Smalltalk authorInitials  "answers a String"
>> >
>> > until we decide we need to support multiple concurrent Author objects
>> > with more than just name and initials..
>> >
>> > And this makes sense anyway -- Smalltalk's current #author.
>> >
>> > I struggle with having a whole class (SystemAuthor) when we cannot
>> > take proper advantage of it and only really need one String field at
>> > this time, not a heavy-weight, value-holder singleton.
>>
>> We cannot take proper advantage of it because it doesn't exist yet :)
>>
>> I'd rather waste an entire class and kill Utilities, than have
>> Utilities continually stick a spanner in the more important objective
>> of modularity.
>>
>> First Utilities, then the world!
>>
>> frank
>>
>> > On Thu, Nov 21, 2013 at 4:33 PM, Frank Shearar <frank.shearar at gmail.com>
>> > wrote:
>> >> On 21 November 2013 21:20,  <commits at source.squeak.org> wrote:
>> >>> Frank Shearar uploaded a new version of MonticelloConfigurations to
>> >>> project The Trunk:
>> >>> http://source.squeak.org/trunk/MonticelloConfigurations-fbs.118.mcz
>> >>>
>> >>> ==================== Summary ====================
>> >>>
>> >>> Name: MonticelloConfigurations-fbs.118
>> >>> Author: fbs
>> >>> Time: 21 November 2013, 9:20:19.085 pm
>> >>> UUID: aaba44a1-8cfd-4147-8d94-69d5fc5ac571
>> >>> Ancestors: MonticelloConfigurations-cmm.117
>> >>>
>> >>> Move the #upgradeIsMerge preference to MCConfiguration.
>> >>>
>> >>> =============== Diff against MonticelloConfigurations-cmm.117
>> >>> ===============
>> >>
>> >> Just by the way, MonticelloConfigurations depends on System for one
>> >> thing only now: Utilities' author stuff. I'm knocking up a completely
>> >> lame minimal mimic-existing-stuff SystemAuthor that I will hopefully
>> >> finish tomorrow. I plan to sever this dependency, and then remove all
>> >> the references to Utilities authorName/Initials with SystemAuthor
>> >> current, and then we can think about any other stuff we might do with
>> >> this.
>> >>
>> >> frank