Pardon me if this has already been suggested.

Most macro writers could make the idiot-proofing of their macros much 
more thorough by having a feature by which it is possible to test an 
argument passed to the macro to determine if it is of the expected type.

Not only can this be used to give better feedback in an error message, 
macro writers could also use it to make a macro more flexible for the 
end user.

Here's one I though up just now:

#macro FunHouse(Paint)
   #if(type(Paint)="texture")
     #local txtPaint=Paint;
   #else_if(type(Paint)="pigment") // yeah, the SDL could use an
                                     // else-if statement, if it
                                     // doesn't already have one
     #local txtPaint=texture { pigment { Paint } }
   #else
     #debug "Invalid object passed as Paint parameter to FunHouse().\n"
     #local txtPaint=texture { }
   #end
   union {
      /// several objects here to make a fun house
      texture { txtPaint }
   }
#end

I suggest passing a string back only because it's more human-readable 
for comparisons, and more easily allows for future expansion of the 
feature (such as stating whether the object is an array of something, or 
just a something).

Regards,
John

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> Pardon me if this has already been suggested.
>
> Most macro writers could make the idiot-proofing of their macros much
> more thorough by having a feature by which it is possible to test an
> argument passed to the macro to determine if it is of the expected type.
>
> Not only can this be used to give better feedback in an error message,
> macro writers could also use it to make a macro more flexible for the
> end user.
>
> Here's one I though up just now:
>
> #macro FunHouse(Paint)
>    #if(type(Paint)="texture")
>      #local txtPaint=Paint;
>    #else_if(type(Paint)="pigment") // yeah, the SDL could use an
>                                      // else-if statement, if it
>                                      // doesn't already have one
>      #local txtPaint=texture { pigment { Paint } }
>    #else
>      #debug "Invalid object passed as Paint parameter to FunHouse().\n"
>      #local txtPaint=texture { }
>    #end
>    union {
>       /// several objects here to make a fun house
>       texture { txtPaint }
>    }
> #end
>
> I suggest passing a string back only because it's more human-readable
> for comparisons, and more easily allows for future expansion of the
> feature (such as stating whether the object is an array of something, or
> just a something).
>
> Regards,
> John

Agreed, but I think the type() operator should return a string of the objects
type, in which case you'd have to use string compare.  Being able to determine
the type could also be handy for permitting greater flexibility in macros and
text file reading and writing operations.


-Reactor

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> Pardon me if this has already been suggested.

The idea is indeed not new: Something along these lines is implemented in
MegaPOV. Unfortunately, it doesn't seem to be on the agenda for regular POV
3.7.

I'd consider this a good thing to have in a POV 4 SDL, at any rate.

>    #else_if(type(Paint)="pigment") // yeah, the SDL could use an
>                                      // else-if statement, if it
>                                      // doesn't already have one

POV 3.6 SDL doesn't, but I consider it an essential of any well-designed syntax
to allow for something like an else-if - whether implicitly due to the overall
language design (like C for instance) or explicitly due to a dedicated
statement (like C's preprocessor language).

Post a reply to this message

in news:49edb414$1@news.povray.org John VanSickle wrote:

> Pardon me if this has already been suggested.
> 
> Most macro writers could make the idiot-proofing of their macros much
> more thorough by having a feature by which it is possible to test an 
> argument passed to the macro to determine if it is of the expected
> type. 


http://docs.python.org/tutorial/errors.html#handling-exceptions

Ingo

Post a reply to this message