On 22.11.2013, at 11:58, Frank Shearar <frank.shearar at gmail.com> wrote:

> On 22 November 2013 10:09, Tobias Pape <Das.Linux at gmx.de> wrote:
>> On 22.11.2013, at 11:04, Frank Shearar <frank.shearar at gmail.com> wrote:
>> 
>>> On 22 November 2013 01:03, David T. Lewis <lewis at mail.msen.com> wrote:
>>>> On Fri, Nov 22, 2013 at 01:31:37AM +0100, Levente Uzonyi wrote:
>>>>> On Thu, 21 Nov 2013, Chris Muller wrote:
>>>>> 
>>>>> 
>>>>> It's generic, but the implementation is not generally useful.
>>>>> 
>>>> 
>>>> I don't see how the concept of a LRU cache is in any way related to Balloon.
>>>> It seems to me that if it is useful enough to be included in the system at
>>>> all, then it should live in a package category that reflects the actual meaning
>>>> of the class.
>>>> 
>>>> Suppose for the sake of argument that Balloon was being maintained as an
>>>> external package outside of the trunk image. Suppose also that an LRU cache
>>>> was something worth having in the trunk. What package would you put it in?
>>> 
>>> I would put it in its own package, called Cache. I anticipate heated
>>> discussion around yet another package with a single class.
>>> 
>>> But really, LRUCache is _not_ generic, because _noone uses it_.
>> 
>> Yea, that's why Seaside implements its own…
>> 
>> </sarcasm> <!-- sorry -->
> 
> Meh. The fundamental problem I'm trying to address is to tease these
> packages apart. If I make deliberate mistakes, and put LRUCache in
> Balloon only because that's the most basic user and doesn't add any
> additional dependencies, _that is a win_. It's one slightly less
> horrible dependency.
> 
> If someone else takes umbrage at such a ridiculous idea, and makes a
> new package, or puts it in Collections, _and doesn't add a new
> ridiculous dependency_, then that's even better.
> 
> No, LRUCache doesn't belong in Balloons. It may well be generally
> useful. But moving it there fixes a real problem. What I don't want is
> to be paralysed with discussions like "but this is not theoretically
> perfect!".

Yes, you are right there.
I would think, spinning of a new, small package would be a good compromise?

Best
	-Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1665 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131122/712fd8d7/signature.pgp