You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 29, 2020. It is now read-only.
For example, replace uses of LeafNode.parentNode outside that class with LeafNode:getParent().
Though the basic idea is simple, it requires changing a ton of the code, and is very error-prone. But this kind of thing is better to be done earlier than later.
Expected advantages:
Increased perfomance when switching from Foo.__getters:bar to Foo:getBar(). __getters are implemented using metamethods, so, when an object is flattened by calling object:optimize(), they aren't added to the object table. Which means that every access to the getters requires traversing the inheritance tree.
Errors detected earlier. node.parent (expected node.parentNode) returns nil all the time. This hides the real error, as node.parentNode can also return nil if the node has no parent (is a root node). I've already spent a few days debugging such problems.
Makes it explicit that all fields of a class are considered implementation details, and aren't supposed to be accessed directly by the external users, but via the means of getFoo and setFoo methods.
Also makes it easier to preserve the invariants.
Behavior of getters that have side-effects is made less suprising.
Expected disadvantages:
Decreased perfomance when switching from Foo.field (just a table index) to Foo:getField() (usually 2 table indexes, and a call). I don't think the added overhead here are too high to be ignored, but if it does become a bottleneck, the field could just be accessed directly.
The text was updated successfully, but these errors were encountered:
For example, replace uses of
LeafNode.parentNode
outside that class withLeafNode:getParent()
.Though the basic idea is simple, it requires changing a ton of the code, and is very error-prone. But this kind of thing is better to be done earlier than later.
Expected advantages:
Foo.__getters:bar
toFoo:getBar()
.__getters
are implemented using metamethods, so, when an object is flattened by callingobject:optimize()
, they aren't added to the object table. Which means that every access to the getters requires traversing the inheritance tree.node.parent
(expectednode.parentNode
) returnsnil
all the time. This hides the real error, asnode.parentNode
can also returnnil
if the node has no parent (is a root node). I've already spent a few days debugging such problems.getFoo
andsetFoo
methods.Expected disadvantages:
Foo.field
(just a table index) toFoo:getField()
(usually 2 table indexes, and a call). I don't think the added overhead here are too high to be ignored, but if it does become a bottleneck, the field could just be accessed directly.The text was updated successfully, but these errors were encountered: