With the increasing use of namespaces, I’m getting confused. Is there any difference between Xojo.Core.Dictionary and the “classic” Dictionary? Looking in Help/Language Reference, there’s no mention of differences between the two, or why I might want to use one instead of the other. (Actually, there’s no mention at all of Xojo.Core.Dictionary).
Is there in fact any difference between these two dictionaries?
I see a lot of posts talking about using namespaces and apparently there will be many more namespaces coming, but where do I learn about the differences between the traditional ones and the new ones? Without new features, is there any reason to use namespaces at all?
So there are some differences, I’m surprised the two entries aren’t linked to each other or have some description of the differences and why I would choose one over the other. Are both going to be equally supported in the coming years? Is one more “modern” than the other, or more robust internally?
Well, the fact is that you don’t have to use the new Namespace Framework yet in anything other than iOS. While the new framework does work in desktop, console, and web apps, it’s not fully supported yet. Since there is only an iOS database that supports Text and Xojo.Core.Date it’s not all that useful in desktop yet.
The new framework is working hard to make things more consistent (everything is zero based rather than a mix of zero and one based) and the naming should be consistent. Errors that you had to check manually before will throw an exception. And in some cases the new framework doesn’t let you do some of the silly mistakes that were common in the old one. Xojo.Core.Date comes readily to mind on that one.
I’ve had a couple of posts over at http://www.bkeeneybriefs.com that talk about some of these in more detail. The comments are interesting where people have brought up the negatives of the new framework. Feel free to agree or disagree with me or any of the comments.
Differences of note- the new Dictionary uses the Auto type instead of Variant, and it has a new CompareKeys event that let’s you do custom comparisons (like make a case sensitive Dictionary if you wanted to). Both will be available for years.
Auto is quite a departure from Variants. Variants can do implicit conversions which is handy but it’s also dangerous. A lot of very subtle conversions can really screw up your application.
Auto is pretty dumb. It can hold anything, but you have to do the conversion yourself. This isn’t particularly hard, but you do you have to find out what is in the Auto variable to begin with. It’s fairly simple to use Introspection to figure what what Auto holds. Then in your conversion routine you create a native data type and do the conversion.
It’s a bit more work but I think it’s much safer to use. It’s solved a few problems in some of our classes.
[quote=155417:@Norman Palardy]It is
See Help > iOS Language Reference[/quote]
But that is not exactly the right description, since much of the non-UI/non DB stuff is usable in Desktop and Web, and that stuff is not available in the regular language reference.
If you want us to start mixing in new framework stuff with old code it would be nice to have it all available from the same language reference entry point for both.
And even better would be to cross reference the page for the similar functionality in the other framework in each doc set when appropriate. That would certainly help people learn the new framework and find the new pieces when they are added.
[quote=155424:@Karen Atkocius]@Norman Palardy It is
See Help > iOS Language Reference
But that is not exactly the right description, since much of the non-UI/non DB stuff is usable in Desktop and Web, and that stuff is not available in the regular language reference.[/quote]
I think this may be part of my confusion, maybe because I haven’t yet looked at writing iOS apps yet. I can understand iOS needing a lot of new language capabilities, but if they’re also usable in OSX and Win, then it really would be helpful to have them included in the documentation for OSX and Win.
This discussion is helping a lot, I look forward to seeing more info!
Honestly, I would wait another release to really start looking at the new framework. It’s still pretty green and there will be some changes. Not everything in the old framework is compatible with the new framework and visa versa (I’m thinking mostly dates and auto/variants).
There’s nothing in the new framework that is a must have yet. Though, the new Xojo.Core.Timer.CallLater methods are pretty friggin’ cool.
Well, no, not really, but I can’t tell you how many one-shot timers I’ve created over the years either by dragging a timer on to the window/page or implementing via code.
What can I say? It never occurred to me create what you did. I’m not worthy!
There are two versions of CallLater. The first is a simple delegate call. The second is delegate call with parameters. Both will be handy. Like I said, I usually find a reason for a one-shot timer somewhere in most projects.
[quote=155453:@Bob Keeney]What can I say? It never occurred to me create what you did. I’m not worthy!
[/quote]
LOL! I can’t hold a candle to you.
That was something that annoyed me, so I dealt with it to be less annoyed.
I could make it act the same as the new functionality, but I guess I may as well take that off my website. Going forward it would only really be useful for old versions of Xojo/RS/RB
