[squeak-dev] Extracing author information from Utilities

Colin Putney colin at wiresong.com
Sat Sep 15 05:40:22 UTC 2012


On Fri, Sep 14, 2012 at 9:13 PM, Levente Uzonyi <leves at elte.hu> wrote:


>> 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.
>
>
> That doesn't seem to be too hard to do by checking both the initials and
the
> name and ask for both one after the other if they are missing.

But remember, we'd be checking for the presence of an author object, and
creating one from scratch, rather than checking each field separately. So
we'd pretty much always have two dialogs in succession, which is a bit
awkward. I suppose we could do a single dialog with a template like:

    Author
        username: 'Your Name'
        initials: 'yn'.

That's how most other tools work.

I just think that if we continue to treat initials and name as separate
entities that can be set and queried independently, then there's not much
point doing the extraction at all. We're just changing where the globals
values are stored.

>>
>> 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
>> more.
>
>
> I wanted to separate Author from Utilities, but if we leave #authorName in
> utilities, then it won't happen in 4.4.

Oh wow, I didn't even know we *had* authorName in Utilities. In that case,
extracting it along with #authorInitials makes perfect sense. Strike my
suggestion.

> Pharo uses #fullName for what we use #initials for. If we don't want our
API
> to be compatible at this level, then we can use #fullName instead of
> #username.

Right, let's not introduce gratuitous incompatibility. How about
#properName?

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120914/b33cca30/attachment.htm


More information about the Squeak-dev mailing list