Re: object(x) rethink
Andy Drummond wrote:
>
> The Euphoria docs tell me that object(x) always returns True. That makes
> it a bit useless. Especially since if x is NOT an object it crashes
> Euphoria!
> Would it not be better if object(x) returned True if x was an object and
> False if x either was not an object (i.e. something else like a function)
> or, and this is what I would like, if x had not yet been assigned a value
> so, even though it might have been declared, it is valueless.
Well just to get over the pedantic issue first, object() does not return True or
False; it returns 1 or 0. Euphoria has no boolean datatype.
But yes, object() does seem quite useless in its current form. But what do we
want it to do? So far we seem to have a few options:
(A) Leave it alone.
(B) Return 1 if the symbol has been explictly declared as 'object', regardless
of what type of data it is currently carrying, otherwise return 0.
(C) Return 1 if the symbol has been assigned a value, othewise return 0.
(D) Return a value that represents the declaration type of the symbol. eg. 1 for
objects, 2 for sequences, 3 for integers, 4 for atoms, 5 for user-types, 6 for
procedures, 7 for functions, ...
(E) Same as (D) but related to the current data content of the symbol, rather
than the original symbol declaration.
(F) Same as (D)/(E) but also return the negative value if the symbol has not
been assigned yet.
My feeling is it should be left alone. Instead of changing it, we need some new
built-in functions to tell us things about the symbols.
It should be left alone because the Euphoria datatype system is built upon a
hierarchy of datatypes...
atoms are also objects
integers are also atoms and thus also objects
sequence are also objects
The current integer(), atom() and sequence() functions give us information about
the current data contained by the symbol, so therefore object() should do the
same. This is particularly useful when dealing with sequence elements, which are
always 'declared' as objects.
However, we could do with functions like assigned() and declaration().
The assigned() function would return 1 if the symbol has a value, and 0 if it
doesn't. This information is useful so we can tell if we need to initialize the
symbol or not.
I was thinking that a declaration() function would return a value indicating
what the symbol was declared as, but I can't think of anything useful to do with
that information. With the possible exception being that a function that took a
routine_id could be able to tell you things about the routine, such is it a
function or procedure, what is name and namespace is, what is parameter signature
is, etc ...
I also think the interpreter should raise an exception (that is, crash) when the
symbol used as a parameter has not been declared at all.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
|
Not Categorized, Please Help
|
|
