What do you think of the new framework?

General
21

[quote=151747:@Markus Winter]The new framework can be seen in iOS but will come to the Desktop sooner or later. And while the old framework will be around for a few more years, the transition from Carbon to Cocoa has taught us that one should probably not expect any bug fixes or new features in the old framework, meaning it will be obsolete very quickly.

So what do people think of the new framework?

I came to REALbasic for a reason, and that was BASIC. I see the new framework as making the language more complex and thereby more unfriendly to beginners and BASIC-lovers alike. Code becomes a LOT less easy to read. Maybe it has some big advantage, but I fail to see it. But then I’m not an advanced programmer. Which brought me to BASIC. So the circle closes.

So what arguments could sway me to be enthusiastic about the new framework? And no, separate namespaces everywhere is not an advantage but a hindrance in my opinion …[/quote]

I believe the new framework came out mostly from limitations of the iOS framework, as a way to safeguard the integrity of the language. As it turns out, iOS is corseted in many many ways that were never as intense in Mac OS X. And I sincerely hope it never gets there.

For instance, no code can stop execution, so Msgbox exit in favor of Message, since the second one does not halt execution. And many more so. Most of the innovations, though, seem more the result of the new Text type, and an obvious intent on the part of engineers to protect us from ourselves. Why Text instead of expanding the current string ? That is a political decision to force users into “good habits”.

Ensue a lot of differences in the syntax of the language, mostly do based instead of plain verbs with parentheses.

When I saw that the first time around, I balked and it took me a day or two to come around, and look closer. You know the result. I needed old code, and wrapped most of the stuff I needed into methods that mimicked the older syntax. I could not quite go all the way, since in spite of being inaccessible, string remains a reserved word because it is used internally.

The end result of the wrapper, though, is that I am able to code mostly using the syntax I like, especially reuse code I already had, and let geeks be geeks with their convoluted desire to make us all speak C-ish.

I do not like the new framework much more than acne, but it is here to stay. I would have prefered strings on steroid, but Text it is. As long as I can produce the programs I want, it is more a minor inconvenience than anything.

New features around the date object or other things are not bad, though.

22

The new framework is like the new IDE
Didn’t want it, don’t like it much. Very disappointed to see how much different the code for iOS will need to be.

Ive been through this once already with the car crash that was VB6 to VB.Net
Thats why I came here in the first place.

23

[quote=151793:@Karen Atkocius]It won’t parse out a leading number from a string. That was a feature not a bug! Now we would need to do it ourselves 
 and it is tedious


  • Karen[/quote]
    OK, you’re correct in that Val will handle “123a” and not “a123” while the new framework doesn’t convert either of these because it sees them both as equally invalid. That’s significant as far as I’m concerned but I can see why someone who frequently dealing with text data that happens to have the numeric component at the front, would see it as more complicated. So Val is fine if your text comes after the number (as you mentioned in science) but not so good if it comes before the data (as is often the case in business).
24

[quote=151804:@Jeff Tullin]The new framework is like the new IDE
Didn’t want it, don’t like it much. Very disappointed to see how much different the code for iOS will need to be.

Ive been through this once already with the car crash that was VB6 to VB.Net
Thats why I came here in the first place.[/quote]
@Jeff Tullin I don’t think it’s that different. There are some areas (like numeric conversion) where it’s a little different. But most of your code won’t be that different. There are differences, no doubt about that. But where there are differences, I believe they improve the language. In some places, the language requires you to be more explicit, but this will result in fewer bugs in your code because you are being more clear about your intent.

25

[quote=151804:@Jeff Tullin]The new framework is like the new IDE
Didn’t want it, don’t like it much. Very disappointed to see how much different the code for iOS will need to be.

Ive been through this once already with the car crash that was VB6 to VB.Net
Thats why I came here in the first place.[/quote]

If you look closely at the utter unfriendly nature of the iOS framework, you will discovered far more cruel than .NET.

I think Xojo did a pretty good job abstracting us from that paraphernalia.

If only Microsoft had not littered Visual Basic with framework calls without the slightest concern for legacy code, VB .NET would not have been the mess it is today.

But if you think about it, Xojo already spared us the cruelty of the Cocoa framework. So new framework or not, Xojo remains Xojo, IMHO.

26

While there are some iOS-specific behaviors that different because of how iOS itself works, the core parts of the framework, such as numeric conversions, how the new Text and Auto data types behave, etc., are the result of years of watching how users use the language. We have seen the bugs users unknowingly create because of implicit actions in the framework. By being a little more explicit in the new framework, you save a lot of lost productivity in bug hunting down the road.

27

Outside of XPlatfrom what brought people to this product was ease of coding
 I hope Geoff realizes that the approach to the new framework[quote=151808:@Geoff Perlman]OK, you’re correct in that Val will handle “123a” and not “a123” while the new framework doesn’t convert either of these because it sees them both as equally invalid. That’s significant as far as I’m concerned but I can see why someone who frequently dealing with text data that happens to have the numeric component at the front, would see it as more complicated. So Val is fine if your text comes after the number (as you mentioned in science) but not so good if it comes before the data (as is often the case in business).[/quote]

I submit units are part of business too


If there is a leading dollar sign the text could be “$29.67/pound”


Dim S as String = “$29.67/pound”
Dim PricePerPound As Double = Val(S.Mid(2))

In any case why make life harder for more people than one needs to?

  • Karen
28

I see how Text and the retirement of string were intended to impose safer ways of doing things, and how that can be good for users by sparing them the possibility to create bugs.

I would have preferred String was not retired, but simply given the attributes of the current Text. After all, when we went from byte strings Ă  la AppleSoft Basic to UTF-8, string it remained, although the very nature of a string of Unicode glyphs is quite different.

It is too late to argue, anyway. String is dead, long live Text.

29

That wasn’t possible without breaking existing code.

30

[quote=151817:@Karen Atkocius]I submit units are part of business too


If there is a leading dollar sign the text could be “$29.67/pound”


Dim S as String = “$29.67/pound”
Dim PricePerPound As Double = Val(S.Mid(2))

In any case why make life harder for more people than one needs to?[/quote]
But see there you are handling the case of the $ because you know VAL won’t and are not handling the case of “/pound” because you know it will. That’s fine as long as you know exactly how VAL works but it’s not obvious or intuitive.

What I would like to see (and I’ll admit there may be good reasons why this can’t or shouldn’t be done) would be to have the new FromText functions start from the left and strip away characters until they reach a numeric one, then continue until they reach a non-numeric character and drop everything else. That way, you could pass “$29.67/pound” to Double.FromText and get back 29.67.

Again, there may be good reasons not to do that but if there are not, that would certainly be convenient.

VAL is also not locale-saavy while the new conversion functions are.

31

[quote=151831:@Geoff Perlman]But see there you are handling the case of the $ because you know VAL won’t and are not handling the case of “/pound” because you know it will. That’s fine as long as you know exactly how VAL works but it’s not obvious or intuitive.

[/quote]

I disagree strongly.

As i said going from left to right and finding any valid number present is simple to understand, easy to remember and intuitive for most. Do you really think otherwise???

And A single character money sign is standard
 In fact if you put the method on teh currency type you could make it local savvy in do it then it could be:

Dim PricePerPound as Currency = Currency.TextToValue("$29.67/pound", LocalizationIfNeeded)
Or
Dim PricePerPound as Currency = Currency.TextToValue(“29.67/pound”, LocalizationIfNeeded)

And both should work


And THAT is how a modern RAD framework should work!

  • Karen
32

[quote=151833:@Karen Atkocius]I disagree strongly.

As i said going from left to right and finding any valid number present is simple to understand, easy to remember and intuitive for most. Do you really think otherwise???

And A single character money sign is standard
 In fact if you put the method on the currency type you could make it local savvy 
 then it could be:

Dim PricePerPound as Currency = Currency.TextToValue("$29.67/pound", LocalizationIfNeeded)
Or
Dim PricePerPound as Currency = Currency.TextToValue(“29.67/pound”, LocalizationIfNeeded)

And both should work


And THAT is how a modern RAD framework should work!

  • Karen[/quote]
33

meant to edit


A change such as that would have been welcome and help to make the new framework more desirable and not more of a pain.

OK make that Currency,FromText

and that one would be the only one to allow a leading character

All the Numeric FromText Methods should not error for truing characters
 And that would also allow easier code conversion to the new framework

  • karen
34

Look, this is just another case of Geoff and his engineers implementing something that no one was asking for, in a way that steals productivity cycles, and is very intrusive to the way things have been done which seem to have been working just fine for the most part. One needs no more recent example than to look at the new IDE. Was it really necessary to change the whole UI? Were the implemented changes a better use of screen real estate? Did it make you more productive? The hardcore Xojo fanatics will say “yes” but the majority know that the real answer is no.

Debating Geoff or any of the engineers is useless. Geoff isn’t going to change his mind and his engineers are all going to fall in lock step behind the one signing the checks. Therefore, you can either fall in line too or speak with your wallets and start investing your time and money in other tools. Xojo is and has been deaf to the needs and wants of the existing user base in an effort to appeal to NEW users for a long time. How many times does he have to abuse you before you say enough is enough? As it has happen so many times before, Geoff and his crew are going to do what they’re going to do regardless of what you say. So either drink the Kool-Aid Geoff is handing you or move on.

Sometimes the grass really is greener on the other side.

35

No one should mistake explaining our thinking for not listening. We make lots of changes every cycle based on user feedback.

36

[quote=151835:@Karen Atkocius]All the Numeric FromText Methods should not error for truing characters

[/quote]

That should be trailing characters.

Besides being more user friendly it really would help the conversion of code from the old framework

  • Karen
37

That’s incorrect. This is a discussion and in order to have one, both sides need to explain and discuss the logic of the situation. As Travis has pointed out, we have often made changes based upon discussions like this one. The point is to review all sides and see if a better solution can be found.

38

[quote=151835:@Karen Atkocius]meant to edit


A change such as that would have been welcome and help to make the new framework more desirable and not more of a pain.

OK make that Currency,FromText

and that one would be the only one to allow a leading character

All the Numeric FromText Methods should not error for truing characters
 And that would also allow easier code conversion to the new framework

  • karen[/quote]
    With Currency this makes a lot of sense because currencies have a standard format which can be derived from the locale.

For numeric conversion functions, are you saying that trailing characters should be stripped but leading characters should not be?

39

Really? The time to have a discussion like this is BEFORE it is implemented not afterwards. The implementation of the new framework is an edict, not a call for discussion. I liken it to having a discussion about having a baby after you find out that you’re pregnant.

40

It is not practical for us to debate every API with the user community. However, when members of the community take issue with something we have implemented, we are certainly willing to discuss it.