2016-02-01 20:43 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:

> Hi Tim,
>
> On Mon, Feb 1, 2016 at 11:25 AM, tim Rowledge <tim at rowledge.org> wrote:
>
>> Surely class categories are, like method protocols, simply convenience
>> artefacts to aid reader comprehension and finding classes relevant to one’s
>> work?
>>
>> Using them as a semantic organisation for packages was a simplifying
>> short-cut for Monticello but not a particularly good idea for ‘serious’
>> package specification.  It wouldn’t (he said, waving appendages wildly) be
>> very hard to revise MC to use a quite separate idea of category names from
>> the browser. We’d need separated browsers for package-viewing and category
>> viewing I guess. Is there anything terribly wrong about having a
>> kernel-collections package that included a class or two from category
>> Collections-Unordered, a few Collections-Processes, something from
>> Compiler-Caches etc? And would that really require that every one of those
>> have all the methods installed? Not to mention that an actual kernel system
>> would require quite a few classes anyway
>>
>
> This was a /huge/ bone of contention in the VisualWorks team when we went
> to 5i to provide Store, given parcels in 3.0. My position was that package
> structure was another orthogonal property and structure than class
> categories.  Alan Knight's position was that this was unnecessarily complex
> and confusing and we should use class categories as packages, as does
> Monticello.  While I think I was right, I want to be happy.  I've used
> Monticello for 8 years and I love it.  I do love the simplicity of
> categories being packages.  Occasionally I chafe at the difficulty that
> categories make in slicing off a subcomponent (one often has to introduce a
> name like FuBar to carve off Fu-Bar from Fu and its underlings).  So while
> you're right that packages could be separate, and the architecture of
> Monticello makes that quite straight-forward, it does mean introducing a
> whole new level of tooling to deal with the new packaging namespace, and a
> lot of work to reorganize a system that is pretty-well organized right
> now.  So I think it's best to let sleeping dogs lie and live with the
> situation for now.  When someone embarks on a really interesting bootstrap
> project that constructs minimal images and provides new insights into how
> the system should be packaged it could be worth revisiting, but I think we
> have fatter fish to fry right now.
>
>
And now, the categories are kind of deprecated in VW... Absolutely not
visible from any Browser.
The browsers with double classification were somehow troubling. Maybe the
two classifications were too close (more parallel than orthogonal), or said
differently, not enough efforts had been put to distinguish the two (i.e.
using different vocabulary) - too many efforts for undetermined value?

I too like very much the simplicity of Montiello. In regard, the efforts of
Pharo for decoupling classification and package management only lead to
trouble so far (compatibility oblige they didn't yet abandon classification
oriented packaging if I understand it, but then they would face same
problem as VW IMO).

Nicolas


> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Mommy!  The cursor's winking at me!
>>
>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160201/00e58815/attachment.htm