Not criticizing your coding style, but as an example of your point, that's not the best only because Ubound is perfectly suited for a For loop.
@Eric W True. My only point is the framework will have to have
Uboundavailable everywhere to make it work, where presently there is
Lengthetc all being all 1-based.
Ubound is the upper bounds of something (usually an array). Count is a count of something. Size is a size of something. Len/Length should be joined for consistency, but the others are all different things and have their uses.
Edit: Additionally count, size, and length all have legitimate uses for zero. The problem is when things like
IdxField, which implies an index, has no zero. FolderItem.Item isn't really 1-based when you know the underlying reason. I don't recall where I read it, but Item(0) is really the parent level (like
ls - though I'm not sure if that influenced it).
Also citizen-programmers tend to think 1 is the first counting number not 0, which is why VB tried to accommodate both. But there are inconsistencies with things like memory blocks which have a one-based Size property, that citizen-programmers would understand, but zero-based access as only professional programmers would see the world. Option Base command anyone?
Well the only Feedback case I could find on this subject is a request to make everything 1 based!!!
I can't imagine why it took five years to close it but it was - thank the deity!
There is no difference in the code quality produced by a 'professional programer' and a 'citizen programer'. Both can produce truly beautiful or awful code! The only difference is the opportunity afforded to each to practice the art.
As a citizen programmer, I strongly disagree with the prejudiced opinion that you expressed. Citizen programmers are not subhumans; we can understand concepts like any "fully human professional programmer".
There was nothing pejorative intended about citizen-devs and 1-based coding. It is natural because citizen-dev projects often start with spreadsheets referenced Top-Left from Cell A1 as a 1-based system, or word processor macros where word-counts are 1-baed or SQL statements where the first row is Row 1. In fact no one in the real world gets up in the morning and thinks -1 (neg-one) items means there is none so that
ubound = 0 means there is really one. The only reason why things are zero based is so we don't loose a position in the address space which was a concern when it was only had 256 8-bit values but with 64 bit we should be able to afford to the cost of loosing an address to maintain 1-based compatibility.
So if Xojo wants to be citizen developer friendly, I think it should accommodate both zero and one-based concepts with the caveat that 1-based code might execute fractionally more slowly. So everything should have a Unbound with no exceptions, but no one should be forced by the language to code in zero bases if that doesn't fit their use-case - in a perfect world anyway.
This does not mean I will ever be a fan of
What I find interesting is the seeming absolute resistance to change. The "New" now deprecated framework was designed to mitigate these issues without breaking code.
For example Xojo.Core.Text.Mid is zero based and so becomes consistent. String.Mid remains 1 based. Doesn't break existing code, but does offer a way to simplify your code with a bit of adjustment to your thinking.
If you are able to ignore the "Wall of Code" namespace issue then you can see that the deprecated new framework added some cool stuff. Take for instance the beginswith and endswith functions of text. If s.left(3) = "Yes" vs If t.beginswith("Yes") - you'll notice in the second example I don't need to specifiy the length of "Yes".
While Xojo appears to follow the Microsoft way in that deprecations aren't acted on for years. I do wonder if the new API2.0 is going to mean we have Date & nDate.
Should Xojo have created a new product (XojoX?) that only included New Framework items and classic items that would be deprecated when replaced? This might have removed the "Wall of Code" complaint that seems to have been largely a learning curve issue.
Just my thoughts on this conversation.
Happy New Year to you all.
Greetings of the season Wayne! Hope you are enjoying the summer weather as much as I am ;-)
The aim of Xojo should be 'low-code', irrespective of an individual programmer's zero or one-based preference. What I think this means is:
1) Everything should have both a
Count and a
Ubound so people can test in the way that suits their circumstances.
2) There should be a new
Empty data type / function so I can say
Do Until Array.Empty or
If String.Empty Then without having to know if it's
Count= 0 or
Size = 0.
3) Everything should have an
LBound including things that have a Count.
4) Arrays, Dictionaries etc should all have an optional OptionBase parameter in their dimensioning.
Otherwise everything should stay the same as the default so no user code gets broken or starts operating in unexpected ways causing bad things to happen.
IMHO deciding that zero-base is the universal future of Xojo is about compiler-friendly low-level code not use case-friendly low-code, since in the real world most things start at number 1. However my point is the language should be rich enough to allow safe interoperability between zero and one-based addressing.
@Eric W reason why things are zero based is so we don't loose a position in the address space which was a concern when it was only had 256 8-bit values but with 64 bit we should be able to afford to the cost of loosing an address to
May I politely point out that the you actually mean "lose" and "losing", not "loose" and "loosing".
Personally I am quite happy with 0-based for offsets and 1-based for counts. So "abc" has a count of 3 and the first character is at offset 0 in the string.
What I would like to see is more string functions such as PHP provides (although perhaps with better names). F'rinstance, I entirely agree with Wayne in his praise for .BeginsWith and .EndsWith. However it would be nice if .Replace allowed me to slice out and replace text based on a start position and an end position. Thus, if I want to replace a <body> element with my own one, I can look for "<body" (gives a startpos), look for ">" using the startpos in the IndexOf (gives me an endpos), and then .Replace using the startpos, endpos, and replacement string. At the moment I have to concatenate a .Left, a .Right, and the replacement string, which must be slower.