Return to Answer

You can think of an object o as an entity containing

1. a collection of local variables v1, v2, ... (the state of the object),
2. a collection of closures m1, m2, ... that close over v1, v2, m1, m2 (the methods of the object),
3. a mechanism to access the local variable and methods by name: an object is basically a higher-order function that takes a name as input and returns a field or a method as a result.

In a Python object you use the dot notation (o.var, o.foo()) to access members and methods. Of course, you can easily simulate this by means of a dictionary as you have described: a dictionary is also a mapping (see point 3) and you can use it to store object fields or methods.

So I would say that the class construct is a more convenient syntax to express the object pattern. You can simulate objects with dictionaries too, it just gets more verbose.

The syntax of creating an 'object'. This is the reason (I think) classes are superior, because using a function to create classes would quickly become very irritating.

Instead of having functions to create classes, I would imagine using functions to create objects (i.e. special dictionaries), which would correspond to class constructors. See also your example: function A() is the constructor function corresponding to the __init__() method of class A.

Inheritance.

I think that if you model classes with constructor functions returning dictionaries, then you can model inheritance by using the superclass constructor in the subclass constructor. The subclass constructor can call the superclass constructor and then extend / override the resulting dictionary with its own definitions.

For example:

# Superclass A. def A(val): def toString(a): return str(a['a']) def printOut(a): print(a['toString'](a)) return {'a': val, 'toString': toString, 'printOut': printOut} # B is a subclass of A. def B(val): # Override method. def toString(a): return 'value = ' + str(a['a']) r = A(val) r['toString'] = toString return r 

You can think of an object o as an entity containing

1. a collection of local variables v1, v2, ... (the state of the object),
2. a collection of closures m1, m2, ... that close over v1, v2, m1, m2 (the methods of the object),
3. a mechanism to access the local variable and methods by name: an object is basically a higher-order function that takes a name as input and returns a field or a method as a result.

In a Python object you use the dot notation (o.var, o.foo()) to access members and methods. Of course, you can easily simulate this by means of a dictionary as you have described: a dictionary is also a mapping (see point 3) and you can use it to store object fields or methods.

So I would say that the class construct is a more convenient syntax to express the object pattern. You can simulate objects with dictionaries too, it just gets more verbose.

The syntax of creating an 'object'. This is the reason (I think) classes are superior, because using a function to create classes would quickly become very irritating.

Instead of having functions to create classes, I would imagine using functions to create objects (i.e. special dictionaries), which would correspond to class constructors. See also your example: function A() is the constructor function corresponding to the __init__() method of class A.

Inheritance.

I think that if you model classes with constructor functions returning dictionaries, then you can model inheritance by using the superclass constructor in the subclass constructor. The subclass constructor can call the superclass constructor and then extend / override the resulting dictionary with its own definitions.

For example:

# Superclass A. def A(val): def toString(a): return str(a['a']) def printOut(a): print(a['toString'](a)) return {'a': val, 'toString': toString, 'printOut': printOut} # B is a subclass of A. def B(val): # Override method. def toString(a): return 'value = ' + str(a['a']) r = A(val) r['toString'] = toString return r 

Summarizing, I would not say that dictionaries are the same as classes:

• A dictionary is an arbitrary mapping.
• An object is a special mapping from names to variables and methods.
• A class is a language construct that gathers together objects with similar structure and helps to create objects.
• Objects and classes can be simulated in a straightforward way using functions and dictionaries.

You can think of an object o as an entity containing

1. a collection of local variables v1, v2, ... (the state of the object),
2. a collection of closures m1, m2, ... that close over v1, v2, m1, m2 (the methods of the object),
3. a mechanism to access the local variable and methods by name: an object is basically a higher-order function that takes a name as input and returns a field or a method as a result.

In a Python object you use the dot notation (o.var, o.foo()) to access members and methods. Of course, you can easily simulate this by means of a dictionary as you have described: a dictionary is also a mapping (see point 3) and you can use it to store object fields or methods.

So I would say that the class construct is a more convenient syntax to express the object pattern. You can simulate objects with dictionaries too, it just gets more verbose.

The syntax of creating an 'object'. This is the reason (I think) classes are superior, because using a function to create classes would quickly become very irritating.

Instead of having functions to create classes, I would imagine using functions to create objects (i.e. special dictionaries), which would correspond to class constructors. See also your example: function A() is the constructor function corresponding to the __init__() method of class A.

Inheritance.

I think that if you model classes with constructor functions returning dictionaries, then you can model inheritance by using the superclass constructor in the subclass constructor. The subclass constructor can call the superclass constructor and then extend / override the resulting dictionary with its own definitions.

For example:

# Superclass A. def A(val): def toString(a): return str(a['a']) def printout(a): print(a['toString'](a)) return {'a': val, 'toString': toString, 'printOut': printOut} # B is a subclass of A. def B(val): # Override method. def toString(a): return str('value = ' + a['a']) r = A(val) r['toString'] = toString return r 

You can think of an object o as an entity containing

1. a collection of local variables v1, v2, ... (the state of the object),
2. a collection of closures m1, m2, ... that close over v1, v2, m1, m2 (the methods of the object),
3. a mechanism to access the local variable and methods by name: an object is basically a higher-order function that takes a name as input and returns a field or a method as a result.

In a Python object you use the dot notation (o.var, o.foo()) to access members and methods. Of course, you can easily simulate this by means of a dictionary as you have described: a dictionary is also a mapping (see point 3) and you can use it to store object fields or methods.

So I would say that the class construct is a more convenient syntax to express the object pattern. You can simulate objects with dictionaries too, it just gets more verbose.

The syntax of creating an 'object'. This is the reason (I think) classes are superior, because using a function to create classes would quickly become very irritating.

Instead of having functions to create classes, I would imagine using functions to create objects (i.e. special dictionaries), which would correspond to class constructors. See also your example: function A() is the constructor function corresponding to the __init__() method of class A.

Inheritance.

I think that if you model classes with constructor functions returning dictionaries, then you can model inheritance by using the superclass constructor in the subclass constructor. The subclass constructor can call the superclass constructor and then extend / override the resulting dictionary with its own definitions.

For example:

# Superclass A. def A(val): def toString(a): return str(a['a']) def printOut(a): print(a['toString'](a)) return {'a': val, 'toString': toString, 'printOut': printOut} # B is a subclass of A. def B(val): # Override method. def toString(a): return 'value = ' + str(a['a']) r = A(val) r['toString'] = toString return r 

You can think of an object o as an entity containing

1. a collection of local variables v1, v2, ... (the state of the object),
2. a collection of closures m1, m2, ... that close over v1, v2, m1, m2 (the methods of the object),
3. a mechanism to access the local variable and methods by name: an object is basically a higher-order function that takes a name as input and returns a field or a method as a result.

In a Python object you use the dot notation (o.var, o.foo()) to access members and methods. Of course, you can easily simulate this by means of a dictionary as you have described: a dictionary is also a mapping (see point 3) and you can use it to store object fields or methods.

So I would say that the class construct is a more convenient syntax to express the object pattern. You can simulate objects with dictionaries too, it just gets more verbose.

The syntax of creating an 'object'. This is the reason (I think) classes are superior, because using a function to create classes would quickly become very irritating.

Instead of having functions to create classes, I would imagine using functions to create objects (i.e. special dictionaries), which would correspond to class constructors. See also your example: function A() is the constructor function corresponding to the __init__() method of class A.

Inheritance.

I think that if you model classes with constructor functions returning dictionaries, then you can model inheritance by passing the superclass constructor as an argument to the subclass constructor. The subclass constructor can call the superclass constructor and then extend / override the resulting dictionary with its own definitions.

You can think of an object o as an entity containing

1. a collection of local variables v1, v2, ... (the state of the object),
2. a collection of closures m1, m2, ... that close over v1, v2, m1, m2 (the methods of the object),
3. a mechanism to access the local variable and methods by name: an object is basically a higher-order function that takes a name as input and returns a field or a method as a result.

In a Python object you use the dot notation (o.var, o.foo()) to access members and methods. Of course, you can easily simulate this by means of a dictionary as you have described: a dictionary is also a mapping (see point 3) and you can use it to store object fields or methods.

So I would say that the class construct is a more convenient syntax to express the object pattern. You can simulate objects with dictionaries too, it just gets more verbose.

The syntax of creating an 'object'. This is the reason (I think) classes are superior, because using a function to create classes would quickly become very irritating.

Instead of having functions to create classes, I would imagine using functions to create objects (i.e. special dictionaries), which would correspond to class constructors. See also your example: function A() is the constructor function corresponding to the __init__() method of class A.

Inheritance.

I think that if you model classes with constructor functions returning dictionaries, then you can model inheritance by using the superclass constructor in the subclass constructor. The subclass constructor can call the superclass constructor and then extend / override the resulting dictionary with its own definitions.

For example:

# Superclass A. def A(val): def toString(a): return str(a['a']) def printout(a): print(a['toString'](a)) return {'a': val, 'toString': toString, 'printOut': printOut} # B is a subclass of A. def B(val): # Override method. def toString(a): return str('value = ' + a['a']) r = A(val) r['toString'] = toString return r