Today, nothing prevents all the stuff we produce to be orginized more or
less like a mess. I guess it actually is for some of us, and I guarantee
you it is the case for me. The #include approach is too limited and
prevents from modularity, visibility, naming range, etc ..., and the
reusability is somewhat limited and puzzling. A well known and mature
solution for these features is Object Orientedness. Let's make POV4 be
object-oriented. Not too much, but enough to benefit of what can be good
for our purpose.

If we want (still more or less):
    - OO
    - inheritance (prevents useless re-writing of common properties)
    - modularity
    - reusability
    - visibility rules
    - locatability
    - avoid code duplication

And considering that Java was mentionned in the discussion thread as
providing such features, and considering that Java is also a very popular
language, let's try to make POV4 be inspired by Java for these aspects.
Thus, we can talk about 'packages', 'classes', and 'inheritance'. The
following lines can express that we are definig a new 'module' in our
'organisation'.


// Let's make the relationship stuff-we-write/location be bijective,
// and therefore force a minimal organisation: we express how we are
// organised, and where we locate this module in the organisation.
// Like Java, we can say that this code is in the file
// <some root directory>/household/furniture/Stool.pov4
package household.furniture;

// Reuse already defined stuff (can be/is already compiled)
import hormann.IsoWood3;
import pov.math.vector.*;
import pov.Metals;
import decoration.Velvet;
import tools.NiceStuff;

// We define a type of object 'Stool' that inherits main behaviour from
// 'FourLegged' (defined in the same package).
class Stool extends FourLegged
{
    [CLASS_BODY]
}

It is quite direct from Java, but it is not much of a problem at this level:
Java's OK for that according to me. Only this can satisfy the main
structural concerns, whatever we put in the [CLASS_BODY]. And the code is
as compact as POV.

The use of a Stool in a scene could be like:

package scenes.rooms;

// Only a scene is renderable. The name 'RoomByNight' can be used as the
// default name for the output image.
scene RoomByNight
{
    global_settings {...}
    light_source {...}

    // The stool. POV-like syntax, as if it were a primitive object. Can be
    // considered as a POV-like notational shortcut for a constructor.
    Stool
    {
        [stool properties]
    }
}

Until now, POV is C-like syntax and is limited. Why not Java-like
features/syntax for some aspects? For the rest of the language and
features, we can see later what syntax is most appropriate.

My idea here is to find an agreement on this main structural aspect. These
lines are just an example, an effective start point to help thinking. There
are surely pros and contras.

Comments welcome.

Post a reply to this message