> While our automatic get/set
> accessors happen to support set-to-NULL mode, by passing undef as an
> argument, it generates a warning:
>
> Use of uninitialized value in subroutine entry
>
> Both, when accepting an undef as an argument and when returning one.
hmm, that's odd. is there any way around that (see below)?
>
> While, I see no problem with adjusting the API to allow passing undef to
> set a certain field to NULL,
yes, we need that. at least we did for mp1, so I suspect the same is true
with mp2. your $parsed->query('') example is a good one - '' is very
different than null, so I would expect $parsed->query('') to behave exactly
as it does. $parsed->query(undef) should have the desired effect (well,
without the warnings :)
> 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).
>
> 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?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
