How to convert to the new framework?

General
21

IMHO you should simply not convert. There is this long computing wisdom that says “if it ain’t broken, don’t fix it” that I verified through all the years I used computers.

From Xojo own saying “the classic framework is here for a long time”. Meaning probably “for as long as it does not break code”. And we all know how careful Xojo engineers are to maintain backward compatibility.

I tend to look at the new framework for its real value rather than as a fad that I should embrace to follow some trend. To me the questions are :

  • Could the new framework do better for MY app ?
  • Will it improve MY production ?
  • Is there some feature it will enable MY app to do that it does not do currently ?

With all the already written code, it would be rather foolish to refactor everything. But there are aspects where the new framework could improve it. For instance, I could take advantage of the new Xojo.Net.HTTPSecureSocket to have a Paypal listener in Xojo rather than one in PHP. But is that REALLY necessary ? Has the PHP in any way let me down so I should replace it by Xojo ? What could I do more in Xojo ? All questions I may simply put away, because it ain’t broke…

Why, for instance, should you break your encodless strings with Text ? Unless you are a masochist, go on with what works !

Things are quite different for new code. Would that be an iOS app where I have no choice, or a new project where the new framework can really make the difference, then I will probably don’t hesitate.

22

[quote=210082:@Markus Winter]Let’s assume I have a dict Carpark with the following key value pairs with the key being of class user and the value of class vehicle:

Homer - car1
Marge - car2
Lisa - car3
Bart - motorbike

old dictionary:

I can add or delete entries, I can give Lisa a new car4 and give car3 to Marge.

I can iterate over it with for each visitor as user in Carpark.keys

I can change Lisa’s hair colour and the maximum speed on Bart’s motorbike (I assume he tunes it).
[/quote]
New dictionary: You can do all the same stuff, in the same way. PLUS, there are some new features you can take advantage of. One of which is the immutable DictionaryEntry, which is faster to iterate over than the old Keys() method. But don’t let “immutable” throw you. You can use the Key from the DictionaryEntry to update the value in the dictionary just like you are used to doing. You can update the Dictionary, just not the DictionaryEntry, which is a copy of the key/value pairs.

23

Migration of existing code should be put off unless needed since the new framework will probably get more features/tools over time which could make a future migration easier and quicker.

However where a business case exists to migrate a portion of code now the first investment I would make is to create robust unit tests of the existing code before making any changes. That way unexpected results can be avoided.

However coding with new framework could be important in relation to Text. This is especially so for an app that might one day have to handle input from users internationally. It might be better to bite the bullet now than be plagued by broken code later. This is because the String/Text issue crosses boundaries between systems meaning it has to be considered end-to-end. I think a real-world Xojo String/Text conversion tutorial would be welcome if anyone is game…

24

@Michel Bujardet : I’d love to agree with you. I really dread redoing all my code. However, in the last years we have been taught by both Xojo AND Apple to start conversion early and to just do it. My trust in both companies just isn’t there.

Tomorrow Apple comes and says that a new library needs to be used for signing apps. Or there is a crash bug in folderitems. And Xojo says “oh, we can only do the change for the new framework”. It’s not like we haven’t had this before.

@Paul Lefebvre :

That’s totally naive. What else do you expect from us? We either use the new framework or we don’t use it. Or you put it in the trash bin.

25

Rip-n-replace is not a good strategy. I’m pleased I can mix classic and new framework in the same line of code: Unlike others who simply discontinued language(s) and told the dev community to learn a new platform cold-turkey.

Conflating operating system/hardware vendor idiosyncrasies with Xojo Inc. is a bit unfair. Even Linux has changing-library issues.

26

I have to agree. This feels more and more like the VB6/VB.NET mess we had 15 years ago, except now Xojo adds even more confusion by mixing both languages together. The reasons may have been valid (lack of resources to lauch a complete version of the new framework, scare of losing existing customes, etc.). Going cold-turkey may seem harsh and makes people angry, but at least the sitiuation is clear.

An overhaul of the languages was needed. I’m glad to see the new framework acts more like a modern programming language (feature wise, hate the .NET syntax). Lately, programming in Xojo feels a lot like programming in VB6 15 years ago: If you want to do advanced/modern stuff, you’ll need to use API declares everywhere. Luckely a lot of people in this community gracefully donate their time in writting libraries wrapping a lot of them. Again, feels like VB6, when ‘vbaccelerator’ wrote wrappers to help us :slight_smile:

In our company we’ve decided we dont’ write a single line in the new framework UNTIL it completely covers everything in the old framework. We will then write our new projects in the framework ONLY. We’ve put a serious bet with our company by continuing to use Xojo in the future. (I’ve had to fight/debate like hell to do so). And I sure hope there will be a switch in the options called ‘Disable old framework syntax’…

27

I’ve been down this road a lot recently. My advice is to write new code in the new framework where possible, but don’t force it on yourself. The new framework is missing A LOT of stuff, and you’ll wind up having to make concessions in one place or another. For example (desktop, web, and console):

No databases.
No threads.
No TCPSocket.
No RegEx.
No built-in encoding of binary to text, such as hex or base64.
No shell.
SpecialFolder is missing most locations.
No pictures.

Just a list off the top of my head. These are issues I would expect to be resolved eventually, but in its current state, the new framework is not ready for use outside of iOS projects. It can handle smaller tasks, which is why my latest open source projects use it, but I’ve found it pretty much impossible to develop a production-quality desktop app without the classic framework.

It will get better, but it just isn’t ready yet. So just wait. As for converting your 50k line project to the new framework… I don’t think that will ever happen. Porting from classic framework to Xojo framework is just too difficult, you won’t make it happen on such a large scale. Find+Replace techniques just won’t work, because so many pieces have changed that it’ll require basically rewriting each line.

For example, these two chunks of code are equivalent:

Dim Message As String = "Hello World" Dim World As String = Mid(Message, 7)

Dim Message As Text = "Hello World" Dim World As Text = Message.Mid(6)

Or

Dim Dict As New Dictionary For I As Integer = 0 To Dict.Count - 1 Dim Key As Variant = Dict.Key(I) Dim Value As Variant = Dict.Value(Key) Next

Dim Dict As New Xojo.Core.Dictionary For Each Entry As Xojo.Core.DictionaryEntry In Dict Dim Key As Auto = Entry.Key Dim Value As Auto = Entry.Value Next

Without even considering which is better, the simple fact of the matter is porting your project will require understanding every single line of code. It’s simply too much work for a 50k line project.

The good news is the classic framework will probably hang around for a very long time, because the Xojo IDE requires it, and is so large that it too will likely never be ported.

28

[quote=210185:@Beatrix Willius]@Michel Bujardet : I’d love to agree with you. I really dread redoing all my code. However, in the last years we have been taught by both Xojo AND Apple to start conversion early and to just do it. My trust in both companies just isn’t there.

Tomorrow Apple comes and says that a new library needs to be used for signing apps. Or there is a crash bug in folderitems. And Xojo says “oh, we can only do the change for the new framework”. It’s not like we haven’t had this before.
[/quote]

Contrary to you, my experience with RB/Xojo has been for 13 years one of remarkable stability, throughout all the crazy moves Apple has done, changing twice hardware base (68000 -> PPC -> Intel -> God knows what tomorrow ARM ?). If I had stayed with other tools, I would have had to rewrite large portions of code every time. I am not unique here, with many people here having such code that bonified with age instead of decaying.

As you say, it is a question of trust. I cannot change your feelings. Just share my experience.

About trust, I would not trust Apple even if they pretended being nice. All counts for them is bottom line, and when one is the most profitable company ever, to hell with those pesky developers small fish anyway. At every iteration of their system, would that be on Mac or iOS, they make sure something is not compatible. I don’t believe it is because they hate us byte crafters, but because programmed obsolescence is an integral part of their marketing ploy. Every year like clockwork they deprecate hardware by the use of a new system. That makes users feel inadequate, and they pull their credit card.

OK. I do hate when they do that. BUT I do profit from it. Lets face it, every new system is an opportunity to sell a new version, upgrades and service.

I believe Xojo is prepping indeed for the next storm, and that indeed the new framework is their best tarp against Apple whims and follies. After all, one of the main advantages of Xojo is to abstract us from the meanders of the framework in the first place. My point was not to ignore the new framework, it was not to transition too early. Becoming familiar with the new framework and experimenting with it to make sure that when needed we master it is paramount. But baking the cake weeks before birthday may be kind of unnecessary.

When you say [quote]What I’m missing is how I’m supposed to convert my 50kloc+ application to the new framework. [/quote] I am just trying to share how I would approach it. None of us has an infinite amount of time, and days are only 16 hours work ;). Setting priorities seems to me : first make sure money keeps flowing in, then prepare the transition. And on that last point, I tend to have a contingent approach : if it ain’t broke, don’t fix it. That does not mean in any way I cannot little by little update my code.

Among the possibilities you mentioned [quote]What I’m missing is how I’m supposed to convert my 50kloc+ application to the new framework. Go class by class? Go framework class by framework class like convert the memoryblocks first, then the timers and so on? Go bottom up or top down?[/quote] I would venture as saying it is probably far easier to go class by class. OOP is your friend. Also, when applicable, wrapping new framework in methods that support the older syntax saves a lot of aggravation refactoring innumerable lines of code. I have not experimented that, but it even seems feasible to create a myMemoryBlock that wraps Xojo.Core.MutableMemoryBlock or myTimer that wraps Xojo.Core.Timer and are just a replacement away to update older code. Of course, in the enchanted world of programming, not everything is ever that simple. But is it not the reason why we get paid ?

29
  • The Xojo frameworks (classic and new) are wrappers around OS native frameworks. Changes in the OS native frameworks do not trigger changes in the API we are using of the Xojo framework. The change from Carbon to Cocoa and the deprecation of QuickTime have nothing to do with Xojo. If Beatrix have had her application developed as a native Carbon one written in C, she would have had an unusable application. She would have had to re-develop it in Objective-C completely. Each of us should be grateful to ourselves to have chosen REALbasic for our applications, because Xojo made a smooth transition to Cocoa possible.
  • The new compiler will compile the classic framework for 64-bit too which is a strong signal that this framework will live long.
  • Another indication that the classic framework will live for long is that the programing language itself does not change (some of you remember the “transition” from VB6 to VB .NET probably vividly and it drove them to RB).
  • Also be aware that the classic framework is a namespace too. It is called Global (I would have chosen Classic). I think this might help over the time when mixing both frameworks.

It is really much too early to think about it, as the new framework is not mature (in terms of completeness, not in terms of quality). In addition to what Thom has already listed: the user interface stuff has also not been adapted to the new framework.

Personally I think from what I know about the RB/Xojo history (and about Objective C / Cocoa – that’s where I come from – and about compilers – my hobby) that the classic framework will never die. Maybe it will not evolve anymore after a certain point but that’s about it.

30

Guys: thanks for your thoughts. For now I’ll wait and will do a bit code cleanup.

@Xojo guys: from your replies I don’t really get how you expect us users to react to the change. Somehow I expect more than touting minimal improvements.

31

As long as the IDE is classic framework, those of us who have written large standard apps (that is: not tailor-made software), can safely assume the classic framework to be maintained and adapted to new versions of operating systems, where necessary.
But like Beatrix , I fear the moment where some management decision is made and the old framework is deprecated or just not adjusted, for this or that reason.
It would be one hell of a work to re-write such standard software to compile with the new framework. Horrible idea.

32

It’s amazing how time makes one forget pain. As I recall it, the first VB.NET was mainly only used for pilot projects. If anyone had asked “How do I convert 50K lines of code to early VB.NET” the answer might have been “increase your medication”. I recall no one asking questions like this - a fact which speaks for itself.
The new framework works with the classic Xojo UIs (Web & Desktops) and the existing IDE and is inter-operable with existing code. So there really is no comparison between using the new framework and the VB6 > VB.NET experience. It’s also difficult to understand the source of any confusion since the namespace makes it explicit what is new framework and what is classic. The only “switch” involved that I have found is from Strings to Text which does I think mandate standardizing on one or the other where possible.

33

Luck had it I discovered RB just as VB. NET was released. So my code survived the VB. NET transition. This is more than I can say for code I had written back in 1998 or so in VB (was it 4 ?).

I wish Microsoft had been as wise as Xojo in making .NET part of VB without breaking the camel’s back. Facing the resistance of people who still use VB6 to this day, they even finally decided to kill it in Windows 8. Probably one of the reasons why some people keep Windows 7. That should give them a hint. But like Apple, they are too big to care. They even try to kill Desktop altogether. With Windows 10, they no longer show listings of Desktop apps in the Windows Store, and one is supposed to wait for, next year sometime (could be Christmas for all we know), have desktop apps run in the highly speculative Centennial bridge. How is that to reward the innumerable developers who have been supporting their platform since Windows 1 ?

I like Xojo because it is a human sized company that cares.

That one is kind of a toughie. Especially since String is so ambivalent between bytes and characters. And because older code makes it such a confusion, especially when memoryBlocks are involved.

34

This is not a binary use it/don’t use it situation. We have precisely created the new framework so it coexists with the classic framework so you do not have to sweat over this. You can use the new framework for new stuff when it makes sense to do so, or you stick with the old framework. Or update your old code when the new framework has stuff to make that worthwhile. We are not forcing your hand one way or the other.

Since we put a lot of time and effort into making it possible to use the new framework alongside the classic framework (unlike the .NET situation), I was expecting pretty much the opposite of your response: relief rather than frustration.

We can only tout what it there now, so I don’t really get what you mean.

35

This seems like a good idea, but not likely to be all that useful until the new framework is more complete.

36

And this is one of the biggest pluspoints I see: If you have old projects, there’s no need to change to the new framework. Except for cases where
– you want to use a class that’s only available in the new framework or
– you want to have your code xplatform-compatible with iOS too.

In the first case, you can always add the new framework class and install a small conversion module that does the translation between old and new framework parameters. Obviously this could result in too much conversion, so you could find yourself porting more and more stuff to the new framework. In most cases translation modules will do fine.

And in the second case, of course, you’ll have to use the new framework throughout your projects. While the new framework is incomplete, you’ll still need some conversion functions where you have to use old classes. But this enables you to share code between all supported platforms. Every other solution would require a lot more work on developer’s side.

37

Yes, and what Xojo Inc. did is fantastic since we can take advantage of the new framework already without being forced to. It’s up to us what we want to use of the new framework and what to leave in classic.
Remember the arrogance of Microsoft back in 2000: they just dropped the classic stuff (VB6) and the first version of .NET was terrible.

38

@Paul Lefebvre : I think we are talking at cross-purposes. Or we have different backgrounds.

My background is enterprise. My speciality are processes. So when there is a change coming I expect a change plan. Or at least a rough idea what to do in the future. 2 frameworks are a waste of time and energy. For now I can accept that the new framework isn’t ready for prime time. But at some point in time we will need to change to the new framework. For this I’l like to see some help.

39

Being from an enterprise background as well my experience is “change it all at once” is almost always a recipe for disaster and being way over budgets of all kinds.

IF thats your plan of attack then stick with the classic framework until such time as you can rewrite 100% of your code base on the new framework.
I plan on doing it incrementally on the IDE itself.

We deliberately made the new framework something you can move to as it makes sense so YOU can decide when / if / how to move to it as it fits your plans and timelines.

I expect that the classic framework will be around for many many years (I’d put money on 5+ if I had to bet and perhaps much longer)

40

I see it more as a migration path. The plan Xojo has is undoubtedly that the new framework will be the one for future development. Expecting that on day one the whole framework is ready and the old one can replace isn’t realisistic. If that was the case you would be exposed to a situation where you didn’t have a choise but were obliged to replace the old code all in once.

I don’t know if i will be more or less pleased by the new framework but i think it’s a evolutionairy way of moving to the future.