Now that R3 is out we all get to take a look at the new framework and the direction it is heading in. Right now it is is ONLY required for iOS but eventually it will be the only one … There can be only one! (Yes I watched Highlander )
It is very different…
I’m not crazy about the extensive namespacing because lots of LONG text on code lines make my glaze over but I understand why they went that way and would deal can deal with it…
But there is something else I am seeing that’s much more basic (or rather NOT BASIC) in philosophy that bothers me. They are working very hard to make it very hard to shoot ourselves in the foot… While at first blush that sounds like a good thing it has some not so good consequences… It makes Xojo more more nit picking when it does not really need to be, as well as less flexible and so make it more complicated , require more code to do the same thing in most situations and in general makes coding less fun.
As well as other discussions here (though some may have been in the beta forum)
It feels like an an academic idealistic IT approach for what should be able to be done and how to do it, rather than a practical ease of use focused one. It also seems overly formal for BASIC based language. RB/RS/Xojo has always had a good balance between safety and flexibility/ease of use… With the new framework that seems to be shifting in the wrong direction…
I know the Xojo engineers will likely disagree but in the long run we are the only judges that matter as we vote with our wallets.
To me it seems this approach will turn off many of those just learning and make coding more of a slog through the mud and give Xojo a less clear coding advantage over other options.
I want Xojo to succeed and be the fun product to code it it has always been… We are still early on in the new framework… I want to start this discussion so that we have some chance of influencing how the framework grows…
If you have taken a good look at teh new framework so far please share your thoughts…
You won’t have to deal with the namespacing at all except when mixing code from the old and new frameworks. If you are using only the new framework in a project, you can effectively ignore the namespacing entirely.
Yes, 100% agree their comments !
I think this would be a BIG MISTAKE because we XOJO in a high productivity differential and relatively simple learning curve, I fear that this change will have to find another option because for many of us I believe programming is just a way to improve our specialties and thus produce great tools to assist us in our professions and we have no time or interest in being super developers.
There’s no greater loss of productivity than bugs that occasionally appear (often at the very inconvenient time when someone is actually using your software) and take hours to track down all because of implicit conversions and such. While the new framework does require you to be more explicit in a few places, the result of this small extra investment is far more robust code.
Hi Geoff Perlman,
I understand your point of view but as I have mentioned my specialty is not programming for which I am so XOJO fan, because it gives me a very good and good productivity experience, I know that I speak for many when I ask you so that if something for change is made in an automatic way as when tools like StaticText were removed from the table and open a project when it is corrected automatically.
I know this is a great job for us but simple users is very scary!
The change from static text to label was simple as we could convert the super class and do it very accurately.
I’m not confident we could convert your code correctly and embody the intent correctly.
Strings are a great example of where knowing the intent would be difficult to get right.
Since they can be simply runs of bytes OR actual text with an encoding knowing which would require a depth of code analysis & data flow to know how you’re using “strings” that I would suggest we don’t do this.
[quote=151784:@Paulo Vargas]Hi Geoff Perlman,
I understand your point of view but as I have mentioned my specialty is not programming for which I am so XOJO fan, because it gives me a very good and good productivity experience, I know that I speak for many when I ask you so that if something for change is made in an automatic way as when tools like StaticText were removed from the table and open a project when it is corrected automatically.
I know this is a great job for us but simple users is very scary![/quote]
Hi Paul,
FWIW, I’m not a full-time programmer either and I’m constantly advocating for simplicity. But as with so many things, there are trade-offs. I don’t think numeric conversion in the new framework is that big of a deal. There are certainly going to be some new things you will need to learn but I really think they are an improvement for all.
Am I to understand that you’re in favor of making it harder to write correct code rather than easier ?
The old framework & certain of its datatypes, string is a good example, made it harder to write code that was well behaved.
Things like VAL also fail silently, or behave in surprising ways, so you end up with “bugs” like the on you reported <https://xojo.com/issue/12171> and cases like <https://xojo.com/issue/2140>
[quote=151810:@Norman Palardy]Am I to understand that you’re in favor of making it harder to write correct code rather than easier ?
[/quote]
No I am in favor of not making things harder/more inconvenient than they really need to me. That Bug I reported is an X-platform issue that you could fix, As for hex Just doc it does not do hex or allow specification of numeric base (Assume Decimal but but allow specification of Octal, hex or Binary) X = Val(item as String, Base as enum =Decimal). The other one I don’t see as a problem.
BTW the bug I reported was when I was purposely stressing/testing Val and Not teh result if a real world issue.
The vast majority of users were satisfied with and even liked how VAL worked. Are there some edge cases? Yes… but they are rare.
If you make life harder for everyone because of very infrequent edge cases you will make make the overall satisfaction with the product fall.
Trying too hard to protect us from ourselves is path to frustrating your customers…
Remember you hear mostly from these few who have issues with things like this and NOT from the vast majority or have no problem with or actually like how Val works with respect to parsing strings for numbers.
FWIW, I’m not a full-time programmer either and I’m constantly advocating for simplicity. But as with so many things, there are trade-offs. I don’t think numeric conversion in the new framework is that big of a deal. There are certainly going to be some new things you will need to learn but I really think they are an improvement for all.[/quote]
Of course Geoff, I understand that some things need to be relearned but I think you have to be careful for this learning not be too large because it may discourage some users.
I leave my embrace and say that I trust and admire XOJO team
Making it easier to write correct code is basically the direction the new framework is heading
And more consistent error handling
So once you learn one way you don’t have to remember that some things will throw exceptions, some return error code, etc etc like the current framework does
That’s a good thing
Will have to make changes to my code to work with the new framework for desktop? Will I have to make horrifying changes to my code in the future? Is this an actual quote ‘Dont worry, the old framework will exist for years.’. thanks
[quote=151894:@Norman Palardy]So once you learn one way you don’t have to remember that some things will throw exceptions, some return error code, etc etc like the current framework does
[/quote]
Except that somethings don’t deserve the hassle of exceptions ( though some most certainly do!)
The numeric FromText methods are a good example of what does not. Returning 0 is more convenient the vast majority of the time… The few times it’s not we can check for ourselves… that would be less work overall for us and easier for beginners.
Exception handling is a more advanced concept for a beginner… to having to deal with it from the start makes the language less approachable IMO.
[quote=151927:@Karen Atkocius]that would be less work overall for us and easier for beginners.
[/quote]
More work overall for you (you have to write extra code to check if its numeric if its empty etc etc etc)
And confusing as heck for beginners because code DOESN’T work as expected when val(string) returns a weird result like the case I cited where val(“info@123.com”) return INF not 0 and calculations are ALL returning INF.
You’ve been writing Xojo code for … 10 years ?
Some of the things I’ve said you look at and go “Well DUH!”
Watch the new folks on the forums & watch the mistakes that get made and you’ll see just a fraction of the things we get reported as “bugs” that are just “yeah it lets you do that but you shouldn’t because…”
I’m not harshing on you here at all Karen when I ask this. I really don’t have an opinion on this yet, but I’ve seen this argument a few times today. Maybe there is something I’m missing, but what would you do in a situation where zero is a valid result? In that case, you can’t use zero to indicate something went wrong.
Let’s say you have a textfield as “number of units” that you want to multiply by a price to get a total. If that field is blank, you can just use val(textfield1.text)*unitprice to get the correct price.
If you really want to then check if it’s numeric first, you can, but for quick stuff having val “just work” is fantastic. My gut tells me throwing exceptions for this one is a problem, but I haven’t worked with it yet so I need to keep my yap trap shut until I do.
Now, as far as enums no longer working like integers, THAT I have a problem with. LOL
When it and you are dealing with text in a TextField, when the user leaves the textfield I do
TextField.text = Format(Val(TextField.text), aFormatString)
That way you they can see how what they typed was interpreted and can correct it if need be.
)