On Tue, 25 Jun 2002 08:19:36 -0500, Thorsten Froehlich wrote:

> If you carefully consider the scope in either case you will notice that
> there is no other than the "this" or "self" (or whatever you call it)
> scope, so no need for it as keyword to specify the only available scope.
>  In particular because every attribute of the object would be a reserved
> name anyway, so no need to disambiguate between local and global
> variables either.  Essentially what I am pointing out is that the
> concept of "this" or "self" simply does not apply to POV-Ray SDL.

I don't understand what you mean...it doesn't have anything to do with
disambiguating scope, it would be a symbol for the shape currently being
parsed. It has an equivalent in the current language, it's just a
shortcut, so I don't know how it doesn't apply.


> As we are talking about the future so am I.  Just imagine every
> expression being a function rather than a macro.  Then you would apply
> the changes to the object after everything is well-defined and order
> problems would not exist.

Sounds interesting, but I think you need to explain a bit more. Do you
mean using a VM for everything instead of the current direct parser, but
using a syntax somewhat similar to what there is now, or are you talking
about making a functional language like Lisp or Scheme?

I would personally like a simplified prototype-based object oriented
language...all the current shapes would fit in a heirarchy of objects. To
create a sphere, you would copy the "sphere" object and place it in the
scene, then modify it to fit your needs. All the attributes would exist at
all times, you wouldn't have a "half constructed" object. It is a very
flexible system, but not as complex as a class-based system. Syntax would
be something like:

sphere.create() {
    center = self.min_extent();
    radius = 5;
};

The create() method would make a copy and add it to the scene, so you
wouldn't have to add it with a separate call. The following block executes
in the scope of the object, you can define new members or modify existing
ones. The create() call returns a complete object, so there's no problems
with calling min_extent(). The standard objects would not be constant, you
could modify the default sphere center like this:

sphere.center = < 1, 2, 3>;

The same would apply for textures, the camera, global settings, and
anything else that would be contained by an object. You could extend and
modify POV-Ray without having to modify the parser and distributing a new
version, an include file could create objects that would be used exactly
like the built in objects, or could add its own behavior to the built in
ones.

Also, I'm currently learning Ruby, and I'm getting a few ideas for CSDL
that could also be applied to a POV-Ray language without making things too
complicated.


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/

Post a reply to this message