BTree packaging

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

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

>
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> -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
> <[hidden email]> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>

>> So maybe if Squeak renamed "Collections" similarly to what Pharo did,
>
> I don't mind if you commit the package under a new name. I wasn't
> aware that Squeak has a different package structure for collections.
>
>> MC allows a dash in a package name and treats it as one unique name?
>
> The important thing is that the name of a package is not a prefix of
> another package (like the package 'Collection' is a prefix of
> 'Collection-BTree'). The actual code that tests for this is:
>
>    PackageInfo>>category: categoryName matches: prefix
>        ^ categoryName notNil and: [categoryName = prefix or:
> [categoryName beginsWith: prefix, '-']]
>
> In Pharo people seem to avoid the use of dashes in package names.
>
> In Seaside we extensively use dashes as a tag to differentiate
> tests/examples and platform dependent code while keeping the package
> name the "same": http://code.google.com/p/seaside/wiki/PackageNaming
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project