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.  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.


>
> 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.

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.

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




> frank
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131123/667528e2/attachment.htm