Olin Lathrop wrote:
>> I should get a handle on
>> these concepts instead of spending your time saving face with
>> uniformed responses such as "that's a moot point".

>That's really arrogant for someone that has asked a lot of stupid questions
here lately.  Vitali's first language isn't english, although he does quite
well with it. <

Sadly, at this point I am more fluent in English than in any other language. 
"Use it, or lose it." :-(

> A better response might have been "whatever", which basically
says, "Look, this is immaterial to the larger point at hand.  You may be
right, but it really doesn't matter.  It would be nice if you stopped
wasting time and derailing the thread with nitpicks so we can discuss the
main point.". <

You could interpret it that way, but I really consider it to be a moot 
point. You can't really "use" a class, except to instantiate an object. On 
the other hand, by definition you cannot have an object without 
instantiating it from a class. Classes in the true OOP sense also have 
certain attributes, for example it is assumed that you should be able to 
derive new classes that inherit the behavior of their parent classes.

What I have (for the sake of this example), is a class called uart.c, with a 
corresponding uart.h file. Uart.c has some private functions and data, and 
public "methods" exposed via the uart.h file. I can do things like:

Uart_SendMessage("Hello World");
Uart_SetBaudRate(115200);

..without instantiating the Uart object. And in the current implementation, 
there are no provisions for inheritance, or deriving multiple instances of 
Uart.

I prefer to think of these chunks of related code and data as "objects", but 
I'm fine with someone else referring to them as "classes". Arguing in favor 
of one over the other is like arguing whether the armadillo is a porcupine 
or a turtle.

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist