-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 31 October 2010, Jeff Johnson <n3...@mac.com> wrote:
> Yup. Lots of places where (even if proper errors are returned) nothing
> uses or cares to check the error code.
> [...]
> I expect Ruby to be about the same: DWIM.
As far as I am concerned, at least the Ruby bindings will be so not DWIM.
I.e., I don't plan on creating RPM::solve_my_problem(). This is for pure
egoistic reasons: I don't want to be held responsible if/when something
breaks silently with the bindings involved because there was no exception
thrown.
> > What about either adding an rpmRC* error to the method signatures of
> > doDefine & Co, or changing their signatures to return the rpmRC, and
> > making the parse address one parameter?
>
> And here the issue is API/ABI: If the library API/ABI changes
> in any way at all, then all that happens is lusers start chanting
> RPM has no stable API/ABI!
I'd happily add wrapper functions/defines to address backwards compatibility
and plaster them also quite appily with big @deprecated warnings all over
the place. ;-)
> Meanwhile, rpmExpand et al have almost nothing important to do with
> "package management".
Sure, but I'd like to get the small things right nontheless. I.e., signal a
Rubyist that 'f' isn't a valid name for a macro.
> Meanwhile the important issue is _NOT_ what rpmlib returns, but rather
> ensuring that the design of the ruby bindings is architecturally correct.
>
> In C, its a very common paradigm to do:
> if (someRoutine(..))
> fprintf(stderr, "Danger Will Robinson! Error! Error! Error!\n);
> That C paradigm just doesn't fit into most bindings, which (if
> intelligently designed) usually return "self" or "this" so that methods
> can be recursively nested like
>
> fooClose( fooRead( fooOpen("/some/file", ...) ...) ...)
>
> Focus on the ruby binding design, exceptions (or mappings to NIL or NULL
> or EMPTY) can be arranged whenever you are sure that you have a
> tasteful/intuitive/aesthetic ruby binding paradigm.
That's why I was asking for return codes. E.g., defining a macro with a name
that's less than 3 characters long should throw an exception. Currently, the
bindings code has no way to catch that error since the RC of the
corresponding macro C function is either not there (i.e., void) or always 0.
> That's one approach. There are others. But returning rpmRC for macros in
> ruby is gonna have a ripple effect everywhere that is quite costly to
> stabilize.
Nay, only in the Ruby bindings *C* code. I.e., translate the return code of
e.g. rpmDefineMacro into something that is to be expected in that language
(be it an exception or something else). The rest of the code can continue to
do (void)rpmDefineMacro(...) as it's done now. The API already has the
return code in the function signature, it just isn't used right now (at
least in the macro code).
Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkzO3YcACgkQhS0drJ3goJK3DwCfekS8Ced4Fq3cSXjuhrp1IuDJ
pOUAn2DfM0Qz6qZpGEUN3TLNnAdu9HJP
=OoUf
-----END PGP SIGNATURE-----
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
