<div dir="ltr">Hi Tim,<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 11:25 AM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Surely class categories are, like method protocols, simply convenience artefacts to aid reader comprehension and finding classes relevant to one’s work?<br>
<br>
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<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
</span>Mommy! The cursor's winking at me!<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>