[squeak-dev] Monticello and PackageInfo

Chris Muller asqueaker at gmail.com
Thu Apr 4 20:47:17 UTC 2013


In Dave's case, I'm wondering whether simply renaming OSProcess-Base
et al back to OSProcess would be appropriate.

In Colin's case, it wasn't clear to me how the 1:many cardinality
helps -- e.g., whether the packages are OmniBrowser-Core +
OmniBrowser-TestFixtures (2 distinct packages) or just OmniBrowser +
OmniBrowser-TestFixtures (a hierarchy of 2 packages); under either
case the fact of the broken OB code leaves a dirty
OmniBrowser-TestFixtures package is still the same solution --
reloading OmniBrowser-TestFixtures.  The only difference I see is that
OmniBrowser package would report dirty too, even if it wasn't, just by
having run the tests.

So I remain skeptical but it seems I'm outvoted.  Thank you for
discussing it nonetheless -- some of our best decisions as a community
were because of good discussions.


On Thu, Apr 4, 2013 at 11:44 AM, Colin Putney <colin at wiresong.com> wrote:
>
>
>
> On Wed, Apr 3, 2013 at 4:36 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>
>>
>> So for me it is important that a class can belong to more than one
>> package.
>
>
> Me too. I've used this feature while splitting monolithic packages into
> multiple packages that can be loaded independently, not to manage a mistake,
> but to make the process easier as I went.
>
> I've also used it when developing tools like Monticello and OmniBrowser. The
> tests inevitably involve making code changes, and I've found it handy to
> have a sub-package containing only those bogus classes that get changed by
> the tests. When things don't get cleaned up properly because of broken tests
> or tools, I can fix things by just loading the sub-package to revert all
> changes.
>
> Colin
>
>
>


More information about the Squeak-dev mailing list