Am Dienstag, 7. Dezember 2010, 18:49:31 schrieb Jeff Johnson:
> On Dec 7, 2010, at 12:39 PM, Eric MSP Veith wrote:
> > class Foo
> >
> > def a
> > end
> >
> > end
> >
> > # ... code passes ...
> >
> > class Foo
> >
> > def b
> > end
> >
> > end
> >
> > Leaves us with one class with two methods. This allows for some very
> > elegant Ruby ideoms.
>
> Same deal in python. The subtley is sub-typing vs sub-classing, but
> both are identically "elegant" (just sub-typing is hugely complex
> to get into place because the entire implementation is in C, not python).
There's no "sub-" involved: The class gets re-opened and features are added.
This is done during runtime. Sure, this is used rather rarely because of the
dangers that lure within, but it can prove to be a pretty elegant solution to
complex (OO-) problems.
> You will find that having an "rpm" container module isn't all that useful
> as you proceed with other objects, just like "package" isn't a very useful
> abstraction for "package management".
The "RPM::" module is more for namespace's sake than for anything else. I
don't plan on defining any constants or functions in it. I just need some
place where I define the symbol "RPM" that I can prepend to RPM::Mc and the
likes. Just for namespace niceness.
> See the PEP about "sub-typing" to see where the pain lies. "sub-classing"
> is easy, "sub-typing" is hard. I wasted about a weekend sub-typing python
> dicts polishing my PythonFu the hard way.
I actually wanted to pretty much avoid any sub-fooing. I concur with you that
it tends to create more problems than it (initially) solves.
Eric
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
