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.
Related
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. :-)
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)
Is there any difference between a parent class and a super class? Is a super class simply a parent class that doesn't inherit from other classes?
This is more of a terminology difference, the idea of parent and child classes or super and subclasses. It seems to depend on programming language experience and application domain as to which one you use as well as when you first began getting into Object Oriented Programming.
In both cases there is a class, the parent class or super class or base class, from which is derived other classes, the child class or subclass. The child class or subclass extends the parent class or super class by adding some capability to the existing capability of the class being extended.
super() is how the parent or super class constructor for a Java class is invoked in a derived class.
There was a fair amount of churn in the terminology during the first years of object oriented programming as various people worked in the area and published papers and books and developed Object Oriented Languages. It was all quite new and exciting and people were trying to decide the proper vocabulary to use so they were trying out various words and phrases to express Object Oriented concepts.
And with a number of Object Oriented Programming languages that have been developed and gained popularity, a community developed around the language with a particular vocabulary. So older and more experienced programmers who were into object oriented early on may call things a bit different.
Parent and child is also used in describing other kinds of Is-A or Has-A relationships. For instance Parent window and Child window is also used for windowing systems in which a window, the Child, is contained within another window, the Parent. So the Parent window Has-A Child window.
I'd say it's the same.
You might want to differentiate between a direct and indirect parent or super class, but I guess the two terms are not clear enough on this, either. So if this is what you are trying to express, better be explicit.
Also, many programming languages have the "super" keyword used to refer to the (single) direct parent class. But even there, if you call a "super" method and the direct parent does not implement it, it also bubbles up.
They are different terms to address the same OOP concept: inheritance. If class ChildClass extends ParentClass you can say:
ChildClass parent class is ParentClass
ParentClass is the super-class of ChildClass
Inheritance levels have nothing to do there, it doesn't matter if a Super-Class itself extends another class.
They are essentially the same. Depending on the language, the terminology changes. Parent may mean the immediate parent, while Super class may mean any of the ancestor classes. In addition, in java, there is the super() method, which calls the parent's constructor.
In Ruby language we have both the concepts meaning different things.
ParentClass -> ChildClass -> this is used for namespacing
and
SuperClass -> SubClass -> this is used for inheritance
Examples below:
ParentClass -> ChildClass:
class A
def self.f1
puts "A -> #{self.name}.f1 called"
end
# B is childclass of A
class B
def self.f2
puts "B -> #{self.name}.f2 called"
end
end
end
# C is subclass of A
class C < A
def self.f3
puts "C -> #{self.name}.f3 called"
B.f2
end
end
See the output below:
C.f1
A -> C.f1 called
C.f3
C -> C.f3 called
B -> A::B.f2 called
Not to sound like a koan, but just wondering if there are definite rules about classes and objects. I used to think classes as blueprints, and objects as the creation from them. But if a combination of blueprints creates another blueprint, does the latter blueprint become an object as well?
Your question seems a bit philosophical... :) "object" and "instance" are quite synonymous in OOP.
If I understood your question correctly, your doubt is: "an object is still an object also if created by another class that is not the same that define its type?"
The answer is "yes", an instance is an object created following the "model" defined by its class, but for many reasons you could instantiate a class in an indirect way, for example a static method (factory method of a factory class, for example) and not directly using new statement.
If you want to see some come, an easy example in Java could be:
public class MyClass {
public MyClass(){}
}
public class MyClassFactory{
public getInstance(){
return new MyClass();
}
}
In this case the instance is not returned directly by MyClass, but from its factory class. however it's an object as well...
In just about every OO environment I know, an instance is the same as an object.
It doesn't matter whether the object/instance is created by the client (such as with new) or by the class (such as with singletons or factories).
If you're talking about blueprints in the context of classes, then creating blueprints from blueprints is inheritance, not instantiation.
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.