What you describe is doable with closures, at least as far as your example goes. Your example can be implemented almost word-for-word in Arc as it stands:
obj is a macro that creates a hash table (you don't need to quote the keys, by the way). So, (Socket url port) will return a function that accepts 1 or more arguments, assumes the first is a method name, looks it up in the hash-table o, finds the corresponding function, and applies it to the rest of the arguments.
If you want to give your object thing internal state that you'll want to modify, use a let.
Here is an example that probably demonstrates most of what you're looking for. It is pretty much cribbed from SICP[0].
Given the way I defined a Bank-Account, you could implement this rather simply:
(def deposit (x . args)
(apply x 'deposit args))
Or, with akkartik's implementation, which I agree is nicer and better:
(def deposit (x . args)
(apply x!deposit args))
And you could make another "object" and give it a distinct 'deposit "method" and it would work fine.
So... it seems that one can easily implement these things in Arc. If you have some project in mind for which you want OO stuff, you can just do the things posted in this thread, and tell everyone how it goes if you like.
If you think OO should be put into the core of the language, well, there's a certain resistance to adding features just because someone suggests it. The core would become large, disorganized, and difficult to maintain if we did that. So, you would have to give a convincing argument as to why it's worth putting in there, and a demonstration of how useful it is in some real project of yours is probably the best argument you could give.
This kind of OO with closures is a fun experiment and looks very elegant at first sight. I love the (x!deposit 50 "meh") version for its simplicity, the use of ssyntax, and the fact that you can pass x!deposit around as a first class function. Thanks to macros, you can of course easily come up with a nice syntax for the definitions:
However, the approach has some issues in real life use. First, every bank account instance replicates the method table and so takes up more memory the more methods the class defines, and each method is a closure that takes up memory as well. Also, this hash table obviously needs to be built every time an instance is created. Another big problem that follows from the above is that when you add or redefine methods on the class, existing instances are left with the old implementation. And there is no way to implement inheritance here.
I guess it is possible to remedy most or all of those problems by sacrifying methods as closures and instead do:
(= bank-account-mt
(obj check-pass (fn (self o pw)
(unless (is o!pw pw)
(err "Wrong password!")))
deposit (fn (self o x pw)
(self 'check-pass pw)
(++ o!money x))
withdraw (fn (self o x pw)
(self 'check-pass pw)
(if (< o!money x)
(err "Not enough money.")
(-- o!money x)))
check (fn (self o pw)
(self 'check-pass pw)
o!money)
change-pw (fn (self o new-pw pw)
(self 'check-pass pw)
(= o!pw new-pw))))
(def Bank-Account (password)
(let o (obj money 0 pw password)
(afn (method-name . args)
(apply (bank-account-mt method-name)
(cons self (cons o args))))))
Again using a macro to improve readability and writability. Adding inheritance is left as an exercise for the reader.
I'm sure this doesn't surprise you, but here's a quick version of 'defclass that uses a syntax similar to your first example and an implementation similar to your second example:
Nice, and you even changed it so x!deposit returns a function again! This does of course add some overhead since a closure is constructed every time you call a method, but still.
One thing I'm not quite happy with is that one has to write o!money. Would it somehow be possible to hide the o? Would it be possible to use !money or .money, or does the parser not allow that? And how to pass the hash table from the afn to the methods without polluting their namespaces? It could be done using a gensym, but then it is not possible to add methods to the method table outside defclass.
