MOO-cows Mailing List Archive


Re: Scattering assignment

Chris Schlesiger wrote:
> I've gotten to really like the scattering assignment in the new server
> version. I was wondering what people would think of adding on to it the
> following:
>   Type requirements.


> So for each of the types:  STR, INT, FLOAT, OBJ, ERR, LIST, we would need
> a special character prefix. Now, I haven't given much thought to what
> characters to use for each (though # immediately comes to mind for OBJ),
> and I suppose that whatever characters are chosen would have to be noted
> carefully so that people don't accidently start variables with them (and
> unintentionally force their data type if used in a scatter assignment),
> but I think that's only a minor problem.

How about a new reserved word-- "as", used for type checking.

In simple assignment, 

     <var> = <expr> AS <type>;

Or, in scattered assignment,

     {<var1>, <var2>} = {<expr1> AS <type>, <expr2> AS <type>};

If the result of <expr> is not of type <type> then E_TYPE is raised.  (Or
if the verb is !d then E_TYPE is assigned to <var>.)

This eliminates the need for a bunch of new special characters that would
undoubtedly conflict with existing code or make it a much bigger chore to
add to the MOO code parser.

Now that I think of it, I wouldn't mind being able to typecast, such that

     x = #3 AS NUM 
     => 3

but since tonum(), tostr(), etc. exist there really isn't a need to add
new stuff to MOO for it.  :)

> Now, the above suggests that it might be nice to combine the ? with the
> type specifier so that z must to be either STR or NUM but not
> both, but I think that's probably getting a bit complex.

And probably unnecessary.  Though, maybe the above example could work like

    z = <expr> AS {NUM, STR};

You could probably take it even one level higher and allow an expression
to the right of the 'as', which should return a NUM or a LIST of NUM.
But this leads to strangeness like which error should be used if that
expression returns the wrong type?  E_INVARG?  (Remember, E_TYPE woule be
reserved for when the assignment didn't match the specified type.)

And, again, I personally don't see much use for it.

That's my two bits' worth.  :)

Follow-Ups: References:

Home | Subject Index | Thread Index