AHKv2 is a masterpiece. Why does it not include built-in libraries for JSON and HTTP requests in 2023?

[sashaatx]

In my opinion JSON built-in libraries are A1 and HTTP requests are like ~D1 on the priority but,

As a language with such rich built-in capabilities and short hands, I can't imagine why these were left out.


[Mod edit: Moved topic from 'AutoHotkey Development'.]

[geek]

For JSON, largely because the development of it is not a priority to Lexikos. Especially because several good AHK implementations exist, and are very easy to grab from online. A good implementation in C/C++ would be considered for inclusion, but not a lot of people take interest in doing that. It's not like AHK is the only language where you're expected to grab third party libraries for useful JSON processing. Java and Kotlin are that way, as well as languages like Lua.

For HTTP requests, building a good flexible native implementation would be very difficult, and would require constant maintenance as the web continues to evolve. It's absolutely trivial to do by COM, and Microsoft handles all of the associated maintenance. I do think a few more documentation pages about the available options is warranted, but I don't expect it will ever be more of a built-in command than the bare-bones Download function (which is notably inflexible, but documents some of the COM options in the examples section at the bottom of the page).

[sashaatx]

For JSON, largely because the development of it is not a priority to Lexikos. Especially because several good AHK implementations exist, and are very easy to grab from online. A good implementation in C/C++ would be considered for inclusion, but not a lot of people take interest in doing that.

For HTTP requests, building a good flexible native implementation would be very difficult, and would require constant maintenance as the web continues to evolve. It's absolutely trivial to do by COM, and Microsoft handles all of the associated maintenance. I do think a few more documentation pages about the available options is warranted, but I don't expect it will ever be more of a built-in command than the bare-bones Download function (which is notably inflexible, but documents some of the COM options in the examples section at the bottom of the page).

Hi Geek, good speak so soon and on better terms.

I suppose I agree, by not developing something its not a priority. Especially as it was solved by dozens a decade ago, porting to a built in library would be trivial and in-demand. My question is more, why is the development of it is not a priority to Lexikos

[geek]

why is the development of it is not a priority to Lexikos

As I said, because several good AHK implementations exist, and are very easy to grab from online. This is what Lexikos has stated in the past that he does in the rare case he finds it necessary.

Porting these to a built-in library would not be as trivial as you might think, as AHK's built-in libraries are written in C++ and all of the third-party libraries make assumptions that have trade-offs. Especially in the handling of true, false, and null values. Either the AHK libraries mishandle those values, or they use a kludge that is not appropriate for baking into the language. New language design would be necessary to build something that is actually fully interoperable with the JSON standard.

[Adventurer]

A built-in library for HTTP requests is a big ask. But, I do have to agree that it is odd there's not a built-in library for JSON. There are good libraries for that, but everyone using different JSON implementations does get bothersome.

[malcev]

@geek, can You convert floats or doubles to string on output in Your json class?
Because now it shows issues:

Code: Select all

var = {"x": 0.7654321}
msgbox % JSON.load(var).x   ; shows 0.765432

For win10 We can use msdn api json parser:
In ahk v2 it is easy to run:

Code: Select all

#include winrt.ahk

if WinRT('Windows.Data.Json.JsonObject').TryParse('{"a":"b"}', &jo)
    MsgBox jo.Lookup('a').ToString() ; "b"

https://github.com/Lexikos/winrt.ahk

[sashaatx]

why is the development of it is not a priority to Lexikos

As I said, because several good AHK implementations exist, and are very easy to grab from online. This is what Lexikos has stated in the past that he does in the rare case he finds it necessary.

Porting these to a built-in library would not be as trivial as you might think, as AHK's built-in libraries are written in C++ and all of the third-party libraries make assumptions that have trade-offs. Especially in the handling of true, false, and null values. Either the AHK libraries mishandle those values, or they use a kludge that is not appropriate for baking into the language. New language design would be necessary to build something that is actually fully interoperable with the JSON standard.

For sure.

If you were to grant me that a big part of AHK's goal is an approachable language for Windows, providing basic automation short-hand for the Windows user and experience,

I have spent time on the Microsoft App store, the #1 developer tools in total count, and seemingly audience capture, are JSON viewers. I'd say its needed in-so-far as demand, the difficulty for the average user to understand json without things like libraries, & the number of people who develop new libraries to make up for this.

That said, keep up your good work. I look forward to cJson (unless you were apart of native.ahk )