On 26 January 2014 23:45, Chris Muller <asqueaker at gmail.com> wrote:
> 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.

In other words, if an app has a problem with lots of "duplicate" value
objects, it ought to have its own cache of these value objects. I
think that's sound.

frank

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