On 22 November 2013 16:37, Chris Muller ma.chris.m@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@gmail.com wrote:
On 21 November 2013 23:05, Chris Muller asqueaker@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@gmail.com wrote:
On 21 November 2013 21:20, commits@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