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. :-)
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.
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)
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 wonder why smalltalk doesn't make use of java-style inner class. This mechanism effectively allows you to define a new instance of a new class, on-the-fly, where you need it, when you need it. It comes handy when you need an object conforming to some specific protocol but you don't want to create a normal class for it, because of its temporary and local nature being very implementation specific.
As far I know, it could be done easily, since syntax for subclassing is standard message sending. And you can pass self to it so it has the notion of the "outer" object. The only issue is anonymousity - the class should not be present in object browser and must be garbage collected when no instances of it exit.
The question is: Has anyone thought of this?
There are really two answers here:
1 - Yes, it is not hard to create anonymous classes that automatically get garbage collected. In Squeak they are called "uniclasses" because the typical use case is for adding methods to a single object. Systems that use this are for example Etoys and Tweak (although in Etoys the classes are actually put into the SystemDict for historic reasons). Here's some Squeak code I recently used for it:
newClass := ClassBuilder new
newSubclassOf: baseClass
type: baseClass typeOfClass
instanceVariables: instVars
from: nil.
baseClass removeSubclass: newClass.
^newClass
Typically, you would add a convenience method to do this. You can can then add methods, and create an instance, and when all instances are gone, the class will be gc'ed too.
Note that in Java, the class object is not gc'ed - an inner class is compiled exactly like a regular class, it's only hidden by the compiler. In contrast, in Smalltalk this all happens at runtime, even the compiling of new methods for this class, which makes it comparatively inefficient. There is a much better way to create anonymous precompiled behavior, which brings us to answer 2:
2 - Even though it's not hard, it's rarely used in Smalltalk. The reason for that is that Smalltalk has a much more convenient mechanism. Inner classes in Java are most often used for making up a method on the fly implementing a specific interface. The inner class declaration is only needed to make the compiler happy for type safety. In Smalltalk, you simply use block closures. This lets you create behavior on the fly that you can pass around. The system libraries are structured in a way to make use of block closures.
I personally never felt that inner classes were something Smalltalk needed.
If you are thinking of using inner classes for tests, then you can also take a look to the class ClassFactoryForTestCase
Creating an anonymous class(es) in smalltalk is a piece of cake.
More than that, any object which has 3 its instance variables properly set to: its superclass, method dictionary and instance format could serve as a class (have instances).
So, i don't see how the problem here.
If you talking about tool(s) support, like browsing or navigating code which contained in such classes, this is different story. Because by default all classes in system are public, and system dictionary is a flat namespace of them (yes , some implementations has namespaces). This simple model works quite well most of the times.
I am pretty sure it could be done with some hacking around the Class and Metaclass protocol. And the question pops quite often from people who have more experience in Java, and Smalltalk becomes interesting to them. Since inner classes have not been implemented inspite of that, I take it to be the sign that most Smalltalk users do not find them usable. This might be because Smalltalk has blocks, which in simpler manner solve many if not all problems that led to the introduction of inner classes to Java.
(a) You could send the messages to create a new class from inside the method of another class
(b) I doubt that there is any benefit in hiding the resulting class from the introspection system
(c) The reason you use inner classes in Java is because there are no first-class functions. If you need to pass a piece of code in Smalltalk, you just pass a block. You don't need to wrap it up with some other type of object to do so.
The problem (in Squeak at least) comes from the lack of a clean separation of concerns. It's trivial to create your own subclass and put it in a private SystemDictionary:
myEnv := SystemDictionary new.
myClass := ClassBuilder new
name: 'MyClass'
inEnvironment: myEnv
subclassOf: Object
type: #normal
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'MyCategory'
unsafe: false.
But even though you put that class in your own SystemDictionary, the 'MyCategory' category added to the system navigation (verifiable by opening a Browser), and - worse - the class organisers aren't created, so when you navigate to MyClass you get a nil pointer.
It's certainly not impossible, theoretically. Right now the tooling's geared towards a single pool of globally visible class definitions.
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.