Doing that causes issues and confusion -- for example changing a
method in the Foo-Bar package means both the Foo package and Foo-Bar
packages are dirty.

By my understanding this is why most folks append suffixes to their
package names like "-Core".  That way, you have "Foo-Core" and
"Foo-Bar" and "Foo-UI", etc.  Three packages, no overlap, no
ambiguity.  Simple.

Do we have any examples today of methods/classes belonging to multiple
packages today?


On Wed, Apr 3, 2013 at 2:01 PM, Colin Putney <colin at wiresong.com> wrote:
>
>
>
> On Wed, Apr 3, 2013 at 11:37 AM, Chris Muller <asqueaker at gmail.com> wrote:
>>
>> > This "feature" is misguided because a class can belong to multiple
>> > packages. So asking a class for its single package info is wrong.
>>
>> (Why such strong words?)  A class can only be defined in one package,
>> just as in Monticello, and this method simply associates its MC
>> equivalent to PackageInfo domain objects.  Why do you say a class can
>> belong to multiple packages -- because of extensions?
>
>
>  A class *can* be part of multiple packages.
>
> Imagine you have two packages, 'Foo' and 'Foo-Bar'. All the classes that
> belong to 'Foo-Bar' are also part of 'Foo'.
>
> Colin
>
>
>