Bob Hughes schrieb in Nachricht <36D4526F.97901B37@aol.com>...
>Think you lost me more than I you.
>Simply put, if you had 'light source' instead of 'light_source' and
>there was a way the pvengine would only see it when written that way,
>ie. *not* when typed in as 'source light' or 'light color' (parser would
>say "What the...!? then), I would certainly like that way of things.
>

It is possible and done before, but I'm afraid the parser would even be
slower than it is now (and it really is, IMHO - please let's not discuss the
speed of the parser again, not here).

But radically changing the keywords is not what we need. I'd rather see a
more object oriented approach, where every object (where light_sources and
cameras would also be objects) would have a predefined set of properties,
which can either be set or read and have a default value. I'm not asking for
data encapsulation or inheritance (yet <g>) or any other *real* object
oriented behaviour, just for a slightly different approach. In fact we
almost have this, but now all properties of objects are keywords too. That
would be too much. All the different types in some objects could just as
well be named constants. Also look_at and position wouldn't be keywords
anymore, but simple properties, where the naming conventions could be
different (e.g. Camera1.LookAt and Camera1.Position - my favourites).

camera {
  Position <1, 1, 1> // or even "Position = <1, 1, 1>"
  Up <0, 1, 0>       //         "Up = <0, 1, 0>
  LookAt <0, 0, 0>   //         "LookAt = <0, 0, 0>
}

light {
  ....

#declare MyBlob = blob {
  Threshhold = 0.7;
  Elements =

    sphere

etc. etc.

But on the other side, this would perhaps turn the script language even more
into a programming language. Good for programmers, bad for non-programmers,
who would have an ever steeper learning curve.

It would propably also make the parser faster (because of the stricter rules
applied), but also much less flexible. Although flexiblity can lead to
sloppiness and mistakes which are hard to find.

There are pros and cons to each approach (the current one and the one I'd
like to see).

So propably the best thing would be to leave it as it is and just add more
and more keywords (either with or without underscores). I could live with
that, as long as the parser speed would be improved constantly.
--
Rudy Velthuis

Post a reply to this message