Re: Lua Needs

Le jeu. 29 nov. 2018 à 16:31, Soni L. <fakedme@gmail.com> a écrit :

In practice it's better to use:

local a = a
a:b.c()
a:d.e()

Because they're components and as such are a property of the object. They may change and as such you should not cache them. Consider them part of the object, rather than separate objects.

you could have the case

local a = a

a:b.d()

a:c.d()

where the desire is to have a way to select one of the "d" component methods (or properties) independantly of the path (possibly complex and resulting from a function call) from which it is accessed, i.e. something like:

local a = a

local x = test and a:b or a:c

x:d()

The function+closure based solution I proposed also works to hold the two references (the base object, and the target function which is any component accessible from the base object via an unknown path, when this targetr function needs in its first parameter a reference to the base object) for this case:

local a = a

local x = function(a, b, c)

local __o___ = a;
return function(...)
return (test and b or c)(__o__, ...)
end
end
x(d)

imagine that "d" is a generic "get" or "set" function used to define some property or subproperty of an object. Such concept is used in oop based on facets (I've used it on a L4G programming language where there was no "method" at all, only dynamic properties.

But such concept is not dead and is widely used for implementing UI components, that are exposing only properties to define the behavior and content/visible aspect of the UI component and propagate all side effects in a component tree, without forcing users to really write any line of code, only get/set values of properties, these values having simple types : generally a single string, a numeric or enum value, a color value, or a locale identifier (with its implied BCP 47 fallback semantics, something that strings alone don't have; such value having also other subproperties like the language code, the script code, or sets of other locales that the locale identifer match during fallbacks). Several "Visual" programming languages (and thier associated UI designer) use such concept with the additional benefit that they are generally easy to serialize (objects that have programmable method facets are much harder to serialize correctly and safely)