Rinzwind wrote:1 ByRef/ByVal option for procedure arguments, especially strings (makes PureBasic more 'Basic' right? Instead of hurting your brain with pointers). So one can easily return multiple results from a procedure through output arguments.
2 Procedure overloading. Same name, different number of arguments or argument type
3 Unsigned data types (it's all about internal representation right?)
4 More platform specific standard libraries like registry and task scheduler handling for Windows. Things that many users will frequently need when programming for their platform. Again, make basic tasks Basic.
5 Hard one... easy ActiveX usage?
How do you define "more basic"? The Basic languages
I learned on did not have ByRef
or ByVal, so adding them does
not make it more basic to me. (I actually prefer most of the features of PB that take it further from "basic".) I would guess your definition of "more basic" is more accurately "more
Visual Basic".
...Does anybody know the first occurrence of those keywords in a language?
While I do agree that most of those would make PB "better" (by some arbitrary definition) had they been implemented in the first place, I am certainly going to vote
-1
to all except 1 & 3. However, keep in mind that Fred makes up his own mind on this stuff, and is rarely influenced by comments.
#1 Those keywords do not actually add capability to the compiler. They just handcuff you, the coder into an old mindset. Pointers are very simple, once you have done it a few times.
As an alternative until Fred does implement this (likely never), you can make macros yourself to replace a ByRef, although you will need one for a call and one for a proc definition. (Macro ByRef : @ : endmacro). Implementation for a Proc definition will be a lot more complicated, depending on what you want out of it. ByVal is redundant, since that is what PB does now.
#2 will most likely never be implemented, because it will break a LOT of old code. I think the updates are manageable, however, it is just as easy to append a Type to the procedure name, since you still have to create multiple procedures. And by appending that Type, you are keeping within PB's style. i.e. PeekS, PokeS, PokeL, etc, you can just as easily create MyProcL and MyProcS.
#3 is actually my favorite, but also very unlikely--it has been requested before. (Although it is already implemented for Byte and Word vars with .a and .u.) Right now, there are only three Types that are not available for Unsigned. For every type Fred adds, there must be a conversion to all of the other types. That means that if he adds ULong, UInt and UQuad, he must create conversions from ULong to Byte, Ulong to Ascii, Ulong to Char, Ulong to Word, Ulong to Unicode, Ulong to Integer, Ulong to Long, Ulong to Float, Ulong to Quad, Ulong to Double, Ulong to UInt, Ulong to UQuad, and Ulong to any other I missed. AND he has to create a conversion to go in the opposite direction for all of those types. Then repeat it for UInt and UQuat. That is at least 72 new conversions he'd have to manage.
#4 & 5...I would much rather Fred focus on Linux and Mac, and bringing them up to the robustness of Win. There are plenty of Windows specific libraries on this forum to handle registry mods, and numerous examples available scattered throughout VB, C# and C++ forums as well. Since they are merely API calls, there will be negligible language barriers to convert them to PB.
whether you or I like it or not...