[Bug 47104] Provide a method to create a non read-only copy of a mw.loadData result
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104 --- Comment #7 from Brad Jorsch bjor...@wikimedia.org --- (In reply to comment #6) I like the idea of having a table that can be set and is preserved across invoke calls, but that wasn't what was asked for in this bug request. And that's not going to happen, as one of the design goals for Scribunto was to specifically not pass information between invoke calls. pairs and ipairs can work by using custom __pairs and __ipairs functions which iterates over the immutable table and uses the key/value from the mutable table when present. After that iterates over the mutable table only using keys which aren't present in the immutable table. Yes. But that's quite complex and error-prone: note the procedure you've outlined won't work correctly if someone tries to assign nil to an existing value for the immutable table, for example. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47104] Provide a method to create a non read-only copy of a mw.loadData result
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104 --- Comment #6 from darklama darkl...@gmail.com --- (In reply to comment #5) I like the idea of having a table that can be set and is preserved across invoke calls, but that wasn't what was asked for in this bug request. loadData can appear to be mutable while being immutable by using two tables. Only the immutable table would be preserved with each invoke. (In reply to comment #4) The problem is making pairs and ipairs work in that case. And the same for # if we ever figure out a way to fix bug 47096. pairs and ipairs can work by using custom __pairs and __ipairs functions which iterates over the immutable table and uses the key/value from the mutable table when present. After that iterates over the mutable table only using keys which aren't present in the immutable table. See 4 suggestions to address # in bug 47096. With that fixed, __len could be calculated with either pairs or ipairs, but that is inefficient. A more efficient approach might be to use three tables, one immutable table, one mutable table for keys that are also in the immutable table, and one mutable table for keys not in the immutable table. __len = #immutable + + #mutable_unique -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47104] Provide a method to create a non read-only copy of a mw.loadData result
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104 Martijn Hoekstra martijnhoeks...@gmail.com changed: What|Removed |Added CC||martijnhoeks...@gmail.com --- Comment #5 from Martijn Hoekstra martijnhoeks...@gmail.com --- The copy-on-write suggestion sounds mighty scary if a module could modify loadData tables, and the modified table would be exposed to *other* modules. I think module writers want to be assured that when they loadData, the data is guaranteed not to be changed. I find it hard to come up with a reasonable scenario where a mutable loadData would be required, and it would create a dependency between a first #invoke of a module to subsequent invokes. (that is, to do something with the modified data on later #invokes you would need to know that an earlier #invoke has actually modified the data.) While I can imagine some situations where you would want to perform an expensive projection on data, and performance requires you to do that transformation only once, it does not sit quite right with me to create this kind of dependency between calls. If this kind of thing were to be implemented, I'd personally rather see an exposed _G.page, where page is either a table of settings for this module for this page, or where page is a table of module names with stored values for the module for the page (possibly with a metatable set to the running modules table for syntactic sugerring, so one can call page.myValue rather than page.thisModuleName.myValue) -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47104] Provide a method to create a non read-only copy of a mw.loadData result
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104 darklama darkl...@gmail.com changed: What|Removed |Added Blocks||48176 Depends on||47096 -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47104] Provide a method to create a non read-only copy of a mw.loadData result
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104 --- Comment #4 from Brad Jorsch bjor...@wikimedia.org --- (In reply to comment #3) Actually, darklama's comment makes me wonder. Could that solution be adapted so that the loadData tables aren't read only? More specifically, could the wrapper be changed to allow one to add a layer of local values in front of the read only data whenever someone attempts to write to the table? That way the read-only original values could be preserved for the next #invoke, but users wouldn't have to worry about loadData tables being read only. The problem is making pairs and ipairs work in that case. And the same for # if we ever figure out a way to fix bug 47096. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47104] Provide a method to create a non read-only copy of a mw.loadData result
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104
darklama darkl...@gmail.com changed:
What|Removed |Added
CC||darkl...@gmail.com
--- Comment #1 from darklama darkl...@gmail.com ---
What circumstances is a writable copy of a read-only table needed?
I think require() can be used when many of the key/value pairs
are going to change. A shallow copy may be the way to go when
only some key/value pairs are going to change, or the table is
going to be extended. I used a similar approach in a module that
was originally copying all the key/value pairs and wasn't
changing most of them.
ro_data = mw.loadData(Module:Name/data);
data = setmetatable( {}, { __index = ro_data });
data.whatever and data[whatever] will return the value of the
index from ro_data unless the index in data is assigned a new
value:
data.whatever = new value;
data[whatever] = new value;
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47104] Provide a method to create a non read-only copy of a mw.loadData result
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104 --- Comment #2 from Tim Starling tstarl...@wikimedia.org --- Cloning it (i.e. copying the key/value pairs individually) would defeat the purpose. It'd be faster to use require(), which does give a writable table. You can use the index metamethod, as darklama suggests, if that is appropriate for your application. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47104] Provide a method to create a non read-only copy of a mw.loadData result
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104 --- Comment #3 from Robert Rohde ro...@robertrohde.com --- (In reply to comment #2) Cloning it (i.e. copying the key/value pairs individually) would defeat the purpose. It'd be faster to use require(), which does give a writable table. This makes sense if one wants a writable copy of the whole thing, but the use cases I've tended to look at are things like: big_table = mw.loadData( Module:BigData ) Where big_table has lots of subtables and what one really wants to manipulate is only a small portion, e.g. my_part = big_table.group1.block5.subtable3. Cloning a small subtable is presumably faster than using require to load the whole thing. You can use the index metamethod, as darklama suggests, if that is appropriate for your application. Actually, darklama's comment makes me wonder. Could that solution be adapted so that the loadData tables aren't read only? More specifically, could the wrapper be changed to allow one to add a layer of local values in front of the read only data whenever someone attempts to write to the table? That way the read-only original values could be preserved for the next #invoke, but users wouldn't have to worry about loadData tables being read only. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47104] Provide a method to create a non read-only copy of a mw.loadData result
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104 Andre Klapper aklap...@wikimedia.org changed: What|Removed |Added Priority|Unprioritized |Low -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
