[DGD] typeof bug?

[Robert Forshaw]

>From: Par Winzell <zell at skotos.net>
>Reply-To: dgd at dworkin.nl
>To: dgd at dworkin.nl
>Subject: Re: [DGD] typeof bug?
>Date: Wed, 30 Mar 2005 14:40:56 -0600
>
>Robert,
>
>>return typeof(a) == T_STRING;
>>
>>Returns 0. If I allocate an empty string to a, then it returns 1. 
>>typeof(a) == T_NIL returns 1 of course, but shouldn't there be a priority 
>>to refer to the type of data the variable could hold, rather than what it 
>>happens to be holding at the time? Or perhaps there should be another 
>>function: datatype - which returns the datatype of the variable rather 
>>than its present content? Or is there a way of doing that already?
>
>This has marginal uses at best.
Generally you always know what the
>type of the variable is, because you typed the piece of code that declared 
>it just a couple of lines earlier. The type of a variable is a static trait 
>of the compiled program.
>
>The only use I can think of for what you suggest is a debugging macro, e.g.
>
># define DUMP(v)  SysLog("Value of: " + variable_name(v) + "[" + \
>                          variable_datatype(v) + " is: " + \
>                          lpc_to_ascii(v));
>
>but... eh.

If past experience has told me anything, it's that requesting a small 
feature in a future version of DGD doesn't work; rather I get told that the 
feature is useless and I don't really want it. I'd like to be proven wrong 
for once.

Here's the macro in question that gave rise to my discovery that typeof 
doesn't do what I thought it did:

#define EMPTY(X) { if(typeof(X) == T_STRING) X = ""; else if(typeof(X) == 
T_ARRAY) X = ({ }); else X = nil; }


In literature, one tries to express as much as possible with as few words as 
possible. By the same reasoning, I want to achieve as much function as 
possible with as little code as possible (with as much lucidity as 
possible), and this is my means of doing that. That is why I would find such 
a feature useful. Here's just a few of the other definitions and macros I 
like to use:

#define EMPTY_ARRAY ({ })

#define EMPTY_STRING ""

#define SWAP(X, Y) { mixed val; val = (X); X = (Y); Y = val; }

#define ARR_INCREASE_SIZE(X, INC) { X += allocate(INC); }

#define GET_BIT(C, B) (((C) << (31 - (B))) >> 31)

#define ARR_REDUCE_BY(X, A) if(A < sizeof((X))) X = X[..sizeof(X) -\
(A + 1)]; else X = EMPTY_ARRAY;

#define UNTIL(X) while(!(X))

#define ARR_SET_MAX(X, MAX) { if(MAX < sizeof(X)) {\
if(MAX > 0) { X = X[..MAX - 1]; } else { X = EMPTY_ARRAY; } }\
else { X += allocate(MAX - sizeof(X)); } }

#define REMOVE_ELEMENT(A, E) A = A[..E - 1] + A[E + 1..];

#define MAX(V, M) ((V) > (M) ? (M) : (V))
#define MIN(V, M) ((V) < (M) ? (M) : (V))

#define APPEND(A, X) A += ({ X });

#define LOOPVARS() int i, sz;

#define ITOC(I) (((string)(I))[0])

#define IS_EMPTY(V) (!(V) || (V) == EMPTY_STRING)

...and so on.

As an aside, I'm coding a pseudo-language which is parsed into LPC. 
Preprocessor definitions come in very handy when trying to keep my code 
short and to the point.

_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger 
http://www.msn.co.uk/messenger