Re: RES: RES: RES: idea of vision of blueprint of ROADMAP of Lua core

[skaller <skaller@...>]

On Mon, 2005-01-17 at 04:17, Jay Carlson wrote:

> How do you refer to object slots defined by parents?

Inside the derived class it is easy:

function derived (x)
  methods = base(x)
  --- this is the parent table

  super_meth1 = methods.meth1
  -- parent meth1

  methods.meth1 = 
    function 
       ... super_meth1 (x) ...
       --- calls parent meth1
    end
  -- override meth1
  ...


If you wanted to you could use a more complex
mechanism than one table which you just upgrade
in derived classes. You could for example chain
tables together in a list (for single inheritance)
and then use a metamethod so that if a lookup
in the top-of-list table failed, you'd search
the next table down the list.

This is more powerful .. and also slower and more
complicated.

The reason this all works is that this really *IS* what
all OO language do, one way or another.

That table in C++ is just a vtable, the main difference
is that it is constructed at compile time, and the closures
are created on the fly when needed instead of once inside
the constructor.

However you do need to ask 'why do i want to do all this
housekeeping'?

Sometimes, object abstractions are useful, but not
nearly as often as you might think. You can work with
just plain functions and tables and you may find that
throwing out most of your abstractions is actually
a good thing -- it increases reusability, reliability,
and rapidity of programming to mainly use algebraic
data types, and only use abstraction where it is
really necessary.

People familiar with OO tend to try to encapsulate everything
but obviously this is impossible and self-defeating.

For example for a table you can write get/set methods
for each component -- but the usual indexing is
*already* an abstracted get/set method, so you have
wasted a heap of time implementing nothing more than
a massive complication and inefficiency.

In Lua, if you really need to abstract getting and setting
a field, you can even still do it, using a plain table,
using meta-method hooks -- so there is very little
reason to write get/set methods for table components.
Why duplicate what the bytecode interpreter already does
for you?

There are lots of reasons NOT to do it though: you lose
the ability to iterate over a table, find all its keys,
etc, if you abstract it into a class.

I'm not saying don't use objects or OO, just to regard
it as 'one more tool in your belt' to be used lightly.
If you use plain data structures and forget abstraction,
you will sometimes find places where it really *hurts*
not to be able to dispatch dynamically .. and that's
a candidate for using some kind of OO technique.

The problem in C++ and Java and other similar languages
is that the languages are so weak in handling *functions*
that you're forced to use objects instead. One comes
to believe that classes/objects are abstraction ..
when in fact abstraction is a technique for representing
data via functions.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net