|
 |
On Fri, 12 Jan 2001 07:11:33 -0800, Ken wrote:
>
>
>Warp wrote:
>>
>> Ken <tyl### [at] pacbell net> wrote:
>> : Why go looking though a bunch of macro files
>> : for a specific function when if can be hard wired into the program.
>>
>> Let me think about some reasons why a macro would be better:
>
>And this is the exact response I expected from someone with advanced
>mathematical and programming skills. You just don't get it.
If the macro is provided with the release of POV you download and install,
you won't have to go looking for it (ideally) and you'll be able to use it
almost like any other keyword, modulo the slight performance hit someone
mentioned (and that we're working on fixing.)
Just because you *can* find and change the behavior of the macro doesn't
mean you have to. I'm sure plenty of people here use Chris Colefax's
macros without the slightest clue how they work, and there's no reason
why any other macro, particularly one that's included with the program,
wouldn't be the same.
But if you *want* to change the behavior, it's a lot easier if it's a
macro than if it's a keyword, and far more portable to other installations
of POV.
Something I'd love to see in the parser, though perhaps it would be too
confusing, is the ability to invoke macros using alternate syntax, so
you could have macro invocations that looked more like first-class tokens.
The idea is that you then wouldn't have to remember whether the pattern
you want to use is implemented as a macro or a builtin, i.e. you use
"hexagon color, color, color modifiers" but you use "hextiles(mortar,
pigment, pigment, pigment, pigment) modifiers" or you use "sphere {center,
radius modifiers}" but you use "object {TorusSpline(radius, points, start)
modifiers}". But I'm not sure how to implement any of this cleanly at the
moment.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
