Thanks for trying bud! But I understand duck types.
I was just musing about strong simularitaries between a couple of different data structures which we tend not to think of as same things. But they are so closely related that I think eventually they will become the same things.
This is one of the great things about Ruby. It is very cutting-edge and serves as a jumping point into some interesting theoretical explorations of programming itself.
I was just musing about strong simularitaries
between a couple of different data structures
which we tend not to think of as same things.
I like your thinking on this, and there are (not surprisingly) other
languages that take it farther. In JavaScript and especially Self,
objects are composed entirely of named “slots” or properties, and they
are frequently used as hashes, with no other specialized hash support in
the language or libraries.
Thanks for trying bud! But I understand duck types.
Heh, sorry. I’m too used to questions about what it is appearing here,
with me
writing long, rambling musings of my own in response.
In fact, your idea seems similar to the way people describe some aspects of
Python. I’m not a Python expert, but I seem to recall that variable
access is
seen more as a lookup than something uniquely part of objects. So
essentially
an object is a hash, and instance variables are just space keyed to the
appropriate
name. Private variables are then made by mangling the name used to access
it by whatever method (facilitated in Python by adding _ or __ to the
beginning
of the name).
Put that together with the fact that functions are first class in
Python, and you
actually have a somewhat consistant object system. It’s just that, for
convenience,
the code:
foo.bar(baz)
becomes:
foo[“bar”](foo, baz)
Or something similar, because the latter is ugly.
In fact, with your hash-proc object model, Ruby becomes a lot more Python
like. “Methods” become automatically first class, but they require a
function
call syntax, so that you can’t write
foo.bar
Because that’s the method bar of foo, not the result of calling method
bar of foo.
For the latter, you need:
foo.bar
which becomes:
foo[:bar][foo]
I don’t really know where I’m going with this. It’s an interesting
subject, though,
and can provide one with things to think about for many hours.
I was just musing about strong simularitaries between a couple of
different data structures which we tend not to think of as same
things. But they are so closely related that I think eventually they
will become the same things.
In fact, Class is a subclass of Module. The added code for making
actual instances is what really separates the two.
Duck typing certainly does make for some interesting thinking though
But I understand duck types.