> 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.
>

"Separate entity", alone, is not enough.  I used to develop code this way;
"ultimate objects" that matched the real-life semantic structure.

So if I had a Person object with a 'name', I would *never even consider"
letting its 'name' be a simple String, it had to be a first-class Name
object with #first, #middle, #last, and printing methods, etc.

Then, one day, I found myself with all of this "stuff" that wasn't really
needed.  More methods, more classes, more concepts, more layers, more reads
by the database.  NONE of which, is truly needed.  It was "heavyweight"
instead of TSTTCPW.

Since then, I've realized, it's perfectly fine to not have a first-class
object if all you need is a String.




>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131122/7c3683d6/attachment.htm