RE: Need standard kernel supported class in Lua, was: Macros and expressivity

["Grellier, Thierry" <t-grellier@...>]

Well when I was talking of inspiring from python, was not thinking of
using its syntax (much prefer Lua one, apart maybe for having a "super"
equivalent to java), but only its inheritance semantic as a base
semantic (though I'm not sure I know it well!).

Thanks for the post.

And well the "simple" OO model I use, for those interested, probably not
the cleverest solution: it favors speed and lazily populates objects.
That is all class changes may not be propagated to the instances...
First key definition is kept for the object which can still modify it.
So if you have
C inherits from C1 and C2 and that both C1 and C2 have field f, C
instance will stick to C1.f (or i.f if it is defined in object). The
output of this can be hard to understand with deep multiple
inheritances.
First lookup of a field is also quite slow as no intermediate closures
are computed.

I might have chosen LOOP, but I didn't knew about it sooner, and I'm a
little confused with which class layer allows to do what and cost what. 
For example:
"On the other hand, in order to properly update the cache of inherited
fields, classes are manipulated by proxies that intercept class
operations and update the class hierarchy properly"

I don't understand what a "proper update" is, and don't care much how it
is implemented (doesn't make semantic clear to me).

I find it really awful to define and fully understand a class semantic
in dynamic language. Any academic work on this topic?



-- OO model :
-- declare a class
-- P1, P2 = class{}, class{ n = 3 }
-- P3 = class():is_a(P2)
-- C = class{}[:is_a(P1, P3, ...)]
-- Optional constructor function C.new(o[, v1, v2, ...])
-- [ex. function C:new(a1, a2) P1.new(self, a1)  P3.new(self, a2) end
-- instanciate a class
-- i = C()   i = C{ m1 = v1, m2 = v2 }   i = C({}, v1, v2) 
-- when new is defined
-- check instance type i:is_a() == C  i:is_a(P1) returns true/false
local getmetatable, setmetatable = getmetatable, setmetatable
local function search(k, superclasses)
  for i=1, #superclasses do 
    local v = superclasses[i][k]
    if v then return v end
  end
  return nil
end
local function no_derive(p) return false end
local function derive(p, plist)
  for i=1, #plist do
    if plist[i] == p or plist[i].__derive(p) then return true end
  end
  return false
end
local function inherit(c, ...)
  local m, superclasses = getmetatable(c), {...}
  m.__index  = function (t, k) return search(k, superclasses) end
  c.__derive = function (p) return derive(p, superclasses) end
  c.is_a = nil
  return c
end
local function check_class(o, class)
  local c = getmetatable(o)
  if class == nil then return c end
  return c and (class == c or c.__derive(class))
end
local function constructor(c, o, ...)
  o = setmetatable(o or {}, c)
  o.is_a = check_class
  if type(c.new) == "function" then o:new(...) end
  return o
end
function class(c)
  if c == nil then c = {} end
  setmetatable (c, {__call = constructor})
  c.__derive = no_derive
  c.is_a     = inherit
  c.__index  = function (t,k) local v = c[k] ; t[k] = v ; return v end
  return c
end

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of steve donovan
Sent: Wednesday, January 16, 2008 9:36 AM
To: Lua list
Subject: Re: Need standard kernel supported class in Lua,was: Macros and
expressivity

On Jan 15, 2008 2:17 PM, Tomas Guisasola Gorham
<tomas@tecgraf.puc-rio.br> wrote:
>         I'm sorry being off-topic here but I can't understand why
> people start to fight using this list.  We have to believe the others
> are well-intentioned and are not attacking us.

Ah, yes! As Fabien says elsewhere, there is social aspect to
programming communities. As a colleague of mine says, people like
getting upset, even if there is no real provocation. This is not a
good thing, because people (especially those not used to us) might be
afraid to speak up because they could be seen as trolls!  I cannot see
why wanting a 'blessed' class system is being provocative at all, as
long as it does not _exclude_ any possibilities.

To get back on topic, this is moreorless the most frequent pattern for
class use:

Name = class()  -- 1. Some function!

function Name:method()
  ...
end

obj = Name()   -- 2 I like overloading () for this

obj:method()

1 and 2 are obviously 'style' issues, so I'm not pushing for any
particular standard here. But (a) methods are best defined using
qualified syntax (why do we _have_ to imitate Python?) and (b) are
called using the colon notation.

1 is just a function call. It usually creates a metatable, it might
not.  We could decide to directly populate the object with method
references; this can make a big difference as Thierry points out; it
depends whether speed is more important than memory.  The point is
that this implementation detail is totally encapsulated in the
function class(), provided we don't assume that every object must have
a metatable.  With a standard reflection interface, such details can
be safely hidden.

The point is that you can change how you do OOP just by changing one
function!  That's cool, although it is also scary.

I really think that providing a simple implementation of class() with
standard Lua would make a lot of new people more at home, immediately,
for the technical cost of 20 odd lines of Lua code.

The social aspect is more complicated. The Three Creators do not
include any blessed utility code; maybe they feel that would be too
prescriptive?  That it would upset people who already have their own
prefered solution? But those people know that they can continue using
their own solutions, that there isn't any implied value judgement of
their efforts.

What really is unnecessary, IHMO, are changes to the core, seeing that
the meta mechanism can produce such a rich set of solutions already.
That's something the mainstream 'competition' does not offer!

steve d.