Then I'm not sure what you mean by this equality "Closures = overcomplicating it"; to whom are you targetting this visible critic given that "foo:bar()" is well documented and supported, and "foo:bar.baz()" is not supported and we can't guess at all what is the expected behavior (what is the effective value to given to "self" within "baz()").
So I have the same remark to address to you " I'm not sure what your goal is here..." , i.e. really to who you are addressing the issue and who could solve it or who you expect a solution (or workaround) to come
from.to solve a problem (most probably related to the integration of Lua into another unspecified OOP language, with specific needs not coverabed by Lua with its implied semantics).
Clearly it seems that even the closures in Lua is an unnecessary byut costly syntaxic "toy" which could as well be supported by languages passing variables by *references* in function calls (in C, these references would turn into pointers because references and pointers in C are tightly linked to each other by unchecked typecasts, making C code difficult or impossible to enfore typesafely, many languages don't have or need pointers at all, they use references only to existing objects that have a know type, including Lua with its "nil" object which is a non-null reference to a static/atomized constant object with LUA_TNIL type and the only permitted instance of this type; instead of pointers, Lua can use accessors, i.e. methods to get/set pseudo typecasts to convert a given type to another by decomposing it into smaller underlying storage units, which can be part of an indexed array/table).
As well tables in Lua can be implemented efficiently using one or more tables without the necessary cost of the hashing function and hashtable, it dtoes that by differentiating integers from the larger set of types for table keys and then avoids the overhead of the hansing function and hashtable for integer keys, storing most values directly in a dense array if the integer keys are dense enough in a single interval and then using the hash table for all other key values including integers that are not part of the dense interval). So Lua can "emulate" pointers but more safely than what classic C compilers or assembly lanbuages do in a single untyped/unchecked array of "bytes" in a single space to store everything (data, code/functions, call stacks, objects, virtual memory mappings, threads, I/O handles...). C++ can be cleaner because we can use it without any pointer and any unsafe typecasts (but C++ still has obscure implicit casts that can become out of control, without using any accessor, and that can easily break the OOP design and type inferences).
Le sam. 1 déc. 2018 à 23:13, Soni "They/Them" L. <
fakedme@gmail.com> a écrit :
> Sorry, accidentally replied directly instead of reply to list >.<
> I still stand by "Closures = overcomplicating it" with regards to "foo:bar()" and "foo:bar.baz()".
> In any case, I'm not sure what your goal is here... ¯\_(?)_/¯
