On 03.04.2013, at 12:07, Chris Muller <asqueaker at gmail.com> wrote:

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

Yes. E.g., there are some projects that provide both separate "hyphen-packages" and one "combined" package. The former is better for development, the latter simpler for users. Balloon3D is an example.

Also, OMeta uses custom package infos for bootstrapping. You have two package infos for the very same classes and methods.

- Bert -

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