There are a variety of ways that could be implemented and it doesn’t have to try to mimic any other language. Xojo could do it in a way that suits it and its users best.
I often need to look up algorithms and source code that are only available in Python or C/C#. When I try to adapt the code in Xojo, these differences in the language make the process harder and slower, because in addition to focusing on the algorithm itself, I also need to pay attention to expanding += and ++. In this case, verbosity means added complexity. With variable = variable + 1 I read two words, with variable +=1 there is only one word in the line. Less distraction and less errors.
Assignment operators would also make it easier to integrate Xojo in a workflow that includes other languages, and would contribute to a wider adoption. Anyone who has learnt just a bit of Javascript or Python will know these conventions. The real differences that make Xojo appealing should not be these, but its framework and the cross-platform compilation.
It is 2025, not 1998, and these operators are an industry standard that is universally accepted and understood. Insisting on being the odd language that does not have them is not “thinking different”. It is like producing a car with a joystick in place of the steering wheel, it does not work because no matter how fond you are of that brilliant idea, the market expects the steering wheel.
6 Likes
Well, with copy&paste, you don’t even need to write it twice.
As I have said more than once. The suggested syntax has two immediate advantages:
- it removes the risk that you get two different, but similarly named variables in the code without noticing.
- the intent is more obvious in the new code, because it is more readable, with only one variable name to consider.
Also pointed out, nobody is suggesting that you must use the syntax. If you don’t like it you are perfectly valid to not use it. I just don’t see why you object to others using it.
Better use of Xojo engineer time ?
2 Likes
And I also responded to what you’re writing.
In my opinion, the time invested in modernizing the language is well spent.
1 Like
And it’s largely immaterial anyway. If you divide the development time of a project by the number of lines of code, the time to type each line will turn out to be just a small fraction of the total time spent. Development won’t get noticeably faster if one needs fewer key strokes to type each line.
1 Like
It’s currently number 9 on the most requested fixes, so opinions clearly vary.
1 Like
Isn’t other things to do before that ?
Say printing with the htmlviewer is an example…
I don’t think anyone has said it had to be done to the exclusion of all other things. I would love for PDF classes to work with UTF8, so I could finally use the Charts system. Given my main app is completely multilingual I can’t use it until it work together properly.
Equally, charts could do with some additional features, I’ve lots of requests in for those. I wait patiently for progress.
My reason for creating this thread was to judge opinion for the feature.
1 Like
Your point has some merit, but it begs for the implementation of all of these operators (in all circumstances) and not just simple single line inc and dec. And these operators are the least of your concerns when “porting” algorithms from c code. The ternary operators are far more insidious, the much more prevalent use of references, naked references and address pointers are much more important (and deadly if overlooked).
I’ve used C, C++ and Python and I don’t want my Xojo code to look anything like them. If I did, I’d use those tools instead.
Yes it’s 2025 and not still 1998, and Geoff has wisely and admirably steered Xojo’s direction and feature set towards his vision and target audience over all those years. I very much respect his judgement!
2 Likes
Code completion in the editor avoids typos, and even manual typos are caught at the next compile unless either one happens to match another variable name that’s also of the same Type.
It might be more readable to some, but it’s also confusing because += and =+ are different operators. Which one do I want? Which one does Xojo support? etc
++ on a loop index is about the only one I’d ever care to use, and I try to use For Each instead to avoid all the possible off by one boundary errors. (Hate the zero based indexing, although I’m thoroughly familiar with its basis way back in machine language. How many items do I have… OK let’s run a loop up to one less than that… what!!! …why???)
1 Like
=+ isn’t an operator, at least none I’ve ever come across, and Xojo does not allow:
Variable = +10 // the Plus makes for a syntax error. Even without spaces.
I was surprised by this but if you try it you’ll find out. Sure you can get caught out with -
VB supports these operators and that’s not at all C like, it’s even the original inspiration for Xojo.
1 Like
Ah, the VB connection is insightful.
But I couldn’t care less about what C and C++ do. They’re a whole different beast, and more of a counterpoint of why something should NOT be done. 
1 Like
VB also allows “Variable++” and “Variable–” but only as a single line, not inline.
No 
So, stop to add arguments.
You asked something / made a feature request, now is the time to wait (or not) if this will be implemented.
A week (and some prior demands) later, you know how popular it is.
It seems to me that a better task for Xojo would be to allow us to define our own operators. Then we could each create our own preferred set of operators and they wouldn’t have to worry about any of this +++ stuff infecting the language at large.
Public UnaryOperator ++ (byref value as integer)
value = value + 1
End
Public JoiningOperator += (byref left as integer, byref right as integer)
left = left + right
End
3 Likes
You would also need inline functions to not suffer a large performance penalty. Method calls cause slowdowns. You could also do with Generics so you didn’t have to implement each of the data types.
I’m not arguing. Only pointing out issues in response to others issues / questions.