Difference between revisions of "Talk:Lua FAQ"
(Some comments reinforcing Nexii's ideas) |
m (whoops typo!) |
||
Line 9: | Line 9: | ||
-- [[User:Nexii Malthus|<span style="color: #111; text-shadow:-1px -1px #ddd, 1px 1px #888;">Nexii Malthus</span>]] 14:19, 4 July 2024 (PDT) | -- [[User:Nexii Malthus|<span style="color: #111; text-shadow:-1px -1px #ddd, 1px 1px #888;">Nexii Malthus</span>]] 14:19, 4 July 2024 (PDT) | ||
: Hear, hear. I foresee a lot of work ahead of us SLWikians. If there is a direct 1:1 correspondence between LSL and Lua, well, in that case, we could do something similar to what Microsoft does on its documentation for .NET, where you get, for the same function, the C# and the VisualBasic variants — the idea being that | : Hear, hear. I foresee a lot of work ahead of us SLWikians. If there is a direct 1:1 correspondence between LSL and Lua, well, in that case, we could do something similar to what Microsoft does on its documentation for .NET, where you get, for the same function, the C# and the VisualBasic variants — the idea being that the function is the ''same'', it's just the language construct that uses the function that will change. | ||
: Other similar cases are those explaining, say, a RESTful API. The overall parameters are described, and then you get code snippets for implementing that call in several different programming languages, e.g. cURL/JavaScript/Python/PHP/Go, for instance. | : Other similar cases are those explaining, say, a RESTful API. The overall parameters are described, and then you get code snippets for implementing that call in several different programming languages, e.g. cURL/JavaScript/Python/PHP/Go, for instance. | ||
: However, I can imagine that this simplistic approach will fail in our case, especially if we start getting some divergence between actual functions (i.e., new functions that only make sense in Lua, such as those dealing with JSON; and old functions that only make sense in LSL, such as those to retrieve values from a List). While (speculatively) Lua could have its own "List-like" type — it shouldn't be hard to implement — I can imagine that accessing its members will look quite different. Or perhaps not. In any case, there will be differences. It might make more sense to have a "Lua portal" instead, and just link together equivalent functionality (so that you can look up something and see both its LSL and Lua equivalents). | : However, I can imagine that this simplistic approach will fail in our case, especially if we start getting some divergence between actual functions (i.e., new functions that only make sense in Lua, such as those dealing with JSON; and old functions that only make sense in LSL, such as those to retrieve values from a List). While (speculatively) Lua could have its own "List-like" type — it shouldn't be hard to implement — I can imagine that accessing its members will look quite different. Or perhaps not. In any case, there will be differences. It might make more sense to have a "Lua portal" instead, and just link together equivalent functionality (so that you can look up something and see both its LSL and Lua equivalents). | ||
: Exciting times ahead :-) Lots of work to do as well. — [[User:Gwyneth Llewelyn|Gwyneth Llewelyn]] ([[User talk:Gwyneth Llewelyn|talk]]) 01:39, 29 August 2024 (PDT) | : Exciting times ahead :-) Lots of work to do as well. — [[User:Gwyneth Llewelyn|Gwyneth Llewelyn]] ([[User talk:Gwyneth Llewelyn|talk]]) 01:39, 29 August 2024 (PDT) |
Revision as of 00:40, 29 August 2024
I really love the LSL Portal and so would appreciate if Lua can get the same treatment or coexist without causing confusion to existing or new scripters.
So I'm wondering about technical documentation and conflicts with LSL. Perhaps a) it might be wisest to create a "Lua Portal" that mirrors the LSL Portal but then is expanded over time. And/Or b) would all LSL functions pages (and the LSL Function template) be updated to show the Lua version? c) What if there is Lua-only function later or syntactical differences esp with functions that use or return lists as lists may not exist in Lua or work differently to Lua tables? And d) would a lot of the function documentation diverge too much due to differences in the languages in how they may need to treat types, operators and example code?
It seems a Lua Portal will be inevitable anyway, because there needs to be a central location where all the Lua-specific pages can be accessed from easily, such as developer resources (tutorials, guides and script examples and libraries), and Lua language reference just as easily as for LSL and also avoid confusing beginners dealing with two different languages on the platform.
Another thing to look at might be that there are a lot of LSL-specific pages that may need to be prefixed with LSL_ in their pages still, e.g. State, While, If, etc since Lua will have differences to LSL. On the other hand there are also some other portals that also invade the global namespace e.g. Coding Standard, Features, Glossary. All of this affects search functionality. A disambiguation page or template akin to wikipedia may be necessary in place of some of the existing redirects. If someone searches for "string" or "if" they get fed with LSL currently.
-- Nexii Malthus 14:19, 4 July 2024 (PDT)
- Hear, hear. I foresee a lot of work ahead of us SLWikians. If there is a direct 1:1 correspondence between LSL and Lua, well, in that case, we could do something similar to what Microsoft does on its documentation for .NET, where you get, for the same function, the C# and the VisualBasic variants — the idea being that the function is the same, it's just the language construct that uses the function that will change.
- Other similar cases are those explaining, say, a RESTful API. The overall parameters are described, and then you get code snippets for implementing that call in several different programming languages, e.g. cURL/JavaScript/Python/PHP/Go, for instance.
- However, I can imagine that this simplistic approach will fail in our case, especially if we start getting some divergence between actual functions (i.e., new functions that only make sense in Lua, such as those dealing with JSON; and old functions that only make sense in LSL, such as those to retrieve values from a List). While (speculatively) Lua could have its own "List-like" type — it shouldn't be hard to implement — I can imagine that accessing its members will look quite different. Or perhaps not. In any case, there will be differences. It might make more sense to have a "Lua portal" instead, and just link together equivalent functionality (so that you can look up something and see both its LSL and Lua equivalents).
- Exciting times ahead :-) Lots of work to do as well. — Gwyneth Llewelyn (talk) 01:39, 29 August 2024 (PDT)