#declare headRotation= 90*y*clock;
#include "myIncWhichDeclaresObjectNamedBody.inc"
object {body transform{someTransform} etc.}


Suppose you've declared an object in povray as above.
Stepping back to a discussion of the philosophy of programming, exactly how is
this object similar and how is it different from an Objective-C object?
(Not quite interested in Java, Smalltalk objects for now.)

Post a reply to this message

Le 20/10/2012 16:53, gregjohn nous fit lire :
> #declare headRotation= 90*y*clock;
> #include "myIncWhichDeclaresObjectNamedBody.inc"
> object {body transform{someTransform} etc.}
> 
> 
> Suppose you've declared an object in povray as above.
> Stepping back to a discussion of the philosophy of programming, exactly how is
> this object similar and how is it different from an Objective-C object?
> (Not quite interested in Java, Smalltalk objects for now.)
> 

differences:
* Inheritance
* Messages (as specified by objective C)

Philosophically, objects in Povray are to objects in Objective C what
bicycle are to air-plane in transportation (or vice-versa).

http://en.wikipedia.org/wiki/Objective-C



object {}: this actually creates an instance/clone of body and applies
the transformation on it.

There is no inheritance in Povray SDL. (or did I missed that ?)
There is no messages/function to be called on object (once created, an
object often become a closed container that you cannot read back or
alter (excepted by cloning, or some specific functions which expect to
be provided an object))

Notice that Objective C took its convention from smalltalk (to extend
the basic C) so avoiding any smalltalk is going to be difficult.

A chair in povray is an object of the scene.
A chair-object in objective C is first an abstraction of a interface and
might as well be some instance of it. (there is class methods and
instance methods, not the same things)


An object in povray is:
 * a textured 2D-shape immersed in 3D, which might also split the 3D
space between two parts(the inside and the outside), with different
properties. The object might be part of the scene, or it might also not
appear in it.

An object in programming language is:
 * an encapsulation of some parts of a modelling (appropriate for the
problem to be solved), whose purpose is to reduce the complexity of the
whole issue by splitting it in multiple smaller problems, hopefully
disconnect-able, and with a reduced set of interactions with other objects.

Post a reply to this message

gregjohn <pte### [at] yahoocom> wrote:
> #declare headRotation= 90*y*clock;
> #include "myIncWhichDeclaresObjectNamedBody.inc"
> object {body transform{someTransform} etc.}

> Suppose you've declared an object in povray as above.
> Stepping back to a discussion of the philosophy of programming, exactly how is
> this object similar and how is it different from an Objective-C object?
> (Not quite interested in Java, Smalltalk objects for now.)

I think you are committing a fallacy of equivocation here.

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
>
>
> object {}: this actually creates an instance/clone of body and applies
> the transformation on it.
>

Thanks.
If I were to repeatedly call this "declare headRotation" and "include ..."
above,  is that in any way like messaging an object?  Does my "body" become like
an instance variable?

My purpose here is to wrap my head around ObjC.  Didn't mean to diss Smalltalk,
but I've seen some tutes that assume you have a PhD in one of the other
object-oriented languages and limit their explanations to folks with that
expertise.

Post a reply to this message

gregjohn <pte### [at] yahoocom> wrote:
> My purpose here is to wrap my head around ObjC.

An object is an instantiation of a class. (In ObjC such an instantiation
is created by calling the 'alloc' method of such a class, and then calling
a constructor to initialize it.)

There are two things that make an object special and different from other
types of first-class citizens (such as ints): They (may) have methods (ie.
member functions), and the object you are handling might actually be of a
different (but usually inherited) type than what the actual code says.

In other words, if a function takes, for example, a parameter of type
MyClass*, then it may be called with an object that's actually not of
type MyClass but something else. (Usually it will be an object of a class
that has been derived from MyClass.)

You can then call the methods of that object (or, more technically speaking
in the context of Objective C, send a message to it). The method
implementations may be those that were implemented for MyClass, or they
might have been re-implemented in whatever derived class the object is.
(The thing is, this function doesn't need to know this in order to work.)

Since you are asking about Objective-C I'm assuming you are trying to
make an iPhone program (or at the very least a MacOS X one). Trying to
do so without understanding object-oriented programming can be a pretty
daunting task. It could take years to master.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Trying to
> do so without understanding object-oriented programming can be a pretty
> daunting task. It could take years to master.
>

http://www.youtube.com/watch?v=Hdsn5sJpL2Y

Post a reply to this message