lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 3/29/14 12:51 PM, Timm S. Mueller wrote:

> Building fails for me under Linux:
> $ git clone
> $ cd shine
> $ make
> [..]
> CC        lib_tvm.o
> CC        lib_init.o
> AR        libtvmjit.a
> GEN       op.h
> make[2]: ./tvmjit: Command not found
> I may be missing something. Sorry for not digging deeper into it yet.
I couldn't reproduce exactly, but I have an idea what it might have
been. Could you try again?
> I find it hard to endorse the notation class.func() providing an
> implicit self.
This is a little ambiguous as there are two cases:

* calling an instance method on the class
* calling a "static" method

The first case could arguably raise an error:

class Point
   move(x, y)
      self.x = x
      self.y = y
Point.move(11, 22)         -- you have a bad self here

The second case is a more consistent. If you define a class method as
`function self::watever() end` in the class body, then there is no
implicit `self` parameter, and calling it as `class::whatever()` does
what you expect (`self` is still in scope as an upvalue, though, and
references the class itself). This is identical do saying, in Lua
`function self.whatever() end`, and calling it as such.

class Foo
   function self::greet()
      -- no `self` parameter
   function self.munge()
      -- implicit `self` parameter

The same applies to any table:

`o = { }; function o::greet() --[[ no self here ]] end`

Similarly, using the `.` notation when defining a method is identical to
Lua's `:`.

This is a bit of a wart, I agree, however I wanted a certain amount of
transparency that it's really still Lua underneath. There's nothing
especially magical about classes. Rather, they're a metatable convention
expressed in syntax.

Having said that, in the case where an instance method is called with
the class as a receiver can probably be fixed.

I'll have a little bit of a think about this again. It's good feedback.