(03-02-2023, 10:46 PM)mnrvovrfc Wrote: Some people might protest that it might be great if QB64(PE) supported an object-oriented programming style, in order to have methods to operate on data, which looks sensible from the point of view of databases. But then getting fancy with polymorphism, templates and stuff like that isn't cool if somebody like this topic's starter desires to keep it fast and simple...
I agree that approaches like polymorphism are overkill and a headache.
For me, the main benefit of supporting simple objects (no crazy polymorphism) would be compatibility with calling & using OO COM type APIs for things like starting up an instance of Excel and controlling it from BASIC.
I think most people do not want or need OO. Having a data structure that _resembles_ a JavaScript object (but is not really OO - no classes or methods, just a more powerful UDT) where you can have nested arrays / arrays of objects / objects nested in objects / etc., and easily access each data element at any level with a string key using simple dot notation, and be able to serialize/deserialize the whole thing to/from JSON that can be read/written to/from a file, would be very powerul, while still keeping things simple for the programmer in the spirit of BASIC.
A SQL database with a server is useful if you have a lot of values to share between users on a network and want to run queries, sort values, filter data, etc. In cases where you're just loading in values from the local filesystem, making some changes, and saving them back to the file, I think using JSON keeps things nice and simple.
Also, a JavaScript type nested data structure gives us a way to easily work with objects that come back from systems like REST Web services, without needing the language to be true OO. And that ability to interface with REST services will make QB64PE very useful for a lot of things.
That's just my take at this point!