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:
>>>>>
>>>>> On Thu, Nov 21, 2013 at 4:51 PM, Frank Shearar <frank.shearar at gmail.com>
>>>>> wrote:
>>>>>> I'm sorely tempted to move LRUCache to Balloon. It's in System at the
>>>>>> moment, making Balloon depend on System.
>>>>
>>>>> LRUCache is generic, so how about Collections?
>>>>
>>>> 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!".

frank

> Best
>         -Tobias
>
>
>