On 12/9/05, Brad Fuller <brad at sonaural.com> wrote:
> Ramon Leon wrote:
>
> >>That's how I use it today.
> >>But, what if you want to add classes from other categories,
> >>that do not have the prefixed name?
> >>For instance, I have an app and all the classes are in the
> >>same category. No problem. But, I have a plugin that I want
> >>to include in this package, but I want to to stay in another
> >>category. It does not have the prefixed name (in your
> >>example, it does not have the "CoolProgram" prefix.) How do
> >>you add that -- w/o adding that complete category as a
> >>required package?
> >>
> >>
> >
> >That's what the dependency mechanism is for, add that other package as a
> >dependency of this package, rather than trying to put it in this
> >package.  Packages are the proper level of reuse, not classes, so if you
> >use one class from another package, then you rightfully depend on that
> >other package.
> >
> >
> Not if I only depend on that one class. I only want to add one class,
> not all of the classes in the category. Unless I'm missing something
> very basic -- which is entirely possible :-)
>
> What I would like is to add single classes from different categories.
> Sure, I could change the category of, let's say, a plugin class. But, I
> would like to keep the plugin under the VMMaker-Plugins category, and
> not create a new category just to add it to a package.

I think one of the issues that Ramon is driving at is that using a
class from another package means that you may be indirectly using
other classes in that package, whether you mean to or not.  So, the
proper level of dependency IS at the package level, not at the class
level.

--
Jason Rogers

"I am crucified with Christ: nevertheless I live; yet not I,
but Christ liveth in me: and the life which I now live in
the flesh I live by the faith of the Son of God, who loved
me, and gave himself for me."
    Galatians 2:20