durusmail: quixote-users: _q_import summary
_q_import summary
2003-01-21
2003-01-21
2003-01-21
_q_resolve summary
2003-01-21
2003-01-21
2003-01-21
2003-01-21
2003-01-21
2003-01-21
2003-01-21
2003-01-21
2003-01-22
2003-01-21
2003-01-23
_q_import summary
Greg Ward
2003-01-21
On 21 January 2003, Andrew Kuchling said:
> In an attempt to come to some decision on _q_import, here's a summary
> of options.
>
> 1) Do nothing, and Jon Corbet continues maintaining his patch.
>
> 2) Add _q_import(component) (_q_resolve, _q_bind_name, whatever),
>    which takes the string component and return a matching object.
>
>   2b) This may also do setattr(container, component, object),
>       so future accesses don't go through _q_import() at all.

Either of these is fine by me.  I have nothing against the concept, and
I *think* _q_import() is an OK name.  I can definitely see Jon's need
for it (or at least, I did the last time this was discussed and Jon
explained his need in detail).  But I have no burning need for it
myself.

> 3) Use _q_getname(req, component) instead.  The only change
>    required is to call _q_getname() for names that are
>    already listed in _q_exports().  This might break some existing
>    applications (one occurrence in our application).

_q_getname() is hard enough to understand already.  Leave it be.

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org

reply