LRUCache to Balloon?

> I'm sorely tempted to move LRUCache to Balloon. It's in System at the
> moment, making Balloon depend on System.
>
> Doing so would make Balloon not depend on System anymore. The other
> user of LRUCache is ScrollBar, which is in Morphic. Morphic already
> depends on Balloon, so nothing happens.
>
> In short: this
> * moves LRUCache closer to one of its two users
> * breaks a needless dependency
>
> Thoughts?
>
> frank
>

>
> On Thu, Nov 21, 2013 at 4:51 PM, Frank Shearar <[hidden email]> wrote:
>> I'm sorely tempted to move LRUCache to Balloon. It's in System at the
>> moment, making Balloon depend on System.
>>
>> Doing so would make Balloon not depend on System anymore. The other
>> user of LRUCache is ScrollBar, which is in Morphic. Morphic already
>> depends on Balloon, so nothing happens.
>>
>> In short: this
>> * moves LRUCache closer to one of its two users
>> * breaks a needless dependency
>>
>> Thoughts?
>>
>> frank
>>
>
>

> On Thu, 21 Nov 2013, Chris Muller wrote:
> >
> >On Thu, Nov 21, 2013 at 4:51 PM, Frank Shearar <[hidden email]>
> >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.
>

> 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 <[hidden email]>
>> >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?

> On 22.11.2013, at 11:04, Frank Shearar <[hidden email]> wrote:
>
>> On 22 November 2013 01:03, David T. Lewis <[hidden email]> 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 <[hidden email]>
>>>>> 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 -->

> On 22.11.2013, at 11:58, Frank Shearar <[hidden email]> wrote:
>
>> On 22 November 2013 10:09, Tobias Pape <[hidden email]> wrote:
>>> On 22.11.2013, at 11:04, Frank Shearar <[hidden email]> wrote:
>>>
>>>> On 22 November 2013 01:03, David T. Lewis <[hidden email]> 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
>
>
>

> On 22 November 2013 10:09, Tobias Pape <[hidden email]> wrote:
>> On 22.11.2013, at 11:04, Frank Shearar <[hidden email]> wrote:
>>
>>> On 22 November 2013 01:03, David T. Lewis <[hidden email]> 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 <[hidden email]>
>>>>>> 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
>>
>>
>>
>

> You said there are already two places where it's used, right?  If
> there's even just ONE MORE place that pops up, we'll find that clearly
> Balloon (WTH?) is the wrong place for it.
>
>    http://www.codinghorror.com/blog/2013/07/rule-of-three.html
>
> I think you should stay consistent in your statements about
> "modularity."  It wraps a Dictionary, it supplies #at: for access.
> You said if it walks and quacks like a collection, it goes in
> Collections.
>
>
>
> On Fri, Nov 22, 2013 at 4:58 AM, Frank Shearar <[hidden email]> wrote:
>> On 22 November 2013 10:09, Tobias Pape <[hidden email]> wrote:
>>> On 22.11.2013, at 11:04, Frank Shearar <[hidden email]> wrote:
>>>
>>>> On 22 November 2013 01:03, David T. Lewis <[hidden email]> 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 <[hidden email]>
>>>>>>> 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
>>>
>>>
>>>
>>

> You said there are already two places where it's used, right?  If
> there's even just ONE MORE place that pops up, we'll find that clearly
> Balloon (WTH?) is the wrong place for it.
>
>   http://www.codinghorror.com/blog/2013/07/rule-of-three.html
>
> I think you should stay consistent in your statements about
> "modularity."  It wraps a Dictionary, it supplies #at: for access.
> You said if it walks and quacks like a collection, it goes in
> Collections.

> On Fri, Nov 22, 2013 at 4:58 AM, Frank Shearar <[hidden email]> wrote:
>> On 22 November 2013 10:09, Tobias Pape <[hidden email]> wrote:
>>> On 22.11.2013, at 11:04, Frank Shearar <[hidden email]> wrote:
>>>
>>>> On 22 November 2013 01:03, David T. Lewis <[hidden email]> 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 <[hidden email]>
>>>>>>> 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
>>>
>>>
>>>
>>
>

> On Fri, Nov 22, 2013 at 10:33 AM, Tobias Pape <[hidden email]> wrote:
>> On 22.11.2013, at 11:58, Frank Shearar <[hidden email]> wrote:
>>
>>> On 22 November 2013 10:09, Tobias Pape <[hidden email]> wrote:
>>>> On 22.11.2013, at 11:04, Frank Shearar <[hidden email]> wrote:
>>>>
>>>>> On 22 November 2013 01:03, David T. Lewis <[hidden email]> 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
>>
>>
>>
>

>> On 22 Nov 2013, at 16:58, Chris Muller <[hidden email]> wrote:
>>
>>>> Yes, you are right there.
>>>> I would think, spinning of a new, small package would be a good
>>>> compromise?
>>>
>>> For THREE METHODS?  My God, PLEASE, no!
>>
>> Bingo! :) But seriously, why do you even care about the number of
> packages in the image?
>>
>
> Because package categories exist for the benefit of human beings who want
> to be able to read and understand the system.

> On 22 November 2013 18:34, David T. Lewis <[hidden email]> wrote:
>>> On 22 Nov 2013, at 16:58, Chris Muller <[hidden email]> wrote:
>>>
>>>>> Yes, you are right there.
>>>>> I would think, spinning of a new, small package would be a good
>>>>> compromise?
>>>>
>>>> For THREE METHODS?  My God, PLEASE, no!
>>>
>>> Bingo! :) But seriously, why do you even care about the number of
>> packages in the image?
>>>
>>
>> Because package categories exist for the benefit of human beings who want
>> to be able to read and understand the system.
>
> Yes. And those names won't change, so..... ? You'd have as many
> packages as you do system categories, if you broken every package up
> right now into its hierarchically named parts.
>
> But also if it ever arises that we really need a decent library of
> various kinds of caches - Clojure has a _very_ nice way of expressing
> various kinds of caches by composing different properties - we'll have
> the perfect package for it. In that far distint time no-one will even
> remember the day that Cache had a single, lonely class.
>
> I would rather we put LRUCache into a _less bad_ package - Balloon -
> than a _bad_ package like System.

> On 22 November 2013 18:34, David T. Lewis <[hidden email]> wrote:
>>> On 22 Nov 2013, at 16:58, Chris Muller <[hidden email]> wrote:
>>>
>>>>> Yes, you are right there.
>>>>> I would think, spinning of a new, small package would be a good
>>>>> compromise?
>>>>
>>>> For THREE METHODS?  My God, PLEASE, no!
>>>
>>> Bingo! :) But seriously, why do you even care about the number of
>> packages in the image?
>>>
>>
>> Because package categories exist for the benefit of human beings who want
>> to be able to read and understand the system.
>
> Yes. And those names won't change, so..... ? You'd have as many
> packages as you do system categories, if you broken every package up
> right now into its hierarchically named parts.
>
> But also if it ever arises that we really need a decent library of
> various kinds of caches - Clojure has a _very_ nice way of expressing
> various kinds of caches by composing different properties - we'll have
> the perfect package for it. In that far distint time no-one will even
> remember the day that Cache had a single, lonely class.