After years and years I've figured something out

for index = arr.Ubound downto 0

My only point is that, unlike using some Count property in a For loop, Ubound requires no additional math to adjust the bounds.

In other words, Ubound is already a natural fit for zero based operations.

True. My only point is the framework will have to have Ubound available everywhere to make it work, where presently there is Count, Size, Len, Length etc 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?

@Eric Wilson: 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”.

Note that the term encompasses even those developers we suspect cannot be fully human based on their sheer output and availability. cough @Christian Schmitz cough

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.

[quote]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”.
[/quote]
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 For...Next however.

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 :wink:

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 Ubound(-1) or Len(0) or 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.

Cheers,

i did think it might be nice if the IDE helper (when you start typing it shows you the function prototype and its parameters) thingummy could have ‘This is 0 based’ or ‘this is 1 based’ appended to it.

Am I the only one who check 0-based / 1-based in the LR ?

No, you are not. :slight_smile:

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 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.

Or use a regular expression.

Personally I don’t find they make for maintainable code.

[quote=420654:@Wayne Golding]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.[/quote]
We cannot switch from String to Text as its Unicode handling is too high level. A critical part of our system, which involves a 3rd party product, processes data the same way as the Xojo String type. If had switched to Text we would have been stuck.
I also read that the Text was slower than String which would have also caused issues for us.

Adding additional functions to String such as BeginsWith / EndsWith should be easy for Xojo to do. In fact, you could do it now with a very simple Extends method.

Function BeginsWith(Extends pHayStack As String, pNeedle As String) As Boolean Return (Left(pHayStack, Len(pNeedle)) = pNeedle) End Function

When I code, I often point my mouse at the method name to see the params. Maybe that could be updated to state if an index is 0 or 1 based? maybe in bold or red?