<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 27, 2014 at 5:48 AM, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
On 27.01.2014, at 14:34, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
<br>
> On 27 January 2014 13:25, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
>><br>
>> On 27.01.2014, at 14:17, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
>><br>
>>> On 27 January 2014 11:27, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
>>>><br>
>>>> On 27.01.2014, at 12:06, Stephan Eggermont <<a href="mailto:stephan@stack.nl">stephan@stack.nl</a>> wrote:<br>
>>>><br>
>>>>> Chris wrote:<br>
>>>>>> Each of my own application instances has its own SharedObjects<br>
>>>>>> container. It's just a simple wrapper of some IdentityDictionary's,<br>
>>>>>> one for Dates, one for literals (incl. Strings). This way, each<br>
>>>>>> object belongs in its own persistent domain, and remaining a String to<br>
>>>>>> avoid being forced to be shared across persistent domains.<br>
>>>>>><br>
>>>>>> We should not let any one app bloat the SymbolTable (which can slow<br>
>>>>>> down the system for ALL apps) merely for this purpose. If we want to<br>
>>>>>> address this data redundancy, we should do so explicitly in the app<br>
>>>>>> (MC). This is a recurring issue we should address it with a reusable<br>
>>>>>> first-class SharedObjectsContainer (or something else acceptable).<br>
>>>>><br>
>>>>> Ha, that’s the kind of comments I was hoping for. Thanks Tobias for<br>
>>>>> pushing this. An application specific value object cache makes sense.<br>
>>>>><br>
>>>>> Stephan<br>
>>>>><br>
>>>>><br>
>>>><br>
>>>> May we schedule this for 4.6?<br>
>>><br>
>>> Sounds like a good idea. Would you mind updating<br>
>>> <a href="http://wiki.squeak.org/squeak/6192" target="_blank">http://wiki.squeak.org/squeak/6192</a> accordingly?<br>
>><br>
>> Can I?<br>
><br>
> I'm confused: are you asking for permission? ("yes, of course, since<br>
> you're a member of the Squeak community, and the 4.6 list of requests<br>
> is for everyone") Or are you asking for the ability? (Because you<br>
> don't know the password.)<br>
<br>
</div></div>The latter :)<br>
<br>
Best<br>
<span class=""><font color="#888888"> -Tobias<br>
</font></span><br>
PS: I have up until now never used the swiki…<br>
Probably we should have a meta-4.6 todo for nicer swiki urls? ;)<br>
<br></blockquote><div>The SWIKI already does have a built-in better URL's. Unfortunately, they don't work with pages that have periods in them (that is, <a href="http://wiki.squeak.org/squeak/squeak4.6">http://wiki.squeak.org/squeak/squeak4.6</a> goes to the FunSqueak4.2Cog page, not really what is desired). The 'trick' is to lump all the works from the title together, with new words being capitalized. It does a scan (or sorts, obviously) to find the best match. My personal past with this is that I make several guesses about what will get a good result, and eventually one works fairly well.</div>
<div><br></div><div>-cbc</div></div><br></div></div>