"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> > Doesn't JavaScript have the ability to assign properties [...]
> >
> > Sph = new Sphere( {
> >   radius: 1,
> >   position: [0,0,1]
> > } );

> A host of languages has this.
>
> The problem is still the scope: However you toss and turn it, you can't just
> go ahead and do some stuff in the new object's scope (or "namespace" or
> however you want to call it) without some added hassle.
>
> The problem is that all mainstream languages do initialization of an
> object by passing some expressions as parameters, with the expressions
> being evaluated in the scope of the calling block. Plus they're
> evaluated before the object is created, so can't have side effects on
> the object.

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.

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.

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.

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

Post a reply to this message

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>


>> Alternately, we could differentiate
>> the content and behavior by using separate sections and languages for
>> each (i.e. HTML and JavaScript in web pages).
> 
> Yuck. We see that in the current SDL. It can be quite powerful, but it's not
> really the way to go.

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.

I don't think using functions (i.e. keywords followed by parentheses) 
for everything is the way to go.

-Mike

Post a reply to this message

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