Lua API reorganization

Discussion of Lua and LuaWML support, development, and ideas.

Moderator: Forum Moderators

User avatar
Celtic_Minstrel
Developer
Posts: 2166
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

Re: Lua API reorganization

Post by Celtic_Minstrel »

I intend to update mainline references to them at some point, yes.

I'm not sure if I can make it "warning lua" instead. It'd make sense, certainly.

Sapient: It's only partially implemented. I don't see how just rearranging documentation could get similar gains. Also, if you're worried about typing more characters, you could always do as before and write eg "local T = wml.tag". I don't think most of them are more characters though? For example, "wml.variable.get" is shorter than "wesnoth.get_variable".
Author of The Black Cross of Aleron campaign and Default++ era.
Former maintainer of Steelhive.
Tad_Carlucci
Inactive Developer
Posts: 503
Joined: April 24th, 2016, 4:18 pm

Re: Lua API reorganization

Post by Tad_Carlucci »

First off, let me say that, in general, I support the idea of reorganizing the interfaces to be more logical and, hopefully, easier to learn and remember.

That said, the question is: is there a technical requirement which necessitates the change, or is there a broad community consensus calling for it?

If the idea is to build consensus by presenting an example, I like where you're going.
I forked real life and now I'm getting merge conflicts.
User avatar
Pentarctagon
Project Manager
Posts: 5527
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Lua API reorganization

Post by Pentarctagon »

Well, given that the wml.* changes have already been committed and mainline currently gives a fair number of deprecation warnings, I'd say we're past the example stage of this.

I guess one question I would have is why parts of the Lua API is being renamed/deprecated during what's supposed to be 1.14 Beta 1.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
User avatar
Celtic_Minstrel
Developer
Posts: 2166
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

Re: Lua API reorganization

Post by Celtic_Minstrel »

Well, it's not like the old forms are being removed, so nothing will break, but you do have a point. I guess I'll disable the deprecation warnings until after 1.14.
Author of The Black Cross of Aleron campaign and Default++ era.
Former maintainer of Steelhive.
DeFender1031
Posts: 11
Joined: March 19th, 2016, 8:29 pm

Re: Lua API reorganization

Post by DeFender1031 »

The purpose of the idea is to provide a cleaner and more organized API which is grouped by what category of thing the API applies to (to be more intuitive for developers using the API) rather than grouped as they were by which part of the code they originate in (a distinction which sometimes makes things easier for the developers making the API, but is of little importance to those using it, nor, in my opinion, should they particularly need to be aware of it). I tend to favor APIs which are intuitive for the API user, even if that means that internal code from both C++ and Lua gets put in the same file or table. I should clarify that it was not my intention to have deprecation warnings added until (A) there is broad consensus to prefer the new organization over the old, (B) the new, more organized API has been around for a while, (C) all mainline code is up-to-date with it and (D) the add-on developers are mostly working with it as well. (Also to be clear, even after deprecation, I don't think the old API as a whole should be removed until the vast majority of add-ons on the official server for whatever version we're up to at the time are no longer using it. On the other hand, certain functions, proxy objects, or or other individual API operations from the old API can be removed or updated individually on a case-by-case basis as the code or architecture changes no longer support that particular paradigm, as they would have been in that case anyway.)
Post Reply