7. Syntax/code
* Separate character to "comment out" code. It would be nice to differentiate (both conceptually and syntax color) comments and code that has just been "comment deactivated". For me, these are two completely use different cases for me as a developer, even if the compiler sees them as the same thing. For example, use ' for comments, and ; to deactivate. If one sets the syntax color background to a sufficiently obnoxious color, sooner or later, that dead code will be removed, instead of just hanging there until one does not know why it was removed and if it might some day be needed again and is scared to remove it... Also, if they are logically separated, one opens up the possibility of future features, such as compiler warnings about such deactivated code.
* #Todo directive. Basically a comment which raises a warning. A list of the #Todo items in the code with the option of jumping to them would also be nice.
* #Deprecated directive. If added to a sub, calls to that sub will generate warnings on compile. Useful for gradually phasing out old code.
* Make "Then" optional in If.
* Unary operater for Not. Not(X) is not the typical way of doing it, Not X feels more natural and more in line with other languages. Even more so as the other logical operators are operators, not function calls (for example A And B, instead of And(A,B)).
* Project attributes would probably fit better in its on file, not in an activity module. Makes more sense that way. For backwards compatibility, both should probably be allowed for a while, but the old way should generate a warning.
* Static variables. Sure, one could use a global/module level variable, but it's not as clean.
* Enums. Enums make for more readable code.
* Layouts can be placed in a panel, to create a somewhat usercontrol-like effect. However, the usefulness of that is more or less negated by the fact that the layout is simply that, a layout telling what's there and where it is. To be really useful, one would need to be able to bundle the layout with its code, and choose what to expose to the parent activity. As it works today, there is no logical code separation, which limits the usefulness a lot. A bit better encapsulation would do a lot to clean up the code.
* File.WriteMap. It would have been nice to have a File.WriteMap2, which behaves in an analogous way to File.ReadMap2. In other words, it adds missing keys, changes keys which already exist in both map and file, and just keeps the value of keys which only exist in the file. It's not complicated to do (use ReadMap, match it to the new map as above, write it back), but it's nice not to have to. Would be very useful for settings, as not all settings are always written at the same time (say, for example, a typical "default value is the previous value entered").
* ReadMap/WriteMap that preserves order of items. A map with a dependable persistent order is immensely useful. For example, creating a cache with such a map is trivial.
* Sortable maps. Closely related with the above point.
* Separate character to "comment out" code. It would be nice to differentiate (both conceptually and syntax color) comments and code that has just been "comment deactivated". For me, these are two completely use different cases for me as a developer, even if the compiler sees them as the same thing. For example, use ' for comments, and ; to deactivate. If one sets the syntax color background to a sufficiently obnoxious color, sooner or later, that dead code will be removed, instead of just hanging there until one does not know why it was removed and if it might some day be needed again and is scared to remove it... Also, if they are logically separated, one opens up the possibility of future features, such as compiler warnings about such deactivated code.
* #Todo directive. Basically a comment which raises a warning. A list of the #Todo items in the code with the option of jumping to them would also be nice.
* #Deprecated directive. If added to a sub, calls to that sub will generate warnings on compile. Useful for gradually phasing out old code.
* Make "Then" optional in If.
* Unary operater for Not. Not(X) is not the typical way of doing it, Not X feels more natural and more in line with other languages. Even more so as the other logical operators are operators, not function calls (for example A And B, instead of And(A,B)).
* Project attributes would probably fit better in its on file, not in an activity module. Makes more sense that way. For backwards compatibility, both should probably be allowed for a while, but the old way should generate a warning.
* Static variables. Sure, one could use a global/module level variable, but it's not as clean.
* Enums. Enums make for more readable code.
* Layouts can be placed in a panel, to create a somewhat usercontrol-like effect. However, the usefulness of that is more or less negated by the fact that the layout is simply that, a layout telling what's there and where it is. To be really useful, one would need to be able to bundle the layout with its code, and choose what to expose to the parent activity. As it works today, there is no logical code separation, which limits the usefulness a lot. A bit better encapsulation would do a lot to clean up the code.
* File.WriteMap. It would have been nice to have a File.WriteMap2, which behaves in an analogous way to File.ReadMap2. In other words, it adds missing keys, changes keys which already exist in both map and file, and just keeps the value of keys which only exist in the file. It's not complicated to do (use ReadMap, match it to the new map as above, write it back), but it's nice not to have to. Would be very useful for settings, as not all settings are always written at the same time (say, for example, a typical "default value is the previous value entered").
* ReadMap/WriteMap that preserves order of items. A map with a dependable persistent order is immensely useful. For example, creating a cache with such a map is trivial.
B4X:
'Pseudocode...
Sub GetItem(Key as string) as string
If CacheMap.KeyExist(Key) then
Item=CacheMap.Get(Key)
CacheMap.Remove(Key)
else
Item=DoExternalFetch(Key)
end if
CacheMap.Add(Item, Key)
If CacheMap.Size>MaxItems then
CacheMap.RemoveAtPos(0)
End if
Return Item
End Sub
