Ok, I just saw that Pharo has Collections-This and Collectoins-That. So I can understand why you said Collections-BTree fits right in nicely.
So maybe if Squeak renamed "Collections" similarly to what Pharo did, MC allows a dash in a package name and treats it as one unique name? On Tue, Mar 16, 2010 at 8:03 PM, Chris Muller <[email protected]> wrote: > -1 from me too about including it in Pharo or any other image. I don't > want to include BTree in any image. > > I was just asking about the naming. Since Squeak has a package called > Collections, loading BTree in Squeak makes that package dirty. > > Now, I agree there is a nostalgic element about that, and is the > original name that Avi gave it. However, I suspect the "Collections" > category of Squeak was there long before BTree came about. There > seems to be consensus that no one thinks BTree belongs in a base > image, and so it seems inappropriate to for an external package to > "invade" the namespace of such a general category, "Collections". > Perhaps, Avi wouldn't mind if the package were renamed to simply BTree > instead of Collections-BTree. > > I really think there are rewards to be harvested by our practicing > considerate collaboration and synergy between the communities. > > - Chris > > On Tue, Mar 16, 2010 at 3:27 PM, Stéphane Ducasse > <[email protected]> wrote: >> >> On Mar 16, 2010, at 7:16 PM, Chris Muller wrote: >> >>> Hi Lukas, are there plans to include BTree standard in the Pharo >>> image? I was just wondering whether that was why the package is named >>> Collections-BTree, or if you would renaming it to simply BTree. >>> >>> It's mostly intangible that I have a dirty Collections package in many >>> image (because I often use BTree). Except that, I do find myself >>> sometimes checking in Monticello, "did I change something in >>> Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this >>> list to be sure....." :) Kind of inconvenient, kind of inconsistent >>> for an external package. What do you think? >> >> MC is from time to time marking dirty packages are not. >> But in your case is it that? Or is there some methods compiled? >> >> For the inclusion into pharo here is my take: >> - if this is important for some internal applications we can >> the idea is that we copy but lukas keeps control and we merge from >> time to time >> as we do with gofer. >> >> - Now our goal is to make Pharo-Core smaller and smaller (but slowly) >> so probably BTree should not be in the core but it could be a package >> to load into >> the pharo (core + maintained by us package) or Pharo-dev (core+ >> maintainedby us + external). >> >> Now once we get a nice map of published packages for a release (aka >> universe browser) >> it should be easier for people to find/load.... packages. >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
