Is class an object in object oriented language? How are Class methods accessed by just name of the class.method name? (internal working). Is this same as a object.method?
And If the Class is same as object (belong to object class which is super class of every thing in OO) and we instantiate it (make object of it), can we make instance of an instance of an class other than Object class.
(Mainly interested in the theoretical perspective even if practically not required ever)
Well, it depends on the language that you are using; in pure OO languages where everything is an object (e.g. Smalltalk) classes are no exception and are objects too. In other languages where classes are not considered as first class citizens they are just special language constructs or primitive types. From now on I'll use Smalltalk as a target language, due to its reflection support and homogeneous style.
How Class methods are accessed by just name of the class.method name?
(internal working). Is this same as as object.method?
Since classes are objects, they are in turn instances of a class (a metaclass). Thus, sending a message to the class is just sending a message to an object whose role is to represent how classes behave. There is a lot of literature out there, you can take a look for example here and here for some introduction.
And If the Class is same as object (belong to object class which is
super class of every thing in OO) and we instantiate it (make object
of it), can we make instance of an instance of an class other than
Object class.
I'm not sure I follow you here, but just for clarification it is not always the case that Object is the superclass of all the classes. The thing is that If you start following the relationships between classes and metaclasses, you may reach a sort of infinite loop. Different languages work this out in different ways and for example, in VisualWorks Smalltalk, Object is a subclass of nil. The thing is that nil is also an object (remember, everything is an object) and it actually represents "nothing". As you may expect, nil is an instance of a class (UndefinedObject) and it also implements some of the class protocol. As a result it can be used to represent a class form where nothing is inherited :).
Finally, I don't know if this answers your question, but yes, you can do many cool things with full reflective capabilities, like creating new classes on the fly or reshaping existing ones. I'll leave you here some documents that you may find interesting regarding this topic:
Metaclasses
Understanding Metaclasses
Debugging Objects
A class isn't an object, you can think of it as a 'blueprint' for an object. It describes the shape and behaviour of that object. Objects are instances of a class.
See here for more information.
Is class a object in object oriented language?
The notion of class is first and foremost theoretical. You can define a thing with "class" semantics even if your language does not support the formal notion of "class" (e.g. Javascript). A class is a template for an object, from which you create instances.
How Class methods are accessed by just name of the class.method name?
I'm not quite sure what you mean. Some languages support "static" or "class" methods, which are methods that are not invoked within the context of an instance of the class. So its not the same as "object.method" which is a normal method on the class where the 'this' (or equivalent) will be the instance on which the method is invoked.
Java (from comments)
For Java, there is a class called Object, and a class called Class. See this. These Java constructs are separate from the notion of Class and Object. The former are implementation details -- they are how the designers constructed the language, the latter are general concepts. So in Java, you can have an instance of an Object, where the instance is an object(the concept) of type Object(the Java construct).
A Basic notion of object means that has been allocated some memory. As devdigital said class is just a blueprint for an object which holds the bare-bone structure and determines how the object will behave when it's it will be instantiated.
Classes are just bodies(without soul) and objects are living bodies(having a soul) that interact with environment or in biological terms respond to external stimuli(public methods and properties) in an analogy to philosophy of life :)
Technically classes are just machine interpretable code residing in memory(not necessary main memory or registers). Objects are code loaded into executable memory(registers/main memory)
Related
I came across with the following statements:
(Metaclass class) new. "Uses the new of Behavior but throws error because Metaclass class is singleton"
Metaclass new. "Uses the new of Behavior"
I thought that Metaclass class is Metaclass then why the answers are different?
I can't seem to figure out how the method lookup works. Which hierarchy tree I need to follow? Where can I find an almost full tree that has the basic classes?
The class/metaclass relationship is among the most complex topics in Smalltalk, yet is part of the elegance of how everything fits together in a consistent manner.
Method lookup starts in a MethodDictionary held by the class of the object (the class describes the object) and proceeds up the inheritance chain.
Generally you should not be creating new instances of Metaclass, but should let the IDE/tools make it for you as a side-effect of creating a new class (sending #'subclass:...' to an existing superclass).
You can find a tree of basic classes in your Smalltalk image. Details depend on the dialect, and Squeak should have a "Class Hierarchy Browser" that allows you to look at things.
Following is a picture that helps me visualize the relationships.
There is some magic in the message #new, whose understanding requires some effort. What should call our attention is this:
How it is possible for a class to understand #new given that #new is implemented in Behavior, which is not a superclass of our class?
For example, Object new creates a brand new instance of Object even though Object is not a subclass of the root implementor of #new (e.g., Behavior).
To better understand this, note that Object new is not a message sent to an instance of Object but to the class Object. Therefore the lookup will start at the class of Object which is a Metaclass, namely Object class.
It looks like the lookup mechanism through metaclasses would follow a special pathway: It starts at the alluded metaclass, say Object class. If it doesn't find the selector, it goes up in the inheritance hierarchy all the way up to ProtoObject class if needed. But, it doesn't stop here. It jumps to the abstract class Class to continue the lookup. From there it goes up following the hierarchy again. This happens with all messages sent to a class, not just with #new. In the case of Object new, it will find the implementor in Behavior.
There is something interesting observe:
When the lookup reaches Class it is no longer a class-side search, it is now an instance-side one.
A question remains:
How is it possible for the lookup to jump from ProtoObject class to Class?
Well, there is actually no jump at all. What happens is this:
ProtoObject superclass == nil.
but
ProtoObject class superclass == Class
and since the lookup sends the #superclass message to follow the inheritance chain, it will naturally transition from ProtoObject class to Class without having to do anything special.
The particular detail here is that for all classes, except ProtoObject we have
AnyClass class superclass == AnyClass superclass class "<- algebraic commutativity"
However, for ProtoObject this is not the case, the superclass of ProtoObject is nil but the superclass of ProtoObject class is Class.
Note
This also the only case where a Metaclass has a superclass which is not a Metaclass. That is precisely the exception which resolves the modeling circularity.
I tried to think of a better name for this is but I couldn't.
Also every topic on this involves python and I don't know python
I know that the dafult :meta-class is standar-class
And that standard-object is an instance of the standard-class and that every class is an instance of the standard-class and inherits everything from the standard-object but how is this this possible?
As in how can standard-object be an object and a superclass both at the same time?
How does it work and why?
What I don't understand is how can an instantained class be also a class?
One way to think about it is to forget that bootstrapping is a problem and imagine that the object system is “just so” and then it seems natural that:
everything is an object
every object is an instance of a class
every (standard) class is a subclass of standard-object
a class is an object
every standard class is an object which is an instance of standard-class
standard-class is a standard class which is an object which is an instance of standard-class and a subclass of standard-object which is a class which is an object which is an instance of standard-class
I tried and failed to find a good diagram.
Another way to think about this is about bootstrapping. How can you make the above state come to be?
One way is that you can make an object without its class existing:
Decide on the memory layout of objects
Knowing how to lay out an instance of standard-class in memory, allocate an instance that will become the class standard-class
Initialise that instance with the right things. Set its class to be itself. Don’t set any superclasses yet
Do the same to allocate an instance that will become standard-object (and other parts of the hierarchy, ie class, the class of T, generic-function, method, etc)
The class of all of these objects can be set to standard-class
Connect up the class hierarchy relationships
Create generic functions and methods for allocating instances and compiling generic functions and such
Welcome to your new object system
You could ask yourself the question in reverse: why would a class not be an object, in an object-oriented programming language?
What is a class? It's something that contains information about how to create new objects, things like fields, default values, etc… In OOP, the default tool to store data together is an object. So CL's classes are just objects! And because classes are objects themselves, of course they have a class, STANDARD-CLASS (STANDARD-OBJECT is the direct superclass of a class without any other superclasses… cf. Inheritance structure of metaobject classes).
As an exercise, you can try to create your own (very simple) object system and you may discover very fast that having your classes being objects would make your life way easier. Going from there, there is just the slight problem of bootstrapping. :-)
Apparently, singletons are bad, and a factory method is recommended. I'm wondering if a singleton toolbox is any better than a singleton.
In my opinion, It's really weak to think that singletons are bad,factory methods are good.
Each of them has preferences. As consequence, I'm sure that there is misunderstanding here.
I know that wikipedia is not the best source. But check out the definition of them. The range of situations are not the same for these patterns.
In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects. The term comes from the mathematical concept of a singleton.
In class-based programming, the factory method pattern is a creational pattern which uses factory methods to deal with the problem of creating objects without specifying the exact class of object that will be created. This is done by creating objects via calling a factory method—either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor.
There are quite a few dynamically typed object oriented languages in which a class itself is an object. Smalltalk, and Python for example. Is there any statically typed language in which a class is an object?
EDIT:
By the term "object", I mean a first class entity. For example, classes in Python can be passed to other methods, can be returned from methods etc.
In a lot of statically typed languages, like JAVA, a class is an object with its own methods.
For example, in Java, the object that represents the "String" class is accessible as "String.class" and then you can invoke methods on this class as "String.class.getFields()", "getMethods()", getConstructor()", "cast(obj)", etc. You can see in the API documentation all the methods of the "Class" class.
Nevertheless, given that the language is statically typed, you cannot dynamically modify a class.
In other words, you are not going to find a method called "class.addField()" in the Class class. The more you can do is "extend" the class (if it is not final) by inheritance.
In yet other words, the a "Class" object is read-only.
By the term "object", I mean a first class entity. For example, classes in Python can be passed to other methods, can be returned from methods etc.
As any other object, you can pass them to methods and return them from methods (they are just regular objects, but that expose only "read" methods). Example (I omit generics for clearness):
public Class myMethod(Class someClassObject) {
System.out.println(someClassObject.getCanonicalName());
Class anotherClass = String.class;
return anotherClass ;
}
I don't fully agree with #edutesoy answer.
First-class means that an implicit constructs is reified as an explicit construct that can be passed around like any object. Classes in Java are not "first-class", they are mirrors where you can inspect some properties but are not the the object itself.
That you can not change the structure of the class at run-time is fine, e.g. add fields, change method body or signature, and that under this perspective it's partly "read-only" is ok.
But let's consider static fields. I guess everybody agrees that unless final static fields are mutable, just like instance fields. In Smalltalk, these are just fields defined on the class itself, rather than on instances of the class. Also, in Smalltalk, class-side methods are polymorphic just like any other method, and :
aClass field: aValue.
might resolve differently depending on the class that is passed. This is not possible in Java ; a static field or method must be referenced via its type. This also means that it does not allow overriding static methods (read the link for more details) as would be the case if they were truely first class.
The fact that reflection is possible in Java doesn't make classes "first-class"--you can only pass a representation of the class around. And to come back to the original question: I don't know of any statically typed language with first-class classes (but my knowledge is limited, maybe one exists).
EDIT
Actually, now I remember it exists StrongTalk (http://www.strongtalk.org/) which is Smalltalk with static typing. The typing issues are discussed in this paper: Strongtalk: Typechecking Smalltalk in a Production Environment
From Oleg Kiselyov and Ralph Lammel's "Haskell's overlooked object system" (emphasis mine),
Not only OOHaskell provides the conventional OO idioms; we have also
language-engineered several features that are either bleeding-edge or unattainable
in mainstream OO languages: for example, first-class classes and class closures; statically type-checked collection classes with bounded polymorphism of implicit collection arguments; multiple inheritance with user-controlled sharing; safe co-variant
argument subtyping.
Well, the benefits of that are reduced in an early-bound language. However, Java reflection objects for classes would basically be what you are asking for.
Why, incidentally, do you want this? Is it more than idle curiousity?
Take a look at the concept of homoiconicity which refers to the extant that a language can refer to its own structures. Also take a look at this post by Eric Lippert.
I've seen many other questions on this same topic but they're not very clear to me, someone new to Objective-C.
I need a plain english explanation. 'Coder speak' is much too difficult for me to understand at this point in my learning.
An instance method or variable applies to that instance. A class method (classes in Objective-C don't have variables, though they can be simulated in various ways) applies to the whole class.
Consider the quintessential Dog class, which derives from the Mammal class (and so on up the tree of life.) A particular dog has a name and a collar and an owner--those are its properties. A particular dog may -bark or -chaseBall or -buryBoneInBackyard--those are its methods.
The Dog class, on the other hand, has different methods. The Dog class has a +globalPopulation and may instantiate itself with a +dogWithDNA: factory method. The Dog class will have an +isExtinct method indicating whether the species as a whole is extinct (it's not, of course.)
In short: class methods affect the entire class, while instance methods affect a particular instance of a class.
First, Objective-C does not have class variables. There are things that act sorts like class variables modally, but they aren't true class variables (see "static variables").
In Objective-C, every class is effectively an instance of a class. Thus, a class method is simply a method that applies to the class. They can be inherited and overridden.
Instance variables (ivars) and instance methods exist on each instance. There is one ivar per instance. Instance methods can not be called on classes.
Class variables^ and class methods do not not exist on instances, they exist on the class. That means that there will only ever be one class variable in the entire application regardless of how many instances are created. Class methods can be called without an instance*, so they kind of act like normal C functions. Because class methods are not attached to an instance, class methods can not access ivars.
^ Objective-C doesn't have class variables per se. "Class variables" are effectively static global variables in C.
* technically, a class is an instance, so class methods are actually instance methods in a sense.
A class is like a mold for something, that you can fill with plaster.
So a class level method is something that you can see and reach and use, without ever having to make a single object.
An instance is like pouring plaster into the mold and getting something out. You stamp out as many as you need; an instance variable then is a place on that object to hold something, and an instance method is something you can do with only that single object, not all of them.