On Dec 7, 2010, at 12:39 PM, Eric MSP Veith wrote:
> Am Dienstag, 7. Dezember 2010, 18:13:09 schrieb Jeff Johnson:
>> Perhaps I don't understand. What is the issue naming "rpm.so"?
>
> Ah, I wanted to be done with a simple "require 'rpm'" without too much behind-
> the-scenes-fiddeling with extra name mapping. Ruby modules and classes are
> mutable, i.e.
>
> 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).
> It is AFAIK possible to do a "require 'libfoo_internal'" and having a call to
> rb_define_module("Foo") in libfoo_internal.so. It's just not that pretty IMHO
> and doesn't follow Ruby ideoms.
>
> But, nevertheless, I'll try to stick with the RPM naming scheme. If I
> encounter problems, I'll cry for help. :-)
>
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".
In python, this is dealt with like "_rpm.foo" and "_rpm.bar" where "foo" and
"bar"
are different types (think: classes) for python, but part of the same bottom
side "_rpm" module.
The module name is a directory from which __init__.py (the top side which loads
the bottom side) is loaded.
Having __init__.py permits manifest constants to be set simply by
editing __init__.py (rather than waiting around for years for RPM
to be upgraded, total waste of time imho).
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.
hth
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
