Paul Graham wrote Why Arc isn't Especially Object-Oriented.. His conclusion for why this is the case are:
I personally have never needed object-oriented abstractions. Common Lisp has an enormously powerful object system and I've never used it once. I've done a lot of things (e.g. making hash tables full of closures) that would have required object-oriented techniques to do in wimpier languages, but I have never had to use CLOS.
Maybe I'm just stupid, or have worked on some limited subset of applications. There is a danger in designing a language based on one's own experience of programming. But it seems more dangerous to put stuff in that you've never needed because it's thought to be a good idea.
Well, maybe it's because I'm younger, but having worked with Perl 5 extensively, I've used its object system (and some OO-support modules) a lot. While I have inherited some classes in Perl 5, I also often use an object just to make sure it can be instantiated.
Furthermore, having learned a bit about Perl 6 and Ruby, I believe that making everything an object, can be advantageous because one can more easily inherit from it, and add methods (and multimethods) to constants or regular variables (e.g: “6->my_func();”), or even easily override default behaviour.
So there we go. Note that Park will not be overly-Object-Oriented (OOO). One would be able to declare global functions and variables, and write scripts or modules without wrapping it in Objects. (Read what Damian Conway has to say about the Hello World program in Java for why I don't like it).
Here are some features of the object system:
Supports multiple-inheritance.
Methods can be added to classes at run-time (like Smalltalk or Ruby).
Supports traits (or as the Perl 6 people call them "Roles").
The fields of every object will be stored as an associative array, accessible using a special method. (This associative array will also be an object since everything is. I wonder how the Python people have solved it, but it's probably doable.)
The member variables of every object will be stored as an associative array, accessible using a special method. (This associative array will also be an object since everything is. I wonder how the Python people have solved it, but it's probably doable.)
Similarly to Perl5 and Python (and as opposed to Java, C++ or PHP) there won't be any built-in "public", "protected", "private", etc. access-control for methods of objects by default. Such things can probably be implemented by tweaking the method class and/or the class meta-class, or in different ways completely, but I don't find it appropriate for Park.
Multi-methods will be supported. Multimethods are functions that are dispatched according to more than one object based on the best matching multimethod signature. The syntax for this would be the mcall function (short for multi-call):
(mcall my-multi-method ([ object1 object2 object3]) optional-param1 optional-param2 optional-param3 )
The standard way to invoke a method is to use the call
function, which propagates according to only a single argument:
(def-method "MyClass::init" ((this) (set (this sum) 0) ) ) (def-method "MyClass::add" ((this n) (+= (-> this sum) n) ) ) (def-method "MyClass::getsum" ((this) (-> this sum) ) ) (set new-summer (new MyClass)) (call add new-summer 5) (call add new-summer 7) (call add new-summer 13) (print (call getsum new-summer) "\n")
This will print 24 and a newline.
Note that usually the call would be redundant, and you could use a simple function call. However, such a function call would be subject to other Perl 5-like calling semantics.