MessyBlob wrote:
> "clipka" <nomail@nomail> wrote:
>> Yuck. We all know this sucks.
> 
> Doesn't JavaScript have the ability to assign properties to objects as they are
> being instantiated?, e.g.
> 
> Sph = new Sphere( {
>   radius: 1,
>   position: [0,0,1]
> } );
> 
> I'm not sure about assigning 'new objects as properties' within these
> properties, e.g. creating a new material in the Sphere new object. Can anyone
> clarify this?
> 

I've never come across this particular syntax. What is more common is to 
do something like this:

Sph = new Sphere();
Sph.radius = 1;
Sph.position = [0,0,1];

-Mike

Post a reply to this message

SharkD wrote:
> I've never come across this particular syntax. What is more common is to 
> do something like this:
> 
> Sph = new Sphere();
> Sph.radius = 1;
> Sph.position = [0,0,1];
> 
> -Mike

Or something like this:

function Sphere(radius, position)
{
	this.radius = radius;
	this.position = position;
}

var Sph = new Sphere(1, [0,0,1]);

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> MessyBlob wrote:
> > "clipka" <nomail@nomail> wrote:
> >> Yuck. We all know this sucks.
> >
> > Doesn't JavaScript have the ability to assign properties to objects as they are
> > being instantiated?, e.g.
> >
> > Sph = new Sphere( {
> >   radius: 1,
> >   position: [0,0,1]
> > } );
> >
> > I'm not sure about assigning 'new objects as properties' within these
> > properties, e.g. creating a new material in the Sphere new object. Can anyone
> > clarify this?
> >
>
> I've never come across this particular syntax. What is more common is to
> do something like this:
>
> Sph = new Sphere();
> Sph.radius = 1;
> Sph.position = [0,0,1];

Yeah, hard getting imperative languages to look like declarative SDL, isn't it?
;)

I know not enough Lua, I only know it's become very popular among embedded
languages, that it's been developed by a brazilian researcher and that he also
teaches Scheme and brought many ideas from it into Lua. :)

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> > > Sph = new Sphere( {
> > >   radius: 1,
> > >   position: [0,0,1]
> > > } );
>
> The class defines default property values in its constructor. Then when you
> create instances, you can optionally assign values to the properties. So the
> examples of 'radius' and 'position' are the names of the properties defined in
> the class. I think this is a very elegant way of instantiating objects, with
> syntax that is very similar to POV-Ray SDL.

Yes, but unless I'm mistaken, all you can do in the object's namespace at this
time is assign values. You cannot, for instance, call functions defined by the
contructor - you could only assign a different value to that function.

> Can you explain your thoughts on what the problem will be with this approach?
> Are you thinking of transformations? Method-triggering property
> assignments ('set' methods) achieve this, e.g. a "translate: [1,0,0]" property
> would call ".doTranslate([1,0,0])" to change the transform matrix just like the
> current SDL parser would. As I understand it, properties are set *after* object
> instantiation, even if they are evaluated before the instantiation.

Hm, maybe then I'm mistaken indeed. I'll have to investigate that.

But even then I must say that I'd actually not like the syntax - for POV needs,
it would mean an unreasonably large number of braces-inside-parentheses "({ ...
})" where only one type of brackets would suffice; and a host of "new"
statements which - as proven by current SDL - shouldn't really be necessary.
Not to speak of all the colons (":").

> The JavaScript way seems better than the 'predefined parameters' approach of
> most other languages, even when (with other languages) overloaded constructors
> (variants that have different types or number of parameters) are specified in
> the class.
>
>
> One weakness I see with this approach, is when POV-Ray SDL containers may have a
> number of children, e.g. with CSG, it might be better to use a ".add(new ...)"
> method call to add child objects to the list.

Shouldn't that, too, be possible using

new scene ({
    object: new sphere ({ ... }),
    object: new box ({ ... }),
    ...
})

(at least if I understand you correctly about the 'set' methods mentioned)


> (With apologies if I'm going over unnecessary background information; I don't
> know how much you, or a typical reader, knows about JavaScript or OO).

No problem here - I think the level of detail is just about right for me ;)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> But even then I must say that I'd actually not like the syntax -
> for POV needs, it would mean an unreasonably large number of
> braces-inside-parentheses "({ ... })" where only one type of
> brackets would suffice; and a host of "new" statements which -
> as proven by current SDL - shouldn't really be necessary.
> Not to speak of all the colons (":").

There's always the option of inserting a pre-processor into the pipeline, which
could assume new objects if an object class is supplied, or existing objects if
its reference is supplied; no need for "new" in the user's SDL source. The
properties would have obvious "property value" construction.

My overall thought is that we could use existing language parsers/compilers, to
take advantage of the superior structuring, and pre-process any POV object
definitions into that language, so that users can create appropriately precise
SDL source.

p.s. I might be confusing some Java concepts with JavaScript concepts, thinking
in particular about the class structuring that JavaScript might not support -
apologies for that; I learned [sic] the two at around the same time. Even so,
then

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> > > > Sph = new Sphere( {
> > > >   radius: 1,
> > > >   position: [0,0,1]
> > > > } );
> > Can you explain your thoughts on what the problem will be with this approach?
> > Are you thinking of transformations? Method-triggering property
> > assignments ('set' methods) achieve this, e.g. a "translate: [1,0,0]" property
> > would call ".doTranslate([1,0,0])" to change the transform matrix just like the
> > current SDL parser would. As I understand it, properties are set *after* object
> > instantiation, even if they are evaluated before the instantiation.
>
> Hm, maybe then I'm mistaken indeed. I'll have to investigate that.

I just checked this, to find that what the construct will actually do is:

temp = new Object();
temp.radius = 1;
temp.position= [0,0,1];
Sph = new Sphere(temp);

This also matches what the ISO ECMAScript specification implies.

So at the point e.g. the "position" property is set, it will still use the
standard getter/setter mechanism of the basic Object type.

Furthermore, it will not act on the Sphere object at all - it will just create
yet another object that will be passed as one single parameter to the Sphere
object.

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> clipka wrote:
> > Hmm... at first glance I thought it could do the desired thing - but it can't.
> > How, for instance, would the following translate?
> >
> > sphere { <x,y,z>, r
> >     translate <a,b,c>
> >     pigment { ... }
> >     translate <d,e,f>
> > }
> >
> > Filing both translate statements as "translate" in the hash map would overwrite
> > the first of them. Just combining the two would fail to properly affect the
> > pigment.
>
> True, but in this case maybe it's better to force the user to substitute
> a better solution? I.e.:
>
>  scene.objects.MySphere.translation += <d,e,f>

Yuck!

You really want to script scenes using statements like

scene.objects.MySphere.material.finish.pigment[2].pattern.translation +=
<a,b,c>?

Not me!

Also note that below the hood, again with the sphere example in mind, this is
not just about changing the "translation" property of a geometric object - it
also must act on the "translation" properties of any patterns associated with
it at that very moment (e.g. pigment patterns).


> While having XML *and* a scripting language might be yucky, I think that
> using separate conventions for content and behavior is a *good idea*.
> And, hash arrays are good in this regard.

Can you give an example about how this separation would look like?

I guess I'm not getting the picture you're aiming at right now.

Also note that functions must be part of the content (to allow for modelling
isosurfaces, function patterns and such), while at the same time they may come
in handy as part of the scripting, too. And as soon as you're using trace(),
you mix the two anyway.

The result of a strict separation can be seen for instance in various
JavaScript-based dynamic HTML pages: Where content and behavior mix, web
designers are forced to either include the behaviour with the content
(JavaScript elements inside the HTML page), or pull some of the content into
the behavior (separate JavaScript files generating HTML code "on the fly"). The
result is an ugly hodgepodge of two entirely different languages.

Therefore, I strongly advocate a single language to drive both form and
behavior, because in a lot of POV-Ray scenes behavior will be used to
auto-generate content.

It's a different thing when the intention is to script a scene for an animation.
However, in that case, nothing stops you as the user from separating content and
behavior by using include file mechanisms.

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> "clipka" <nomail@nomail> wrote:
> > But even then I must say that I'd actually not like the syntax -
> > for POV needs, it would mean an unreasonably large number of
> > braces-inside-parentheses "({ ... })" where only one type of
> > brackets would suffice; and a host of "new" statements which -
> > as proven by current SDL - shouldn't really be necessary.
> > Not to speak of all the colons (":").
>
> There's always the option of inserting a pre-processor into the pipeline,

I guess I'm overusing the word in this thread, but: Yuck!

That one would have to parse the language anyway, wouldn't it? I mean, as long
as we intend it to increase conciseness instead of adding just more overhead.

Plus, I think it would be nice to have a feature as in JavaScript or Lua to take
a string and interpret it as a piece of code. A preprocessor wouldn't be able to
catch that, and people would (righteously) complain why some language constructs
don't work in that case.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Plus, I think it would be nice to have a feature as in JavaScript or Lua to take
> a string and interpret it as a piece of code.

I very nearly suggested the same myself when thinking about post-constructor
code, but decided to keep the proposition uncomplicated :o)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> > "clipka" <nomail@nomail> wrote:
> > > But even then I must say that I'd actually not like the syntax -
> > > for POV needs, it would mean an unreasonably large number of
> > > braces-inside-parentheses "({ ... })" where only one type of
> > > brackets would suffice; and a host of "new" statements which -
> > > as proven by current SDL - shouldn't really be necessary.
> > > Not to speak of all the colons (":").
> >
> > There's always the option of inserting a pre-processor into the pipeline,
>
> I guess I'm overusing the word in this thread, but: Yuck!
>
> That one would have to parse the language anyway, wouldn't it? I mean, as long
> as we intend it to increase conciseness instead of adding just more overhead.
>
> Plus, I think it would be nice to have a feature as in JavaScript or Lua to take
> a string and interpret it as a piece of code. A preprocessor wouldn't be able to
> catch that, and people would (righteously) complain why some language constructs
> don't work in that case.

While again not talking that seriously, Lisp macros are known to do just that:
create parsers for new languages with relatively ease.  For instance:

(define-syntax pigment
    (syntax-rules (color-map checker bozo granite marble)
      ((pigment "skel" str)
       (string-append "pigment {" str
                      "}\n"))
      ((pigment checker (x1 y1 z1) (x2 y2 z2))
       (pigment "skel"
         (let ((ns number->string))
           (string-append "checker rgb <" (ns x1)","(ns y1)","(ns z1)
                          "> rgb <" (ns x2)","(ns y2)","(ns z2)">"))))
      ((pigment checker c1 c2)
       (pigment "skel" (let ((ss symbol->string))
                         (string-append "checker color " (ss (quote c1)) " color
" (ss (quote c2))))))
      ((pigment color-map c1 c2 ...)
       (pigment "skel" (string-append "  color_map {\n" #\newline
                                      "  }\n")))))

This should be sufficient to generate a few well-known pattern of use:

> (display (pigment checker black white))
pigment {checker color black color white}
> (display (pigment checker (1 0 0) (0 0 1)))
pigment {checker rgb <1,0,0> rgb <0,0,1>}

Unfortunately, I'm out of time right now... :P

Post a reply to this message