The latest Xojo blog post was again something about the new framework. How great the framework is and so on. This is giving me really bad feelings about how we are supposed to “use the 2 frameworks side by side for the next years”. Not going to happen I think. But that’s IMHO.
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?
How can I do a code cleanup like identifying classes or methods that I don’t use anymore? How can I find out which classes I have converted? Track this manually for 450 classes? What is missing? What doesn’t work in the new framework?
Of course, everyone has different code with different styles of coding. So I’m mostly interested in ideas. Has anyone - except our resident geniuses - tried to tackle this with a larger application?
The string to text conversion is the one that sounds the scariest. My core algorithm deals with encodingless strings. Can I start to convert the parameters of one class to text without having to bother with manual conversion before using the class or using the parameter in the class?
The classic framework will not go away for a long time. The new framework isn’t even finished when it comes to desktop applications. The classic framework will also compile for 64-bit. I wouldn’t care too much about this for now (my guess is that “now” means many years).
[quote=209913:@Beatrix Willius]The latest Xojo blog post was again something about the new framework. How great the framework is and so on. This is giving me really bad feelings about how we are supposed to “use the 2 frameworks side by side for the next years”. Not going to happen I think. But that’s IMHO.
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?
How can I do a code cleanup like identifying classes or methods that I don’t use anymore? How can I find out which classes I have converted? Track this manually for 450 classes? What is missing? What doesn’t work in the new framework?
Of course, everyone has different code with different styles of coding. So I’m mostly interested in ideas. Has anyone - except our resident geniuses - tried to tackle this with a larger application?
The string to text conversion is the one that sounds the scariest. My core algorithm deals with encodingless strings. Can I start to convert the parameters of one class to text without having to bother with manual conversion before using the class or using the parameter in the class?[/quote]
I too need to start planning the migration to the new framework and would appreciate and tips from those who already started this journey.
@Eli: I don’t believe this. Really I don’t. Been burned by too many bugs that weren’t fixed for Carbon because Cocoa was “just around the corner”.
@Christian: need to think about “new framework for new stuff”. That would mean mixing old and new. But whatever strategy we use for converting we will be using both frameworks anyhow.
These two cases are not comparable at all: Carbon to Cocoa was (indirectly) forced by Apple’s decision to not support Carbon apps I think from 10.6 on. The deprecation of the classic framework will take years, as this is under control of Xojo Inc. It won’t happen for many, many years.
Xojo.Core.Date is another good example. It has much better handling of time zone information. If your app relies on people collaborating from all around the world it makes displaying dates correctly much more straightforward.
Well, the Xojo IDE is mostly written in Xojo using the Classic Framework so if we were to whack the Classic framework, that would be problematic for us.
No one is advocating that your take your existing projects and attempt to convert them to the new framework. The reason we are keeping the classic framework around is precisely so you don’t have to do this.
My blog post is just pointing out “my favorite new Xojo framework features”. The idea is to get all you long-time Xojo users to remember to look at and take advantage of what the new framework offers.
As an example, I recently had a client ask me to add a feature to an app I created for them years ago. The feature was a new component and needed to display some new data. I decided to use the new JSON methods and Xojo.Core.Dictionary for this new component. This allowed me to quickly add the feature since I find the new JSON methods and Dictionary easier to work with. I did not go back and change any pre-existing code; that still uses the classic framework.
[quote=210046:@Markus Winter]For Each entry As Xojo.Core.DictionaryEntry In myDictionary is “crazy easy”, but For each key as string in Dict.keys is what difficult?
What am I missing???[/quote]
The DictionaryEntry class represents a single key-value pair in a Dictionary. It is immutable and is not tied to the Dictionary it was created from, so subsequent updates to the Dictionary will not change the DictionaryEntry property values.
Indeed it has some advantages over a string for iterating it.
Sorry, but (a) that doesn’t answer the question as to why this is supposedly easier than the old way of iterating, and (b) seems like a rather big disadvantage to me. I can’t change the value in a key-value pair??? For example I use dictionaries to make an index of how often words appear in a text, or where. You mean I can no longer do that???
It is not necessarily string, it can be variant, boolean, etc. or custom classes. I use it like
I was editing my message when I saw your answer! Think I found a forum bug
Imagine you have a serialization class where you save objects in a thread. You can use a Lock to avoid other threads to change your final dictionary, but it’s mutable. Once you release, you don’t have control over the program flow (less in a pure Event driven OOP language as Xojo is). Instances are attached to final a dictionary you want to save,but in between could be a context switch and other thread changes that dictionary. Voilá…
It’s like a char * vs a const char *.
Not only changing the dictionary instance, but object pointers as well. Enough to embrace the new Xojo.core.Dictionary.
Still doesn’t answer the question, so I start to suspect the answer is “It’s not, really”.
Considering that dictionaries are very fast to begin with, and the old way seems easier and much more flexible I’m not exactly impressed. Still find it hard to believe that the key-value pairs are immutable (Really???) but if so then I can imagine quite a few situations where I would have to recreate the whole dictionary to change one item. Speed advantage just went cablooe
Anyone has something about these new dictionaries that DOES impress me?
[quote=210046:@Markus Winter]For Each entry As Xojo.Core.DictionaryEntry In myDictionary is “crazy easy”, but For each key as string in Dict.keys is what difficult?
What am I missing???[/quote]
These are my favorite features. I suppose they don’t also have to be yours.
Personally, I prefer and find it easier to use entry.Key and entry.Value to reference the item rather than using Dict.Keys and Dict.Value(key).
As I also mentioned in the blog post, case-sensitivity is nice. As is the Clone method.
I’m not really following so feel free to talk to me like I’m an idiot
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).
new dictionary:
So where exactly does immutable come in for the new dictionary class and how does it affect positively or negatively what I can do?
Also regarding speed: strings are immutable which seems to be one reason they are so slow (just try s + s + s ) so would any benefit with regard to iterating over the dictionary not be wiped out (and then some) by the immutability of the DictionaryEntry class?
Come to think of it: what does it mean in general terms for a class to be immutable? Blog post for Paul?
My opinion too.
By keeping aligned with the development of the new framework you can take the benefits like dictionary, json, sockets etc. it into existing projects when you’re ready for it. But since it might be impossible to unit-test each and every procedure again, I would not considering changing a winning team, even not when the players are getting older.
