-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolas Alvarez wrote:
> What do you mean "C/C++ does not"? When have you needed to recompile all
> libraries before compiling a C++ program? Even within the same project,
> if you change a single file, you can recompile that single file.

He meant that you can't compile against a library unless you have the
header source files for that library.

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you've tried to scan your
face for a texture.
    -- Quietly Watching
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBu3FcCmTzQ++ZncRAvzNAKCbrDKZJDw92WAIcQTTLNXykrwPAwCgotBP
r4oIlN2tbYWGfKz/fNd/Gqw=
=qAPy
-----END PGP SIGNATURE-----

Post a reply to this message

Fa3ien wrote:
> ....unreadable as hell.  I would loved to be able to do
>  Window {height = 250 width = 130 mullion_thickness = 5 ...}
> in any order, and with default values.

I wrote a macro preprocessor to do exactly that sort of thing, for 
exactly the same reason. Imagine that. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

I personally would appreciate a brand new SDL syntax, especially if it
similar to Java.
The attempt Bruno made using Classes to create objects sounds very
interesting to me, especially as it would be easy to create specialized
Classes by sub-classing as you can do with Java.
Example: The class "Glass" defines the standard glass parameters like ior,
reflectiveness, color, transparency and so on. The sub-class "Crystal" may
overwrite the parameters necessary to create a crystal-like texture.

IMHO the most people using POV-ray by writing the SDL by hand (as opposite
to using a graphical modeler) have at least some programming experience,
either Java or .NET.

- Wolf

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> I had a macro like this :
>   #macro Window (Height,Width,TopArc,MullionThick,...) //many parameters

> When invoked, it looked like :
>   Window (250,300,25,5,2,1,1,4,6,120,5)

> ...unreadable as hell.  I would loved to be able to do
>   Window {height = 250 width = 130 mullion_thickness = 5 ...}
> in any order, and with default values.

  You know, you can write /* comments */.

-- 
                                                          - Warp

Post a reply to this message

"Wolf" <nomail@nomail> wrote:
> IMHO the most people using POV-ray by writing the SDL by hand (as opposite
> to using a graphical modeler) have at least some programming experience,
> either Java or .NET.

or Lisp and Python.

BTW, Python accepts named parameters to functions and default values to
parameters.  Let's not forget python is an option -- although slow, but not
nearly as much as the current SDL -- as embbedable scripting engine hooking
directly to C/C++ code underneath...

like:

class GlassSphere( Sphere ):
  def __init__( self, pos = 0, radius = 1, ior = 1.4 ):
    Sphere.__init__( self, pos, radius )
    self.material = materials.Glass( ior )

you then may call it:
sph = GlassSphere( 0, 1, 1.4 )

or:
sph = GlassSphere( ior = 1.2 )

or:
sph = GlassSphere( ior = 1.2, radius = 3 )

or even:
sph = GlassSphere()
sph.ior = 1.2

etc.

A Basic povray scene with just a glass sphere over checkered board and light
could be expressed just as:

GlassSphere()
Plane( y, -1, Pigment( Checker( 0, 1 ) ) )
LightSource( (-5,5,-5) )

which is currently less than with current SDL syntax, which requires
position and radius of sphere.  The python version doesn't, because it gets
default parameters.

What people should understand is that classes allow for far more modular,
reusable and easier way to define objects rather than the macros and local
variables approach.  In my simple example, I've defined a new object type
which inherits behaviour from a predefined povray object (Sphere) and can
easily extend the base class by adding or overriding behaviour via method
definitions.  It's much more than macros which really just define the
constructor and have to take explicit parameters because the SDL lacks
lexical scoping to share modules variables of sort.

yes, Python also supports multiple inheritance as well as a simple interface
system by the name "duck typing"...

I don't have a problem with structured programming by indentation...

BTW, just about as nice as Python or moreso is Ruby, which has not been
mentioned so far...

Post a reply to this message

Wolf nous apporta ses lumieres en ce 2007/10/06 04:57:
> I personally would appreciate a brand new SDL syntax, especially if it
> similar to Java.
> The attempt Bruno made using Classes to create objects sounds very
> interesting to me, especially as it would be easy to create specialized
> Classes by sub-classing as you can do with Java.
> Example: The class "Glass" defines the standard glass parameters like ior,
> reflectiveness, color, transparency and so on. The sub-class "Crystal" may
> overwrite the parameters necessary to create a crystal-like texture.
> 
> IMHO the most people using POV-ray by writing the SDL by hand (as opposite
> to using a graphical modeler) have at least some programming experience,
> either Java or .NET.
> 
> - Wolf
> 
> 
> 
It would'nt be a viable option, as it would prevent you from using ANY existing 
scene, break all actual librarys and piss off a majority of users.

You make strange assumptions regarding typical POV-Ray users.

I don't use a modeler, but I've tried. I don't have any Java nor .NET 
experience, I've not even read any documentation about either. It easier for me 
to do things directly in SDL rather than use a modeler.
I do have some old programing experience using Basic (about 12 years old), 
Pascal (about 20 years old), C/C++ (about 10 years old) and Fortran (over 25 
years old).

-- 
Alain
-------------------------------------------------
Three can keep a secret, if two of them are dead.
Benjamin Franklin

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> "Wolf" <nomail@nomail> wrote:
> > IMHO the most people using POV-ray by writing the SDL by hand (as opposite
> > to using a graphical modeler) have at least some programming experience,
> > either Java or .NET.
>
> or Lisp and Python.

.... or any other language.
My point is that I think there is no need to define the new SDL in a way
somebody having never done any programming can deal with it.
Those people will probably go for a graphical modeler anyway.

- Wolf

Post a reply to this message

"Wolf" <nomail@nomail> wrote:
> My point is that I think there is no need to define the new SDL in a way
> somebody having never done any programming can deal with it.
> Those people will probably go for a graphical modeler anyway.

how about a poll?

But I'm not sure it's true that users of povray SDL have programming
experience.  Of course, most of the heavy users are old timers from a time
when visual modellers were science fiction stuff and the command-line was
king.

Still, I don't think visual modellers are a good substitute for a well
designed language.

They are in fact just as much of a hinderance to productivity as the mouse.
When you're a beginner, the mouse may help you by letting you visualize and
choose options in a menu, but once you've done that 100 times a day,
there's no good substitute for a keyboard shortcut...  Likewise, visual
modellers may have some appeal by letting you choose options and link
visual boxes with arrows, but soon you'll find it cumbersome and willing to
just spell pigment { foo } rather than drop a pigment box inside a texture
box and that inside a material box...

Post a reply to this message

> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> I had a macro like this :
>>   #macro Window (Height,Width,TopArc,MullionThick,...) //many parameters
> 
>> When invoked, it looked like :
>>   Window (250,300,25,5,2,1,1,4,6,120,5)
> 
>> ...unreadable as hell.  I would loved to be able to do
>>   Window {height = 250 width = 130 mullion_thickness = 5 ...}
>> in any order, and with default values.
> 
>   You know, you can write /* comments */.

Yes, I could.
But I still have to
- specify ALL paramters
- specify them in strict order

With built-in functions, i can write :
light_source {... area_light ... circular orient adaptive 2}
or, as well
light_source {... area_light ... adaptive 2 orient circular}

I know that almost no programming language allows that kind
of parsing feature in user-defined functions, but I regret it.

Fabien.

Post a reply to this message

4707ba6b$1@news.povray.org...
> Yes, I could.
> But I still have to
> - specify ALL paramters
> - specify them in strict order
>
I agree !
That's the main reason why when I write a macro, I limit the number of 
parameters even if I'd wish to put a lot more to cover more cases

Marc (not a programmer)

Post a reply to this message