
The Object Model of Self - xkriva11
https://github.com/pavel-krivanek/articles/tree/master/SelfObjectModel
======
scroot
Anyone interested in prototype-based languages should also checkout io [1],
which is a really clever implementation that doesn't get enough love. And
unlike Self it will work with your favorite teletype emulation environments.

[1] [https://iolanguage.org/](https://iolanguage.org/)

~~~
masklinn
I've always been really troubled by io's `clone` not not actually cloning the
object but creating a sub-object / subtype instead. As well as the prototypes
being an array (so manipulating prototypes is not really a thing).

Oh and it uses the same lingo as javascript, which is a net negative, I think
the Self lingo makes much more sense: a Self prototype is the object you copy
in order to get more instances, once the copy is done there is no relationship
between the prototype and the object just as there is no strict relationship
beyond kinship between your car and its original prototype. I guess "template"
might have been an even better term there.

The shared behaviour (and potentially data) lives in _traits_ and _mixins_.

------
artemonster
Really nice explanation. Having read almost all papers on this endless debate
"Classes vs Prototypes" you'd get a feeling that prototype-based object system
wins in any aspects (expressiveness, flexibility, whatever), and yet almost
all prototype-based languages in the end include crude class implementations
(as Class for a signle namespace to contain all related traits, constructor
method and/or prototypical instance for cloning) - interesting, why so? Is
this model ingrained in our brains by our education or we do really think that
way (i.e. with sets of related entities).

~~~
chadcmulligan
I love the idea of prototypes, and self, but I always use classes. There's
this idea of the self prototyping environment you can extend, which is great
for prototyping (perhaps), but when it comes to professional programming we
want a program to deploy and no one really touches the internal structure, so
classes and deployment win out. The same for smalltalk, you don't want to
deploy an environment that your users can extend - except perhaps in research
environments.

The other thing I suppose is multi developer environments - classes and
compilation win out over prototyping because they're easier to split up. There
might be other reasons, but that's why I always come back to class based
programming, the idea of prototypes is very enticing though.

Edit: though I have started to use a pseudo prototyping environment -
breakpoints and evaluate when things get complex, though its not the same.

~~~
Lichtso
> you don't want to deploy an environment that your users can extend

What is so bad about that?

And isn't it common practice around computer games for example, which can be
modded and extended by custom user content?

~~~
e12e
I always used to be a bit lackluster about the idea of deploying smalltalk
applications for a similar reason - too powerful introspection and debug tools
that are too easy for an end user to open accidentally, and be confused by.

But now, switching between a terminal that uses shift-ctrl-c for copy, and
outlook/o365 in chrome, I often accidentally open developer tools in my email
"application"... And wonder how much better we might be off with a solid
smalltalk (or strongtalk, self) system -- than the current mix of crappy web
apps and crappy electron behemoths...

I should note that it's generally possible to strip out/hide and disable most
of the introspection stuff from smalltalk applications and ship more end-user
style applications.

------
tyingq
I really like Perl's setup where objects are nothing more than
namespaces/packages (usable and helpful in non-oo Perl) and one
function...bless()[1].

It makes it very easy to follow exactly how the OO works, what it is, and is
not.

[1]
[https://perldoc.perl.org/functions/bless.html](https://perldoc.perl.org/functions/bless.html)

------
dboreham
Came here to read a psychology article..

------
k__
I learned the object model of Smalltalk at university and after that I
couldn't take most class based OOP languages seriously anymore.

Everything felt like a hack.

Protoypical OOP was the only savior left, haha.

------
h8hawk
Very nice article. It seems most developers don't likes how prototype based
object model works in JS. I wonder how Javascript object system compare to
Self, or similar language IO?

~~~
cmrdporcupine
I learned several prototype OO languages (Self, LambdaMOO and variants) before
I learned JS back in the mid-90s. I even wrote my own compiler and VM for my
own. My take is that JS's implementation of prototypes isn't terrible, but
it's also not clear what it's doing all the time. Like many other things in JS
the semantics are often odd (strange scoping rules, functions as construtors
in certain contexts only, etc.)

Many of the warts have smoothed over time, but JS got a reputation for being
an ugly hack language early on, and unfortunately that also rubbed off on the
idea of prototype OO. I remember hearing a lot of griping about how JS isn't a
"real OO" language (!#@!@#!@) because it only had prototypes and not classes.
And a lot of rejoicing when classes were proposed for the language. Which to
me was a sign of defeat.

Prototypes are more expressive and can express classes but classes cannot
express prototypes.

FWIW I used to talk to and correspond with Steve Dekorte (author of Io) back
when he was starting out. Looks like he's stopped working on it, which is
unfortunate. It was always a nice language, though not suited for my purposes.
And I think he chose a bad name as it wasn't easily Googleable. I'd like to
see what he could do with it now in the era of Wasm...

~~~
sergeykish
I agree, interface is arcane but once it clicks... And that may be a problem -
world divided by those who grasped that Object.__proto__ ===
Function.prototype and other. I've heard similar stories in XSLT land.

What if interface matters? Just recently I've discovered how to clear some
confusion:

    
    
        Object
        Object.proto === null
    
        object = new Object
        object.proto === Object
        object.toString === Object.toString
    
        fun = new Function
        fun.proto === Function
    

It's almost io (just don't touch 'constructor')

    
    
        Object = Object.prototype
        Function = Function.prototype
    
        syntax new = function (ctx) {
          let ident = ctx.next().value
          return #`new ${ident}.constructor`
        }
    
        // bonus point - make it more like io
        Reflect.defineProperty(Object, 'proto',
          Reflect.getOwnPropertyDescriptor(Object, '__proto__'))
    
    

And io is great!

