LRUCache to Balloon?
Locked
12
12
 
|
No, I don't think it's that rubbish. The categories are primarily for helping the user to classify/find things. So that would mean that packages have to divorce from categories, like the Pharo team did. I don't know, maybe it is necessary for proper packaging, but it's far from simple... This way you can load only some kernel collections. 2013/11/22 Frank Shearar <[hidden email]>
|
|
|
In reply to this post by David T. Lewis
Oups, I should have read all the answers before responding... 2013/11/22 David T. Lewis <[hidden email]>
|
|
|
In reply to this post by Chris Muller-4
On 22 November 2013 19:43, Chris Muller <[hidden email]> wrote:
> >> > 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 Three strikes & refactor is a great rule. And I'm happy for someone 6 months from now to go "what the hell, why did Frank put LRUCache into Balloon. It has the obviously right place <here>." But we've now expended more effort between 3+ people than would have taken for me to put LRUCache into Balloon AND pay for inventing the right place AND still have time left over for beer. >> > 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. >> >> No, I said that was a rubbish reason for grouping things together :) > > > What then? A separate package for every kind of Collection? I think we're both guilty of strawmanning each other :) No, of course not. Having each class in a separate package ruins the point of a package. I mean, it _packages_, so a package must _group_. For Collections, I want to push all the collections that Kernel uses - OrderedCollection, Array, ... - into Kernel. For any that are left, I don't particularly care, as long as they don't cause unnecessary coupling between packages. That shouldn't be a problem for Collections, except that Collections depends on System. But back to the point: LRUCache clearly doesn't belong to System. There's no obviously right place for it in any of the other packages. So we have a class that doesn't really belong to any other package. It's only used by Balloon and Morphic (and Morphic depends on Balloon). So we can * put LRUCache in Collections and hold our noses, or * put LRUCache in Balloon and hold our noses, or * put LRUCache in its own package, Caches, and hold our noses. frank |
|
|
Hi Frank, thanks for hanging in there -- this stuff sometimes requires patience to work through!
Frank, I'm not posing strawman arguments, at least not intentionally. The only thing you left me to work with was that organization along a particular semantic was "rubbish". I don't know how to make forward progress knowing only what you _don't_ like. Please tell me what you _like_. So I was just trying to ask, if not that, WHAT, should it be? Then way we can rave and critique about a particular vision, and move on it, or not.
Awesome, I agree with that! I think we'll also need Set and Dictionary (and their superclasses, of course). It doesn't bother me to have Collection defined in Kernel, and I think there's no choice.
don't particularly care, as long as they don't cause unnecessary
For me, it's always seemed obvious. The only raves/critiques in the whole thread I can find [1] related to putting it in Collections seem to amount to it not being useful enough, and yours that, viscerally, it doesn't feel right (which I don't understand).
But based on these facts -- - we have currently 2 users where merely 3 we agree to consider "useful"? - we have the option to integrate Seasides more-useful LRU Cache, which has just 7 methods instead of 3, would put us at 3 users.
- the idea that LRU Cache is a "holder of objects" with #at: access. No need to hold my nose.
That's why I support your option 1, Collections. I think it's the best fit both semantically and pragmatically. Note based on our plans, Kernel is an option too. But I still prefer Collections.
I totally respect the will of the community if you prefer a different package. I only implore we do not create a separate package for something we're all saying has little value.
Thanks, Chris [1] -- 1) > It's generic, but the implementation is not generally useful.
2) > But really, LRUCache is _not_ generic, because _noone uses it_. 3) > Yea, that's why Seaside implements its own… </sarcasm> <!-- sorry --> 4) > If someone else [...] makes a new package, or puts it in Collections, _and doesn't add a new ridiculous dependency_, then that's even better. 5) > the fact that Seaside needs an LRUCache shows that the _concept_ of an LRUCache is needed in at least 3 places.
6) > put LRUCache in Collections and hold our noses
|
|
|
On 23 November 2013 21:58, Chris Muller <[hidden email]> wrote:
> Hi Frank, thanks for hanging in there -- this stuff sometimes requires > patience to work through! > >> >> >> > 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. >> >> >> >> No, I said that was a rubbish reason for grouping things together :) >> > >> > >> > What then? A separate package for every kind of Collection? >> >> I think we're both guilty of strawmanning each other :) No, of course >> not. Having each class in a separate package ruins the point of a >> package. I mean, it _packages_, so a package must _group_. > > Frank, I'm not posing strawman arguments, at least not intentionally. I didn't mean the arguments :) I meant "Chris is the guy who hates small packages" and "Frank is the guy who just wants to rip everything apart". > The > only thing you left me to work with was that organization along a particular > semantic was "rubbish". I don't know how to make forward progress knowing > only what you _don't_ like. Please tell me what you _like_. So I was just > trying to ask, if not that, WHAT, should it be? Then way we can rave and > critique about a particular vision, and move on it, or not. I don't think that grouping collections together _just because_ they're collections isn't useful. I might invent some highly specific kind of collection suitable only for my needs: that should _not_ belong in Collections. >> For Collections, I want to push all the collections that Kernel uses - >> OrderedCollection, Array, ... - into Kernel. For any that are left, I > > > Awesome, I agree with that! I think we'll also need Set and Dictionary (and > their superclasses, of course). It doesn't bother me to have Collection > defined in Kernel, and I think there's no choice. OK, cool. This is the approach I think we should use - a package should serve a particular _function_. Just like a method or a class, a package should try to do just one thing. It's just that that one thing's at a larger scale. System (my favourite!) does _many_ large-scale things, which often aren't related other than being "infrastructure". Kernel ought to do one thing - "the smallest foundation on which we can build". ToolBuilder does one thing - provide a means for us to define UI elements. >> don't particularly care, as long as they don't cause unnecessary >> coupling between packages. That shouldn't be a problem for >> Collections, except that Collections depends on System. >> >> But back to the point: LRUCache clearly doesn't belong to System. >> There's no obviously right place for it in any of the other packages. >> >> >> So we have a class that doesn't really belong to any other package. >> It's only used by Balloon and Morphic (and Morphic depends on >> Balloon). So we can >> * put LRUCache in Collections and hold our noses, or >> * put LRUCache in Balloon and hold our noses, or >> * put LRUCache in its own package, Caches, and hold our noses. > > > For me, it's always seemed obvious. The only raves/critiques in the whole > thread I can find [1] related to putting it in Collections seem to amount to > it not being useful enough, and yours that, viscerally, it doesn't feel > right (which I don't understand). > > But based on these facts -- > > - we have currently 2 users where merely 3 we agree to consider "useful"? > - we have the option to integrate Seasides more-useful LRU Cache, which > has just 7 methods instead of 3, would put us at 3 users. > - the idea that LRU Cache is a "holder of objects" with #at: access. No > need to hold my nose. > > That's why I support your option 1, Collections. I think it's the best fit > both semantically and pragmatically. Note based on our plans, Kernel is an > option too. But I still prefer Collections. OK, I can live with it going into Collections. I don't think all of Collections will/should go into Kernel, so the "4.6 Collections" will be "Collection-y stuff that Kernel doesn't use". > I totally respect the will of the community if you prefer a different > package. I only implore we do not create a separate package for something > we're all saying has little value. I can agree with that last point. If it has so little value, why should it get an entire package all to itself? frank > Thanks, > Chris > > [1] -- > 1) > It's generic, but the implementation is not generally useful. > 2) > But really, LRUCache is _not_ generic, because _noone uses it_. > 3) > Yea, that's why Seaside implements its own… </sarcasm> <!-- sorry > --> > 4) > If someone else [...] makes a new package, or puts it in > Collections, _and doesn't add a new > ridiculous dependency_, then that's even better. > 5) > the fact that Seaside needs an LRUCache shows that the _concept_ of > an LRUCache is needed in at least 3 places. > 6) > put LRUCache in Collections and hold our noses > > > >> >> frank > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |