Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> > some years ago, I had to produce individual images of a great number of
> > windows.
> > 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.

here:

#local Height = 250;
#local Width = 300;
#local TopArc = 25;
#local MullionThick = 5;
Window (Height,Width,TopArc,MullionThick,...) //many parameters

it's pure idiomatic povray SDL and well-known.

Of course, real named parameters accept parameters given in any order.

> > This is an example where an apparently more complex syntax
> > leads to easier understanding.

yes, it makes it easier.  But it's not like current SDL prevents it.

> Well, most languages don't have named parameters. But you can do this in
> OOP languages:
> Window w = new Window();
> w.height=250;
> w.width=130;
> ...
> w.createForReal(); //this creates the actual POV object

I don't like this idiom too much:  it only works if you know the required
parameters to the function, which means you know the inner workings of the
function and is kissing encapsulation and abstraction bye-bye.  What
happens if you forget about providing one of them or doesn't update it
before calling?  bad things happen, in my experience.

Positional parameter passing provide the strongest contract for function
application, that's why it's the default in most languages.

You can of course get around this somewhat by providing default values
inside the function for the case it's missing.  And this is indeed another
old time povray SDL idiom, used from times even before to macros...

> None of the three (real named params, the idiom using constructors, or
> changing properties) can be done with POV-Ray currently... Yep, we
> really need a new language :)

this of course is not true.  But surely it could be improved.

Post a reply to this message