scott wrote:
> I wonder if it would it be possible for POV to expose its core functions 
> in a standard way (eg in a dll for windows), and then you can access 
> them from any programming language you like.  The SDL parser just needs 
> to be a special case that parses the file and calls the same POV core 
> functions that you can from your own code.

I think this came up a number of times in the past. I remember getting 
brutalized for suggesting CIL ;-)

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

On 07/24/09 09:51, David H. Burns wrote:
> I think the concept of "object" is a real advance in programming but
> "OOP" seems
> a lot more than simpling making use of "objects" which "contain" both
> data members
> and functions ("methods")

	As I said before, you have a "ball" variable, which is just a sphere 
with everything you've defined (coordinates, texture, etc).

	It has data members, which would be the aforementioned items 
(coordinates, pigments, etc). It also may have methods, like rotate, 
translate, etc. You could do:

ball.translate(1, 3, 5)

	to translate it by <1, 3, 5>.


	(The syntax may be a bit different - that's a minor issue).

	I think you're worried that you'll somehow have to put all your code 
into the methods of objects. Heck, for simple scenes, I doubt you'll 
have to code _any_ methods. POV-Ray will provide standard methods to all 
objects (like rotate, translate, etc), which you will merely use.

	If you want to do regular for loops, etc, it need not be part of any 
object method, but in your "regular" code. No one said that the new SDL 
will force everything to reside in an object like Java does.

-- 
Cut my pizza in six slices, please; I can't eat eight.

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I do kind of think
> in terms of "objects" when using Pov-Ray, but I wouldn't call that "OOP
> (= Object
> Oriented Programming) thinking", even if that phrase means
> anything--which I doubt.

Well, I do agree that "OOP thinking" is somewhat fuzzy.

Let me rephrase the whole smash like this:

What others call "OOP thinking" might be more familiar to you than you may be
aware of.


> It might be more accurate to say that I am writing code which conforms
> to the syntax dictated by
> the SDL -- regardless of what kind of thinking leads to it. As I have
> said several times before:

> I think the concept of "object" is a real advance in programming but
> "OOP" seems
> a lot more than simpling making use of "objects" which "contain" both
> data members
> and functions ("methods")

Yes; what you describe would be "encapsulation", which is just one major
building block of OOP. As I mentioned earlier, another important one is
"polymorphism", which you can think of as the ability to equip multiple
different objects with methods that have the same name and parameters, but
different code to match the object's data structure. An example is POV-Ray's
"sphere", "box" and all the other primitives using the very same syntax to
transform, apply textures, etc.

A third concept frequently encountered in OOP, "inheritance", on the other hand,
is in my eyes not really an essential part of OOP, but instead just a mechanism
(albeit a powerful one) to manage issues arising from polymorphism, both
regarding redundancy (different objects may be similar enough that parts of
their data structures and methods can be implemented in the very same way, so
it would be a waste of time to write and maintain that same code twice) as well
as object compatibility (compile-time detection of potential attempts to invoke
methods on objects that don't have them).

Atop of this are a bunch of design patterns which are associated with OOP,
probably for the sole reason that they're making such heavy use of
encapsulation and polymorphism that it would be extremely cumbersome to express
them in a non-OOP language.

Some other stuff often associated with OOP languages just happen to have become
popular in mainstream languages at the same time as OOP; for instance
"overloading" of functons (defining multiple functions of the same name but
with different parameter types); model-view-controller architecture (dividing
an application into three components referred to as model, view and
controller); to name a few examples.


>
> >you only know how
> > typical end results from such thought processes look like, when formulated in a
> > general-purpose language retrofitted to better support such formulations
> > ("better" as in "better than nothing") - a language which, by the way, would
> > surely happen to be unsuited for a POV-Ray SDL.
>
> This seems to be true, where would I find some *real* OOP to look at?

I don't know whether there exists such a thing as "real OOP to look at".
Whatever code you look at, if you're not familiar with the language you'll
probably see more of the language's peculiaritis than you'll see of the
programmer's original thoughts.

Academic languages are peculiar anyway; and non-academic languages tend to
accumulate traits over time that are peculiar because the original language
didn't have them.

In the case of POV-Ray, I still have to come across some language that wouldn't
outweigh the benefits by its peculiarities. The current POV-Ray SDL is so
well-suited to its basic task that it would be imprudent to go very far from
that, as far as the effective syntax is concerned. The only problem with it is
that it is particularly ill-suited for the non-basic tasks people want to use
it for these days. It is exceptionally good for *describing* a scene, but also
exceptionally bad for *generating* it (which doesn't mean it lacks the power;
being Turing-complete, you can do anything with the currend SDL; but what it
does lack is performance, some more consistency, and some more support for
OOP).

So what I'd go for is a language that is deliberately designed to be very
remniscient of the current SDL when it comes to describing scene elements, and
as straightforward when it comes to simple scene-generation tasks (like, say,
placing 100 spheres in a row) - any language imposing some overhead for these
two would be ill-suited for POV-Ray.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I think this came up a number of times in the past. I remember getting
> brutalized for suggesting CIL ;-)

.... and rightly so ;)

Post a reply to this message

Thanks. This is the best and most concise explanation of the basic 
tenets of OOP that
I have read. Much better, for instance, than that in "OOP for Dummies".
clipka wrote:





>> This seems to be true, where would I find some *real* OOP to look at?
> 
> I don't know whether there exists such a thing as "real OOP to look at".
> Whatever code you look at, if you're not familiar with the language you'll
> probably see more of the language's peculiaritis than you'll see of the
> programmer's original thoughts.

Perhaps I should have said where could I find some simple examples of 
good OOP
programming. Any that would be very useful to me might be hard to find. 
I have some
Python code for producing a Windows GUI "wrapper" around old Fortran 
code. The results
are quite impressive. It's likely that this code would be as good 
example as I can find --
though it's not especially simple.
> 
> Academic languages are peculiar anyway; and non-academic languages tend to
> accumulate traits over time that are peculiar because the original language
> didn't have them.
> 
  The current POV-Ray SDL is so
> well-suited to its basic task that it would be imprudent to go very far from
> that, as far as the effective syntax is concerned.
Amen!


:) David

Post a reply to this message

David H. Burns wrote:
> Chambers wrote:
>> Just out of curiosity (but you keep saying things like this, so I have 
>> to ask), where have you seen OOP programming?
>>
> 
> Your point is well taken. I have *never* seen OOP *programming*.

<snip>

> To actually see OOP "programming", I suppose I would have to see some 
> one actually coding in OOP.

I don't think you understood my point.  I'm not talking about watching 
someone as they write code.  I'm talking about the source code itself.

What source code have you seen that scared you so badly away from OOP?

My guess (and it's just a hunch at this point), is that the OOP itself 
isn't what scared you, but rather the complexity of the program.  If 
this is the case, then you're almost certainly guaranteed that the 
program would have looked *worse* if it weren't OO.

Something that people don't tend to believe: programming is *hard*.  It 
is *not* a simple matter to sit down with a sheet of requirements, and 
pound out the class (though having a properly written spec makes it 
easier).  And, believe it or not, most programmers' jobs could *not* be 
done by a bunch of monkeys.

It's not for everyone, and some people are more suited to using the 
programs they have than writing new ones.

-- 
Chambers

Post a reply to this message

clipka wrote:
> Chambers <Ben### [at] gmailcom_no_underscores> wrote:
>>>> Shouldn't that be "the Buck"? ;)
>>> ??
>> As in, David K Buck :)
> 
> Ah - now here comes light ;)
> 
> But no: Leader of the dev team is currently Chris Cason :P

I know, but I find it hard to pass up an opportunity for a good pun :)

-- 
Chambers

Post a reply to this message

clipka wrote:
> (BTW, did you know that your working style costs jobs? 'Cause as long as people
> program software instead of developing it, you can't just outsource the coding
> part to India... :P)

In other words, he saves money by not creating *extra* work that his 
employers have to pay for.

Way to go Darren, you deserve a raise! :)

-- 
Chambers

Post a reply to this message

scott wrote:
> I wonder if it would it be possible for POV to expose its core functions 
> in a standard way (eg in a dll for windows), and then you can access 
> them from any programming language you like.

I propose Ook!

-- 
Chambers

Post a reply to this message

Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>> Invisible wrote:
> 
>>> 2. What would be so bad about this being true?
>> It would be too complex to be usable by ordinary folk (i.e. me).
> 
>   And exactly how do you know this?
> 

OOP is the first three letters of oops!

Post a reply to this message