I ask you not to put this into trunk.  I actually have recent
experience with this exact issue.  Let me explain.

So, Monticello is not the only application to have lots and lots of
redundant String instances.  MANY applications have that.  And MC also
has lots of redundant Date instances (one per VersionInfo), as do many
other apps.  And sometimes lots of redundant Float instances (i.e.,
0.0, 1.0, and 100.0 often will have lots of instances).  So slamming
application-specific Strings into the SymbolTable does not solve the
overarching problem while at the same time raising several new
(non-obvious) issues of its own.

One issue relates whether the app will ever want to scale into a
database.  When an object is retrieved from a database, that object is
associated with a particular DB Session, by identity.  But persistent
Symbol objects, by their nature, cannot be associated to only one
Session, because there can only be one in the image.

The Monticello application is _already_ scaled into a database, Magma.

Each of my own application instances has its own SharedObjects
container.  It's just a simple wrapper of some IdentityDictionary's,
one for Dates, one for literals (incl. Strings).  This way, each
object belongs in its own persistent domain, and remaining a String to
avoid being forced to be shared across persistent domains.

We should not let any one app bloat the SymbolTable (which can slow
down the system for ALL apps) merely for this purpose.  If we want to
address this data redundancy, we should do so explicitly in the app
(MC).  This is a recurring issue we should address it with a reusable
first-class SharedObjectsContainer (or something else acceptable).

Thanks.

On Sun, Jan 26, 2014 at 11:06 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>
> On 26.01.2014, at 18:00, Chris Muller <asqueaker at gmail.com> wrote:
>
>> Symbols are one way to canonicalize Strings.  Another way is to
>> introduce one's own canoncalized IdentityDictionary of author strings.
>>
>> Whenever a Symbol is not going to be a selector name, I tend to prefer
>> the latter.
>
> Why?
>
>
>