Geoffrey Young wrote:
[...]
I see a problem with returning undef for
fields with NULL, when a string is expected. But may be it makes a
perfect sense.


yeah, I need to think about that.  mp1 treated undef as special in a few
cases (see below), but that was for setting purposes - I'm not sure about
returns.  I think it is logical to return undef for NULL, rather than ''
(which might mean "\0" or whatever that C string termination thingy is).
but yeah, then you get warnings if you use it in various operations.  but
warnings are good - if you get back undef which throws a warning, something
(maybe you, maybe apache) isn't doing something right, so you should account
for it (code in a default, decide that your approach is wrong, etc).

What do you mean, not doing right? Depending on the original uri you pass to parse() a field can be some string or NULL (undef in perl). So that means that you always need to check whether the field is defined before using it. That's true for optional fields like user, passoword, port, path, query and fragment.


I'm not sure what's the best solution here.

Anybody remembers how mp1 is dealing with those so I don't need to dig
it up?


IIRC $r->args(undef) is one case where the code needed to be changed to
allow for specifically unsetting r->args.  I don't recall the specifics, but
it was between doug, lyle brooks, and myself, probably on dev (and in
Changes IIRC).  I know that $r->custom_response(SERVER_ERROR, undef) also is
special, but that's not a direct slot accessor so the logic may be
different.  that's all I can think of off the top of my head.  hope it helps.

I don't recall it throwing a warning, which is why I asked if there is some
way around it above.  perhaps it's something about the XS wrappers that
we're doing differently that causes the warning?

Yes, the automatic accessor wrappers can't handle undefs at the moment. That needs to be fixed, optionally providing a special set of these that handle undefs.


I just wanted to verify first if that's what we want. Next I'm going to fix that.


-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to