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

On Tue, 25 Jun 2002 12:20:58 -0500, Thorsten Froehlich wrote:

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

But that's not what it is for. In all the examples that have been given,
it is just the addition of the symbol in order to pass the object to a
function. Nobody suggested the example you gave or the syntax changes
needed for it, but you need a "self" symbol to do "min_extent(self)"
without declaring the object first. Allowing "self.radius = 1" would be a
completely separate addition. (I did use "self.min_extent() while talking
about another way of doing that, technically the "self." wouldn't be
necessary, but it was just an example of using min_extent() as a method
instead of a separate function.)


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

I actually did for a time with method calls, to make the difference
between calling a method and calling an ordinary function clearer, but I
eventually abandoned it...too much work.


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

That sounds like my understanding of a functional language (I haven't
coded in one and don't know any in detail, but I've read some about them,
and the next language I learn after Ruby will probably be one). A "shape
definition" would be a function that would be called by the renderer with
some parameters given by the renderer and others by the user, and the
parameters themselves could be function calls. An if statement would be a
function with one value if the condition is true and another value if it
is false. Loops seem to be done mainly by recursion.

From the comp.lang.functional FAQ:
"A functional language is a style of programming that emphasizes the
evaluation of expressions, rather than execution of commands. The
expressions in these languages are used by using functions to combine
basic values. A functional language is a language that supports and
encourages programming in a functional style."
http://www.cs.nott.ac.uk/~gmh//faq.html

It sounds similar to an "evaluator" system I've been working on for my own
raytracer, basically a bunch of "evaluators" (basically function objects)
that are plugged together to do shading. I didn't recognize it at the
time, but I was doing a form of functional programming by linking up
functors. POV already does this a bit with things like deeply nested
pigments or textures and the ability to use equations, patterns, and
pigments in functions, though it could be made much more flexible and
simpler.


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

>> 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"?
>
> But that's not what it is for. In all the examples that have been given,
> it is just the addition of the symbol in order to pass the object to a
> function.

Yu still inherit a bunch of problems from pointers/references which are not
necessary.  After all, there is still no real need.  A function simply
operates on whatever object it was called by.  It couldn't access any other
object anyway...

> That sounds like my understanding of a functional language

No, it would not because POV-Ray SDL itself describes a state and still
would after such an extension.  The function would be nothing else but a
user-defined type of texture, pattern, media, vector, float, matrix etc.

    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

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

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

Not really.  As you cannot reference other objects than the current one
anyway you would not need to pass that information, it would already be
known.

    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:3d18c6c4@news.povray.org:

>> 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);
> Not really.  As you cannot reference other objects than the current one
> anyway you would not need to pass that information, it would already be
> known.

hmm ? this is simple - example :


#declare tempObj = union { 
  ........
 }
#declare tempObj = object { tempObj translate max_extent(tempObj).x*3 }
object { tempObj rotate y*3 }
#declare tempObj = object { tempObj translate max_extent(tempObj)*9 }

wouldn't it be nicer to write above just as :

union {
 ........
 translate max_extent( this ).x*3
 rotate y*3
 translate max_extent( this )*9
}

?

it IS easy to implement - as I shown few posts before, even I can myself 
write it, but as pre-procesor function (because I dont have now time/skill 
to modify POV sources itself)

-- 

Post a reply to this message