Personally, I'd prefer "self"... ;-)
I don't think this would work, not with the current object syntax anyway.
If it is available at any point in the object block, then it would have to
be available at times when the object doesn't completely exist yet. There
would be an "invisible line" somewhere where the "self" identifier would
appear, you couldn't do this:

sphere {min_extent(self), 1}

And I'm not sure how CSG objects would handle it in between adding
objects, or meshes while adding triangles. Something like this might work
though:

object {
    sphere {...}
    "self" or "this" is defined in this level, but not in the shape
specification block itself, making sure there is a complete shape to
refer to.
}

Or if the shape parameters used a different syntax or always had default
values...it would be pretty much necessary for my idea of changing the
POV-Ray language into a prototype-based object oriented language.


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

> Moreover AFAIK extents are only properity available for script.

  You forget inside().

  (And perhaps also trace() could be in some way thought as a property of
the object...)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

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

> I don't think this would work, not with the current object syntax anyway.
> If it is available at any point in the object block, then it would have to
> be available at times when the object doesn't completely exist yet.

While it would not only not work practically when implemented as a
parse-time variable, it is also not necessary if implemented as a
render-time variable - the scope and object are always known and
well-defined without ambiguity at that time!

    Thorsten

Post a reply to this message

On Mon, 24 Jun 2002 13:15:46 -0500, Thorsten Froehlich wrote:

> While it would not only not work practically when implemented as a
> parse-time variable, it is also not necessary if implemented as a
> render-time variable - the scope and object are always known and
> well-defined without ambiguity at that time!

Actually, I think it might work fine if everything has a default value
and is considered to exist at the opening { brace.
If that were so, this:
sphere {min_extent(self), 1}
would center the sphere on the min_extent of the default sphere. I don't
know what it would do for meshes or CSG though, and it might not give a
perfectly obvious result all the time...

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.


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

>> While it would not only not work practically when implemented as a
>> parse-time variable, it is also not necessary if implemented as a
>> render-time variable - the scope and object are always known and
>> well-defined without ambiguity at that time!
> Actually, I think it might work fine if everything has a default value
> and is considered to exist at the opening { brace.

> If that were so, this:
> sphere {min_extent(self), 1}
> would center the sphere on the min_extent of the default sphere. I don't
> know what it would do for meshes or CSG though, and it might not give a
> perfectly obvious result all the time...

I think that is rather easy to implement - even more - I could implement it 
my self - as pre-procesor, and I think that same algorithm will work for
new parser :

1. if You fond keyword 'this' in expresion 'zzz(this)' then 
1a. parse '#declare this_obj = xxx { yyy }' where xxx is type, and yyy are 
object modificers and parameters of object in with keyword 'this' was found
1b. change 'qqq zzz(this)' to 'object {this_obj qqq zzz(this_obj)'
and continue parsing
  qqq zzz(this) - this is last sentens, that was not completly paresed 
(because) 'this' was found while parsing it. 
  i.e.  translate <1,2,3> will be translated fully, and it would be part of
  yyy in  example above, and entrie
  translate min_extent(this) is qqq/xxx

  It should work, ie.:
union { sphere{1,2} sphere{0,1} translate min_extent(this) }
  would become
#declare this_obj = union { sphere{1,2} sphere{0,1} }
object { this_obj translate min_extent(this_obj) }

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





-- 

Post a reply to this message

On 24 Jun 2002 12:00:28 -0400, Warp <war### [at] tagpovrayorg> wrote:
> W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> > Moreover AFAIK extents are only properity available for script.
>
> You forget inside().

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

ABX

Post a reply to this message

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