Are Classes Objects

On the discussion on AreComponentsObjects, someone asked...

"What about Classes, AreClassesObjects?"

Classes may or may not be represented as first-class objects in your runtime environment. It depends on the language and libraries you're using.

C++: (CeePlusPlus)

There used to be no class objects, so every library vendor implemented their own. To standardize the widespread need for RunTimeTypeInformation (RTTI), ANSI adopted minimal requirements for C++ "class objects:" The typeid operator returns an instance of the type_info class, which is guaranteed to give a reasonable response for the (non-virtual) name() method. Vendors can provide more functions, but I know of none who have done anything really significant. Users can't change or extend the type_info class.

The C++ "class object" discussion can sometimes get confused, as "static" attributes (variables) and methods (functions) in a class are often referred to as being "defined at the class level."

Actually type_info::name() is not guaranteed to returning anything useful. The CppStandard says it may be a null-terminated string. You certainly can't rely on, eg, different types yielding different names. 

 - - -
JavaLanguage:

There's an instance of java.lang.Class for every class (and for a few other things too), and you can use the reflection library (java.lang.reflect) to obtain lots of meta-information about the language objects in the runtime environment. (Reflection has instances for many more language objects than just classes.)

MetaData support was much improved in Java 1.2 == Java2. Yet still when using the class objects, they do not really seem to be intgerated as much into the environment as they are in SmalltalkLanguage or RubyLanguage. Since many people think that using MetaData in Java should not be encouraged, this may be considered a feature. 

 - - -
SmalltalkLanguage

There is a Class class, that provides behavior inherited by each class. There is also a Metaclass class, that provides behavior of the class of every class. Class and Metaclass each inherit from Behavior, a class that provides the ability to have instances.

Every class in Smalltalk is denoted by a pair, descending from Class and Metaclass. Behavior of instances of the class are contained in its class descendent. Behavior of the class object itself is contained in its metaclass. The hierarchy is rooted in a self-referential "strange loop" that is guaranteed to produce at least one migraine before being understood.

Everything is an object in Smalltalk. Classes are just special objects that hold common behaviour etc. for a set of related objects. Every object in Smalltalk has a reference to the object representing its class. Class objects have a reference to a MetaClass! It is all very elegant - you can do the same things to Class objects as any other object; e.g. streaming, inspecting, etc. You don't need to invent new syntax for introspection.

The result is that both behavior and state can be added to classes as easily as to instances. In particular, object instantiation, initialization, instance uniquing, and so on are straightforward and elegant in comparison to Java and C++. 

 - - -
COM: (Microsoft's ComponentObjectModel)

COM has a different definition of "class" than you find in OO languages: A COM ClassObject is really an AbstractClassFactory? (AbstractFactoryPattern); it creates instances, but does not provide meta-information about them. (You get one by calling CoGetClassObject?() and giving it a GUID ClassId?.)

From ClassId?, you may be able to access the type library (through the registry), and obtain meta-information about the "classes" and interfaces. You may also be able to get this information directly from instances of objects. See the ITypeInfo interface.

However, you still don't get a real "class object" like the ones in OO implementation languages. 

 - - -
CORBA: (CommonObjectRequestBrokerArchitecture)

CORBA can provide meta-information for its interfaces, if registered in the ImplementationRepository? (IR). But the IR is optional. 

 - - -
ObjectPascal:

If you have a class TThing you can declare a type TThingClass = class of TThing. TThingClass contains all the class-methods of TThing (constructors too). TThingClass-Variables can hold references to any classes descendent from TThing. Messages sent to TThingClass-Variables can be processed polymorphically, i.e. class methods in ObjectPascal can be virtual. This is useful for factory-mechanisms. The difference to Java is the possibility to make "reflection" typesafe. 

 - - -
Contributors: JeffGrigg, AlbrechtScheidig

Is this a trick question? ;-)

I suggest taking a look at TypeObject if you're thinking more in terms of design. Otherwise, in COM, a "coclass" is the physical unit of instantiation that represents the implementation behind one or more interfaces it's based on. A class factory instantiates the coclass as an object that implements its interfaces.

If the COM component was specified in C++, I'd imagine a vtable per coclass and a memory block per instance (if there's any kind of member variable(s)) in the class representing the coclass implementation. The first thing in the memory block would be a pointer to the vtable. I'm not sure how VB or Java would do it.

--PhilipEskelin

VB and Java would have to do it the same way because COM is a binary standard. It doesn't matter whether you write your COM component in C++, Java, VB or even Haskell, from the outside it is an object: it encapsulates state and behaviour behind polymorphic interfaces (AbstractInteractions).

See ComponentFramework for some more thoughts on the issue...

--NatPryce

Right...from the client perspective a component is instantiated and interfaces are used to interact with it. Interaction protocols (AbstractInteractions) are set up to act as a contract between client and server. But an object doesn't necessarily need to facilitate this. My question about how VB or Java does it is really more a question of how its implementation behavior is allocated/managed at runtime. But I agree at the binary level COM enforces a language-independent standard for getting at it.

--PhilipEskelin

In Smalltalk and Java classes are objects.

And meta objects can be used to analyze/reflect upon them. XML also plays in as an interesting future concept in this area.

Why? How does a structured documentation format relate to reified classes?

XML carries metadata alongside its data (a description of the class alongside a description of the instance). It is being investigated (though not, so far, conclusively - but it's early days yet) as a language-independent object serialization format.

Some languages answer "yes" to AreObjectsClasses?. ;)

Moved here from SingletonPattern

It strikes me that there is a generic issue with using classes as containers of variable state. Its convenient I'm sure but it mixes levels of abstraction. Even worse it breaks distributed systems. I think this makes it unsafe.-- RichardHenderson .

I don't quite understand what you are implying. Can you give more detail along with an example of a different way of "containing variable state" -- ChuckMcCorvey

Sure. As a disclaimer I must say that my terminology may not be congruent with the rest of the world so please bear with me if I say something that seems strange. I tend to see a class as a descriptive element, much as type is a descriptive element. As such it is a logical descriptor which is interpreted to produce an instance of the class. This is its primary role. There are few architectural (physical) issues because the class has no behaviour as such. It is constant data.

Static stateless methods and constants may be introduced without changing this fact. Particularly, the class specification data may be replicated without penalty.

As soon as we put variable state in a class we introduce a behaviour which breaks this universality. We can no longer replicate the class data with impunity because the instance of the class data can now vary. This is a severe architectural constraint that makes distribution difficult. Then we have problems of multithreaded access. Again this is a severe architectural constraint, particularly producing nasty race-conditions or a heavy synchronization penalty.

This suggests to me that using classes in a "live" object sense is a poor choice. I prefer an explicitly created singular object which is then linked to class instances explicitly. This forces the behaviour to be made explicit which is a good thing because we control that. Clearly we do not control this behaviour if we leave it to the JVM implementor. A factory class can encapsulate the extra work at instantiation time and provide the lazy semantics as desired. -- RichardHenderson .

Static methods and variables always make me think that there is a hidden class trying to get out. The static class-level methods and variables of a class are really a SingletonPattern instance of some unstated class. -- JeffGrigg

Learning Smalltalk convinced me that if a language has classes in it, then they ought to be objects. But I'm becoming more and more convinced that PrototypeBasedProgramming is the way to go (especially after watching a few beginners try to wrap their heads around the difference between classes and objects). Smalltalkers might enjoy checking out the SelfLanguage; being prototype-based makes it even more flexible than Smalltalk's classes-and-metaclasses system, and it's much simpler too. -- AdamSpitz Ditto for IoLanguage -- JasonGrossman

EditText of this page (last edited September 25, 2009) or FindPage with title or text search