(07-25-2022, 06:07 AM)mnrvovrfc Wrote:(05-05-2022, 05:59 PM)madscijr Wrote: Some features I would find helpful for future QB64:If this is added to QB64 then I'm just going to leave and not come back. You will have to do it yourself pretty much if you really want it. I don't want another M$VB-clone while there is already one out there! Sometimes I contradict myself but... I don't like the type sigils anymore and I don't mind "RETURN" being transformed. Otherwise the somewhat archaic syntax of QB64 inherited from M$QB grew on me a long time ago. It doesn't bother me. Making it more like VB then, it would really really bother me.
* Native dictionary (associative array) type. The basic of which can hold strings, but maybe make it like VBA's which can hold different types?
:
* Built-in / expanded support for hardware images. Built in hardware image commands for shapes (circle, square, line, etc.) and copy portion of hardware image. Maybe commands for tilesets? Or 3-D & isometric graphics? Whatever will make hw images and graphics easier to work with.
* Form/GUI editor and with events (just like VB6 & VBA) built right into the IDE.
* Optional "variant" type? (useful for operator overloading, would need an accompanying typename function)
:
Thank you for your reply.
Could you be more specific? I assume you are talking about variant types. I don't NEED variants - it has its use in some cases. But not all cases - the whole typeless (or whatever you call it) way they do variables in Python and JavaScript is maddening to me, so I don't mind strictly typed.
Likewise, an IDE with a built-in GUI editor isn't something I view as mandatory, more like a nice-to-have. That could be part of an alternate IDE, not replacing the existing one. I know there is inform, so at least there is some option.
However, I don't see the point of being against a native dictionary object or arrays inside of user-defined types. That stuff would make life a lot easier in many ways, and really should be added to the core QB64 language in my opinion.