At this time I don’t need iOS so don’t HAVE to deal with the new framework… but someday (how soon, who knows…) it will be needed for other platforms…
So it makes me wonder what the plans are for Plugin vendors for supporting the new framework on Desktop and Web.
The two bigs one are obviously MBS and Einhugur… It would be a big job to convert their products to the new framework, and I was wondering how they plan to approach it.
Well, if Xojo Inc. wants people to more use the new classes, they may better provide more auto conversion.
e.g. if plugin takes date and user pass xojo.core.date, they could do auto conversion.
We can where it’S good for performance add functions using text or xojo.core.date. But those will be optional.
As we still keep plugins compatible to REALbasic and Real Studio, so we can’t use new data types soon for everything.
While I don’t sell plugins, I’m slowly migrating pieces that I can in my source code, it’s tough going because for the exact reason that Christian points out. Some simple functions can be replaced, but most not yet as they rely too much on the existing framework.
While also not authoring plugins, I try to write my open source projects using the new framework. Methods that would require a date, memoryblock, etc. have overloaded versions for the classic framework. But return types can’t be handled as nicely.
My controls however, are classic framework only. There’s no new framework rectcontrol yet, so the new framework is pointless.
For the time being, there are too many people still using older versions of Xojo that it would be counter productive to use the new framework in third party classes. RubberViews for instance is compatible 2013R1 and up. The new framework would not bring anything better anyway.
It can be different when only the new framework supports certain features needed to accomplish the task.
Current plugins are in C++ anyway, so it should not be an issue. I hope the announced plugins with Xojo code don’t force the new framework. That would be real annoying.