Lua API reorganization

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

Moderators: Forum Moderators, Developers

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

Re: Lua API reorganization

Post by Celtic_Minstrel » May 26th, 2017, 12:11 pm

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.
Maintainer of Steelhive.

Tad_Carlucci
Developer
Posts: 264
Joined: April 24th, 2016, 4:18 pm

Re: Lua API reorganization

Post by Tad_Carlucci » May 26th, 2017, 5:58 pm

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
Forum Administrator
Posts: 3285
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Lua API reorganization

Post by Pentarctagon » May 26th, 2017, 6:40 pm

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: 1043
Joined: August 3rd, 2012, 11:26 pm
Contact:

Re: Lua API reorganization

Post by Celtic_Minstrel » May 27th, 2017, 12:41 am

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.
Maintainer of Steelhive.

DeFender1031
Posts: 11
Joined: March 19th, 2016, 8:29 pm

Re: Lua API reorganization

Post by DeFender1031 » May 28th, 2017, 12:46 pm

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