What is an Object
-
I think you just confirmed my conclusion: . . . . Object is an ambiguous term. The only non-ambiguous terms are class and instance which we should use more often. I do not think there is a single definition for object. Its meaning depends on the context of the discussion, the language, etc. Since most often C++ is used in a Microsoft environment, then in general you can say that the base class of all classes is Object. It only shows there is another definition for the term Object. That is the relevant point. Please note the phrases "most often" and "in general". There are probably exceptions. Still, I suspect that even other implementations of C++ have a base class Object. I have looked around and find Object is often the base class in many implementations of Java. Even some of the newer versions of ancient Lisp/Scheme that have added OOP use Object as the base class. I was very surprised at how consistent that usage is.
So many years of programming I have forgotten more languages than I know.
Unfortunately, class and instance may be unambiguous (or less ambiguous anyway), but don't generalise well as not every object-oriented language has classes. Both JavaScript and Self support object-oriented programming in which slots (member variables) and methods are defined directly on objects. As far as I am aware though, every object-oriented programming language supports objects that hold (ideally encapsulated) data and respond to messages (method calls, member function invocations) in some way. That pretty well sums up the role of an object. The rest is all how particular environments implement that. I'd dispute that "most often C++ is used in a Microsoft environment". I suspect its used much, much more on Linux and (in the form of Objective C++) on Macintosh and i-Whatever platforms. Its also used in a vast number of embedded systems ranging from phones to mars rovers. While Microsoft's MFC class library is rooted in Object, their ATL library is not. Apple use an NSObject as the root of theirs (although not every class needs inherit from NSObject). Most C++ coding actually tends not to use class hierarchies that much - most of the C++ classes I've encountered either do not inherit anything, or from a base class that does not inherit from a common "Object" class. This becomes particularly necessary in the presence of multiple inheritance. Indeed most of the standard C++ library does not even define the base classes. For example, a library must provide a std::vector class, but that class may nor may not inherit from other classes as an implementation decision - it simply has to offer a certain interface (better described in C++ terminology as a Concept). Indeed many objects in C++ are pretty abstract - like iterators, containers, etc. which all behave similarly but have no relationship through inheritance.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Not at all. A normal method of a class (an instance method) has a hidden "this" parameter passed at run time. Any virtual methods defined on the class use "this" to provide access to the vtable, used to resolve virtual methods. In contrast, a static method has no "this" parameter at all, it does not get passed a reference to the class object. In this sense, they are exactly analogous in the way they are implemented to global variables and functions. The only (slight) benefit offered is a degree of encapsulation. C#, C++ and Java do resolve virtual methods dynamically, by looking them up in a vtable at run time. That is the definition of polymorphism. Its not as dynamic as message resolution in dynamic languages, but its all they offer. Gilad Bracha (one of the people who defined the JVM) is eminently more qualified than me to point out the issues with this, and has done so eloquently over at Room 101[^].
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
99% correct. Everything is right, except for the first line: "Not at all". ;P They are implemented differently, yes. But this has nothing to do with the definition of Object. You seem to fail to completely grasp the difference between the concept of object and the implementation of the concept in the language. If "An object is something that has methods and properties", you must accept that classes in C# are, in fact, objects. Special ones, implemented differently, but the concept has nothing to do with the implementation. Static methods can access static variables and nothing else. This is the exact definition of object. Right or wrong, useful or dangerous, like it or not ;) I agree with everything you say, but it's not a point, just a technical digression. Classes are objects? Let's see... It has properties? Mmmmm, yes, it can. It has methods? Again, yes. Ipso facto, in C# a class can be an object. Everything else is simply judging the pros and cons of the actual implementation (which I agree with you 100%). Bye!
-
99% correct. Everything is right, except for the first line: "Not at all". ;P They are implemented differently, yes. But this has nothing to do with the definition of Object. You seem to fail to completely grasp the difference between the concept of object and the implementation of the concept in the language. If "An object is something that has methods and properties", you must accept that classes in C# are, in fact, objects. Special ones, implemented differently, but the concept has nothing to do with the implementation. Static methods can access static variables and nothing else. This is the exact definition of object. Right or wrong, useful or dangerous, like it or not ;) I agree with everything you say, but it's not a point, just a technical digression. Classes are objects? Let's see... It has properties? Mmmmm, yes, it can. It has methods? Again, yes. Ipso facto, in C# a class can be an object. Everything else is simply judging the pros and cons of the actual implementation (which I agree with you 100%). Bye!
OK, in which case they are just extremely badly designed objects. They inhibit testability, break the Single Responsibility Principle (because a "class" now declares 2 objects), the Open-Closed Principle (because they inhibit "open for extension"), the Liskov Substitution Principle (because they cannot be substituted by anything), the Interface Segregation Principle (because a class cannot declare an interface for static members) and the Dependency Inversion Principle (because they cannot be abstract). So, use of statics breaks every single one of the SOLID principles. Alan Kay (who coined the term Object-Oriented) emphasises that message-passing (polymorphism) is crucial to object-oriented programming. An object that cannot be used polymorphically is at least breaking the spirit of OOP, if not the definition.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
OK, in which case they are just extremely badly designed objects. They inhibit testability, break the Single Responsibility Principle (because a "class" now declares 2 objects), the Open-Closed Principle (because they inhibit "open for extension"), the Liskov Substitution Principle (because they cannot be substituted by anything), the Interface Segregation Principle (because a class cannot declare an interface for static members) and the Dependency Inversion Principle (because they cannot be abstract). So, use of statics breaks every single one of the SOLID principles. Alan Kay (who coined the term Object-Oriented) emphasises that message-passing (polymorphism) is crucial to object-oriented programming. An object that cannot be used polymorphically is at least breaking the spirit of OOP, if not the definition.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Agreed, 100%. :thumbsup: I was not telling in any way it's a good idea to use a lot of statics. I was just referring to an "object" strict definition.
-
Unfortunately, class and instance may be unambiguous (or less ambiguous anyway), but don't generalise well as not every object-oriented language has classes. Both JavaScript and Self support object-oriented programming in which slots (member variables) and methods are defined directly on objects. As far as I am aware though, every object-oriented programming language supports objects that hold (ideally encapsulated) data and respond to messages (method calls, member function invocations) in some way. That pretty well sums up the role of an object. The rest is all how particular environments implement that. I'd dispute that "most often C++ is used in a Microsoft environment". I suspect its used much, much more on Linux and (in the form of Objective C++) on Macintosh and i-Whatever platforms. Its also used in a vast number of embedded systems ranging from phones to mars rovers. While Microsoft's MFC class library is rooted in Object, their ATL library is not. Apple use an NSObject as the root of theirs (although not every class needs inherit from NSObject). Most C++ coding actually tends not to use class hierarchies that much - most of the C++ classes I've encountered either do not inherit anything, or from a base class that does not inherit from a common "Object" class. This becomes particularly necessary in the presence of multiple inheritance. Indeed most of the standard C++ library does not even define the base classes. For example, a library must provide a std::vector class, but that class may nor may not inherit from other classes as an implementation decision - it simply has to offer a certain interface (better described in C++ terminology as a Concept). Indeed many objects in C++ are pretty abstract - like iterators, containers, etc. which all behave similarly but have no relationship through inheritance.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
What object oriented language does not have classes? I was never able to find one. I should have been more careful in my criteria. I was referring to the amount of code use and not lines written. Consider much of Windows and its applications are based on C++. Also consider Windows used to hold a near monopoly on operating systems. I still think C++ is used most often in the Microsoft environment. That may be changing as C# gains hold and Windows loses more of its monopoly. As far as lines written I would not even venture to guess that. Also, do not confuse C with C++. I am sure C under any criteria is the most used language.
So many years of programming I have forgotten more languages than I know.
-
Agreed, 100%. :thumbsup: I was not telling in any way it's a good idea to use a lot of statics. I was just referring to an "object" strict definition.
A very interesting discussion. You both have proven the point of the original question most eloquently. Object is a very ambiguous term. Its meaning depends on the context of which is used. I wonder what the above debate would look like if you could not use the word object and could only use the terms class and instance. :omg:
So many years of programming I have forgotten more languages than I know.
-
What object oriented language does not have classes? I was never able to find one. I should have been more careful in my criteria. I was referring to the amount of code use and not lines written. Consider much of Windows and its applications are based on C++. Also consider Windows used to hold a near monopoly on operating systems. I still think C++ is used most often in the Microsoft environment. That may be changing as C# gains hold and Windows loses more of its monopoly. As far as lines written I would not even venture to guess that. Also, do not confuse C with C++. I am sure C under any criteria is the most used language.
So many years of programming I have forgotten more languages than I know.
"What object oriented language does not have classes?" - I mentioned two in the post above: JavaScript and Self. I'm not so convinced about MS's share of C++ market - witness the fact that their's is the least conformant version of C++ (compared to GCC and CLang). I think if it was still pervasive on their platform, they would have invested more effort (especially with Herb Sutter on the standards committee). I think .NET has overtaken C++, except in limited app domains such as games.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
"What object oriented language does not have classes?" - I mentioned two in the post above: JavaScript and Self. I'm not so convinced about MS's share of C++ market - witness the fact that their's is the least conformant version of C++ (compared to GCC and CLang). I think if it was still pervasive on their platform, they would have invested more effort (especially with Herb Sutter on the standards committee). I think .NET has overtaken C++, except in limited app domains such as games.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Yes, .NET has taken over everything. As you move from VB to C++ to C# you have to relearn little. Most of the program is .NET calls. Actually all the languages Java, C#, C++, etc. are actually very small. It is all the object model/libraries that surround it that do much of the work. It is often harder to learn a new object model than the language. Some of the standards committees add things to the language that are really part of the object libraries. They then call things that only implement the original language non-compliant. I think they need to split the language core from its supporting environment. That is how things really work. In standards committees each push their own environment and no body wins. The result is often garbage or it takes so long to approve that it is either irrelevant or obsolete.
So many years of programming I have forgotten more languages than I know.
-
Yes, .NET has taken over everything. As you move from VB to C++ to C# you have to relearn little. Most of the program is .NET calls. Actually all the languages Java, C#, C++, etc. are actually very small. It is all the object model/libraries that surround it that do much of the work. It is often harder to learn a new object model than the language. Some of the standards committees add things to the language that are really part of the object libraries. They then call things that only implement the original language non-compliant. I think they need to split the language core from its supporting environment. That is how things really work. In standards committees each push their own environment and no body wins. The result is often garbage or it takes so long to approve that it is either irrelevant or obsolete.
So many years of programming I have forgotten more languages than I know.
Too true, I've been trying to catch up with modern C++ developments (many of these are the language) and its just got so goddamn complex I no longer know how the hell a newcomer would begin. I was remiss earlier and neglected to provide a link to Self: Self Wikipedia[^] and Self Website[^]. It's really worth a look (although only from the point-of-view of seeing another perspective, I feel its ill-suited to modern programming). It pioneered many of the techniques we take for granted in .NET, Java and modern JavaScript - particularly in efficient VM implementation (hotspots, JITing etc.). It also introduced prototype-based programming. I'm a little biased when it comes to defining Objects - my perspective is largely informed by the original Smalltalk definitions and I cannot help feeling that not everything since then is really progress. In particular, most later languages support something based on v-tables rather than full open polymorphism, which to my mind actually limits possibilities rather than open them up. *Edit* Wow - just found an awesome video on YouTube on Self - gives some real context Self Video[^]
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Object is a universal term that can be applied to any level of abstraction. It can be an instance of a class, a smartphone, a record in a database, a document, an archive of documents and a pixel on your screen. But an object can also be other things like a rock, an animal or a song. A rock doesn't have to fit in the classification systems that scientists created and a song doesn't have to fit in the artist/genre system that the music industry has created. These objects are not (strictly) instances. So every instance is an object, but not every object is an instance. Instances always come from classes, but objects don't have to. Objects can also be born out of chaos.
.
0bx wrote:
Object is a universal term
Probably the most "correct" explanation I've come across. At least IMO ... which is probably the problem, there's no "opinion" shared by everyone. At best it's shared by most, though that particular "object" is hard to find. To turn this into a specific programming simile. To me the value inside the RAM position pointed to by an un-initialized pointer is still an "object" even though it might have no meaning in any form of any class inside the program. It certainly isn't an "instance" of any of them, except if by random chance it was.