[self-interest] prototypes, "meta" and reflective programming

[Jecel Assumpcao Jr]

On Wed, 10 Jan 2001, C. Ramakrishnan wrote:
> In JavaScript, however, objects are just the same as arrays with the
> slot names being the index.  So I could have just done:
> 
>   myObject[key] = value;
> 
> No need for reflection.

Actually, this alternate representation for objects (you called them
arrays, but they look more like dictionaries to me) *is* reflection. It
is just much more "lightweight" than

      (reflect: myObject) slotAt: key PutValue: value

or something like that. But it is, in theory, the same thing.

And this is the important question: do we want reflection to be as
convenient and transparent as possible? Or do we want to put in "speed
bumps" - some visible barrier that the programmer must cross to get to
the meta world?

Reflection is good: it allows you to do things you couldn't do
otherwise and to make explicit implementation details in order to allow
you to change them as needed.

Reflection is bad: it cuts through levels of abstraction and
contaminates your application with all sorts of little details that
make it very hard to change things later on.

Mirrors are an example of "speed bumps", as are the PropertyDescriptors
you mentioned for Java. They take some overhead to set up and use, so
you'll probably stop and think twice before going this route. If there
is a purely "base level" solution to your problem, you are encouraged
to use it instead.

Now consider things like 'printString' in Smalltalk and Self. This is
meta too, but it is disguised as an ordinary method. So you end up
using it all the time in your programs. It starts off well enough ("how
easy it is to convert numbers to strings!") but in the end it always
becomes a big mess.

Albertina asked:
> So if someone could tell me if there is some relationship 
> between metaprogramming and virtual machine before I try 
> to explain my viewpoints I would be greatly indebted. 

A "virtual machine", as the name says, is a machine that doesn't
physically exist. Some languages like Smalltalk, UCSD Pascal, Modula-2,
Self and Java were designed to run on top of virtual machines that then
must be simulated on a real machine. The idea is that it is easier to
adapt this simulation for several different physical computers than to
change the language's compiler to directly deal with all these
different real computers.

"Metaprogramming" is programming about programming. When you write a
word processor, you are "programming about text", but when you write a
compiler or an operating system you are programming about programming,
right? The two "programming"s in my definition can be different (writing
a C compiler so someone can write a word processor) or the same (a
Smalltalk system written in Smalltalk).

So creating a virtual machine is most certainly programming about
programming. You can write a vm in C++ to run Self (obviously
different). You can write a vm in Squeak to run another Squeak (subtly
different). You can write a vm in Self to run the exact same Self (the
second phase of Self/R).

I don't think I explained the relationship, but I hope at least I gave
some idea of the complexity of the answer.

-- Jecel