Re: A custom type/class system with lua/luajit

[Richard Hundt <richardhundt@...>]

> Actually, with 5e9 iterations it takes 10s for me, which is around 2ns per
> iteration, which is around C speed on my CPU. I'm using an Intel Core2 Duo
> 1,8Ghz underclocked laptop CPU. :)

Oops, I was off by 3 zeros there. Next time I'll try actually running
your code ;)

> Alright, here's my "wishlist" :)
> - Class system with single-inheritance and mixins(aka components,
> interfaces)
> - Overloadable, default values directly in the member declaration(this is
> where e.g. java fails, it can't handle default values with polymorphism
> well)
> - Function type guards.
>
> Looking over your tests, you actually already have 1 and 3, nice! I can't
> test 2 right now since your inheritance seems to be broken, but it sounds
> like something that is easily done.

Item 2 is intended to work (and was working at some point) in that the
following:

class Foo {
    has stack : Array = [ ]
}

compiles to something like:

__class(self, "Foo", {}, {}, function(self, super)
     __has(self, "stack", Array, function() return Array:new() end)
end)

So the default value of a property is an expression which is wrapped
in a function, to which the member access delegates if the value is
nil. So following is also valid:

class AbstractFoo {
    has message = error("message required") // requires overloading
}

I can imagine that it's broken :/ I've also been delaying announcing
the project until it had stabilized a bit. Sounds like I should get
cracking on getting guards into the new version again ;)

> Oh, and to give some feedback.. I believe that "has member is readonly" is
> rather hard to read, seeing as it looks like an english sentence, but really
> isn't. I'd actually go for a more C-like idiom, e.g. "CONST member"  there.
> :)

The idea behind this was that since members slots are objects
themselves, they can have traits which are mixed in using `is'
(something borrowed from Perl 6). This could apply to grammar rules,
and methods too, and could be user defined. So something like:

trait EmailAddress {
   method __writer(v) {
      // validate v
   }
}

class Person {
    has email : String is EmailAddress = ""
}

In the end, this adds a lot of complexity to the language as it raises
questions of whether you should be able to mix in traits into class
members at run-time, or not, and if so, then the performance hit
becomes significant unless you find a way to clear the generated
member accessors (so delegating to the meta object on each property
access is costly). So I'm inclined to just drop this feature for now.
This is why this whole thing is experimental. Lots of the language
features are more of an exploration of whether something *could* be
done. Not whether it should be.

Anyway, I'll take some holiday soon and give this thing a bit more
loving; see if I can get it into shape again.

Cheers,
Richard