roxen.lists.pike.general

Subject Author Date
Re: Importing constants from modules in 7.8.* Henrik_Grubbström <grubba[at]roxen[dot]com> 22-04-2009
On Mon, 20 Apr 2009, <aldem-pike[at]aldem.net> wrote:

> On Mon, Apr 20, 2009 at 07:00:07PM +0200, Henrik Grubbström wrote:
>
>> Are you sure that it actually worked in Pike 7.6 (ie that zero_type(NULL)
>> was 1)?
>
>  Hmm...No, zero_type(NULL) is 0, but nevertheless, it worked as expected...

I've now added compat support for the 7.6 behaviour. Note that the 
behaviour is fickle and not something you'd typically want to rely on:

Pike v7.8 release 247 running Hilfe v3.5 (Incremental Pike Frontend)
(running in Pike 7.6 compat mode)
> class Foo { constant a = 0; constant q = UNDEFINED; };
> map(values(Foo), zero_type);
(1) Result: ({ /* 2 elements */
                 1,
                 1
             })
> class Foo { constant a = 0; constant q = UNDEFINED; constant z = 0; };
> map(values(Foo), zero_type);
(2) Result: ({ /* 3 elements */
                 0,
                 0,
                 0
             })

>  The question is, how to alias UNDEFINED to NULL without using preprocessor?

That's exactly what you get in Pike 7.8; just that you can't access it via 
the module interface, since UNDEFINED has a special meaning there.

>  I just hate to type zero_type(X) all the time, that's why this NULL was
>  invented, to compare something to it instead.

Comparing with UNDEFINED doesn't help you (it's actually the cause for the 
7.6 behaviour above). Try creating a class with a lfun::`==() instead:

> class null { int `==(mixed x) { return intp(x) && zero_type(x); } };
> object NULL = null();
> NULL == 0;
(3) Result: 0
> NULL == NULL;
(4) Result: 1
> NULL == UNDEFINED;
(5) Result: 1

>> The reason that it fails is probably that NULL actually gets the value
>> UNDEFINED (and not 0) in Pike 7.8. Note that symbols with the value
>> UNDEFINED in modules indicate that the symbol doesn't exist, thus the
>> error message.
>
>  So, then this is kind of semantics change? UNDEFINED is not regular value
>  anymore (like it was before).
>
>  Thanks!
>
> Regards,
> /Al

--
Henrik Grubbström					<grubba[at]roxen.com>
Roxen Internet Software AB