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