In article <pan### [at] maccom> , Christopher James
Huff <chr### [at] maccom>  wrote:

> Actually, I think it might work fine if everything has a default value
> and is considered to exist at the opening { brace.

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'm not sure what you are trying to say about implementing it as a
> render-time variable...most of the uses I can think of for it are at
> parse time.

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.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <Xns### [at] 204213191226> , "Rafal 'Raf256' 
Maj" <raf### [at] raf256com> wrote:

> btw - Name 'this' or 'self' - maybe use both - for users that like C++ and
> thoes who like Pascal/Deplhi ;)

But POV-Ray SDL is neither of these, it is POV-Ray SDL and just putting
something useful in a programming language doesn't mean it is useful in
POV-Ray SDL.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3d186041@news.povray.org: 

> just
> putting something useful in a programming language doesn't mean it is
> useful in POV-Ray SDL.

it is not very useful, but always a little, and it is rather easy to 
implement as shown in previous post.


-- 

Post a reply to this message

> I consider inside() more as method. The same way eval_* for pigments and
> patterns.

But you don't consider the *_extent() functions to be methods? I
personally had to keep myself from typing "self.min_extent()". I would
say trace() is the same.


-- 
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

On Tue, 25 Jun 2002 09:09:29 -0500, Christopher James Huff <chr### [at] maccom>
wrote:
> > I consider inside() more as method. The same way eval_* for pigments and
> > patterns.
>
> But you don't consider the *_extent() functions to be methods?

Of course *_extent() function are method but result of it is also properity
since it has the same value as bounding box corners. I can't say the same
about inside. Inside method is function of vector. Of course all methods could
be considered as properities but it is different subject.

ABX

Post a reply to this message

On Tue, 25 Jun 2002 08:32:08 -0500, Rafal 'Raf256' Maj wrote:

> it is not very useful, but always a little, and it is rather easy to
> implement as shown in previous post.

I think it would be a bit harder than you think...have you even looked at
the parser code? It certainly wouldn't be implemented the way you suggest.


-- 
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

Christopher James Huff <chr### [at] maccom> wrote in
news:pan### [at] maccom: 

>> it is not very useful, but always a little, and it is rather easy to
>> implement as shown in previous post.
> I think it would be a bit harder than you think...have you even looked
> at the parser code? 

no :(

? It certainly wouldn't be implemented the way you suggest. 

if You say so...


I think that I can write a little preprocesor that will impliment this 
function, and I would only take about 0.01-0.05 sec every 1000 lines of 
.pov source on 1GHz.

I can write it - because I want to do something for best free 3d renderer 
ever :) I hope that this will be usefull...
If I would write [1] some preprocesor that will add useful functions to 
POV, will someone just add my ANSI C code to pov souces (or do You have too 
many volunteer coders already ;) ?

From technical side - I wish to write some addons for Pov. I don't have 
enought time to learn Pov source now :-/ but I can provide function like
char* fun(const char*); that will fast pre-proces scene script and as 
output give regular POV 3.5 code

[1] depending on free time in my work it would be 1 - 8 weeks


-- 

Post a reply to this message

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

In article <pan### [at] maccom> , Christopher James
Huff <chr### [at] maccom>  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.

You just don't need it.  If you think about it, what is the "this" pointer
in C++ for?  To access members without having to use lengthy specification
of the exact scope you are working on.  But why would you want to have to
write "self.radius = 1" if you could just as well implement it such that you
can write "radius = 1"?

Or do you always write "this->foo_member" inside a C++ member function?

> 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?

No, more in the spririt of POV-Ray give full access to everything.  Imagine
you could replace every expression with one i.e. depending on clock, the
parser would automatically recognize it and apply it dynamically.  No more
parsing of the whole scene.  The same would apply when rendering a single
frame.  Only after parsing (also that tehcnically isn't at render time but
just before it) the expression would be evaluated.  Of it could be any
function you insert.

Given an intelligent enough parser it is even be possible to allow
substitution of any block-level element with "code like a function" (I
intentionally want to leave the specific definition of this open).  As it
woudl effectively allow substitution of anything in an object by aosmething
declared, there would be no more need for a "self" or "this" because as soon
as you insert the function it automatically knows which context it is in.


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3d189874@news.povray.org: 

> specification of the exact scope you are working on.  But why would
> you want to have to write "self.radius = 1" if you could just as well
> implement it such that you can write "radius = 1"?

because this is needed to pass current object (this) to other function.
same as in C++ you would write draw(this);  and not :
temporary_object = { ... };
draw(temporary_object);
  




-- 

Post a reply to this message