[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua Needs
- From: Coda Highland <chighland@...>
- Date: Tue, 27 Nov 2018 09:21:23 -0600
On Tue, Nov 27, 2018 at 3:42 AM Soni L. <email@example.com> wrote:
> On Tue, Nov 27, 2018, 01:55 Coda Highland <firstname.lastname@example.org wrote:
>> On Mon, Nov 26, 2018 at 8:51 PM Soni L. <email@example.com> wrote:
>> > Suggestion: Don't assume (or use) inheritance. Or at least don't mix inheritance with components.
>> > Rust has traits, which are somewhat similar to components, but it doesn't have inheritance. That's because mixing traits/components and inheritance is, at best, messy.
>> So on the one hand, you're completely right. Traits are a much better
>> model for this than inheritance, and mixing traits and inheritance can
>> indeed get quite messy.
>> But on the other hand, that still leaves the matter of "what's the
>> best way to implement traits in Lua?" as a question to be discussed.
>> /s/ Adam
> Sorry, uh, is it okay if I ask what you mean by that?
> I mean, I was specifically saying these shouldn't be a thing:
> foo:thing.other.more.why() -> foo.thing.other.more.why(foo)
> foo.thing.other.more:why() -> the ability to use self.super.super.super to access foo
> Mostly because they look nothing like traits, but also because they look like some weird attempt at inheritance?
First off: This isn't inheritance at all. It's composition. Some
languages do support composition via inheritance (C++, Python), but in
the larger programming world it's not a popular paradigm because of
all of the issues that arise in multiple inheritance.
There's no SPECIFIC reason why foo:bar.baz() -> foo.bar.baz(foo) can't
be supported. I have no complaints about that syntax as long as only a
single : is supported in an expression. It might be a bit ugly to
handle at parse time or at run time, but the fact that Cratera
supports it suggests it's not THAT bad.
self.super.super.super fails HARD, though, because the notion of
"super" there becomes bound up in the specific way the expression is
constructed. Consider this:
local more = foo.thing.other.more
more:why() -- what does self.super mean here?
The "more" object there has no idea that it's contained within
"foo.thing.other" unless you explicitly assign the value of "super" in
the object -- at which point that works just fine in current Lua
without any modifications at all -- or if you do what Python does and
you have . return a binding object instead of the object itself. But
tracking the whole call-time super chain adds an arbitrary amount of
overhead to every function call expression even if it's never going to