I know that Joe has mentioned ABIs, but I personally still think that adding a ‘float’ type will make this transition much easier. Especially for newbies to the language who start during this transition or find old declares when they do start.
In regards to structures, it gives almost all of Xojo’s competitors an advantage in having a ‘float’ type as it then makes structures non-specific to the architecture of the processor, reducing the complexity of the developers code. Reducing complexity, reduces the likelihood of bugs or crashes.
If you look through the beta forum, the most common issue developers are having is because a third party piece of code is using architecture specific structures (I’m as guilty as everyone else in this respect).
It makes sense to have an Integer type that is 32 bits in 32-bit builds and 64 bits in 64 bit builds, because that’s more or less how integer types work. Floating-point types don’t work the same way; the size of such a type isn’t really as closely tied to the processor size.
We’re dealing with an Apple-specific case. It would certainly be nice to have a CGFloat type in Xojo that does the right thing. But I infer from the alpha/beta production for 2015r3 that Xojo lacks the resources to add it along with everything else. I’d rather Joe spend his time getting all of the 64-bitness working than adding an interim CGFloat type.
The second concern, of course, is that there is no such thing as an interim addition to the framework. Were a CGFloat type added with the understanding that it was immediately deprecated along with 32-bit support, someone would end up bitching because they had to then go through and replace their use of CGFloat with Double, or they had found some odd use for the type and could it please be left in…
[quote=213755:@Charles Yeomans]
The second concern, of course, is that there is no such thing as an interim addition to the framework. Were a CGFloat type added with the understanding that it was immediately deprecated along with 32-bit support, someone would end up bitching because they had to then go through and replace their use of CGFloat with Double, or they had found some odd use for the type and could it please be left in…[/quote]
VERY true - additions to the language &/frameworks are rarely “temporary” and are approached with a great deal of caution because we end up having to live with them for a very long time
[quote=213755:@Charles Yeomans]It makes sense to have an Integer type that is 32 bits in 32-bit builds and 64 bits in 64 bit builds, because that’s more or less how integer types work. Floating-point types don’t work the same way; the size of such a type isn’t really as closely tied to the processor size.
We’re dealing with an Apple-specific case. It would certainly be nice to have a CGFloat type in Xojo that does the right thing. But I infer from the alpha/beta production for 2015r3 that Xojo lacks the resources to add it along with everything else. I’d rather Joe spend his time getting all of the 64-bitness working than adding an interim CGFloat type.
The second concern, of course, is that there is no such thing as an interim addition to the framework. Were a CGFloat type added with the understanding that it was immediately deprecated along with 32-bit support, someone would end up ■■■■■■■■ because they had to then go through and replace their use of CGFloat with Double, or they had found some odd use for the type and could it please be left in…[/quote]
This sums things up fairly well.
For example, Inline68k was only removed from the language this year after 13+ years of doing absolutely nothing except letting existing code continue to work.
If I understand right, the new CGFLoat is an automagic Integer that presents the right type to a declare depending on 32 bit or 64 bit platform. Does that mean that if I want to upgrade a MacOSLib declare for 64 bit, all I have to do is a replace Integer by CGFloat ?
CGfloat represents the single/double datatype for declares (32/64). You only need CGFloat now for your declare calls.
Before you had to declare twice single and double one for each target. Integer is handled by the compiler (32/64 bit) depending on the target. There is no chance.
Example
(before) #if target32 then
declare sub setAlphaValue lib CocoaLib selector “setAlphaValue:” (obj as integer, alpha as single) #elseif target64
declare sub setAlphaValue lib CocoaLib selector “setAlphaValue:” (obj as integer, alpha as double) #endif
(now)
declare sub setAlphaValue lib CocoaLib selector “setAlphaValue:” (obj as integer, alpha as CGFloat)
You can also now use the external methods of a module, this will not only simply code, but gives a speed boost. One routine I had is now 3x faster because it no longer has to enter methods to get at the declares (tested in IDE only, so I don’t know how much or little performance boost it creates in a built app).
Hey Sam. I don’t get this. I usually have only NSClassFromString as external method but now I can choose an “obj-c” selector.
Having that, I don’t need to type declares somewhere in method anymore ?
I guess it depends on how you like to work with declares, but it means that you can specify a declare once (as an external method) and use it where-ever you like.
I use a lot of CoreGraphics in our apps, so being able to use external methods again is a real boon.
I’ve not used it yet for ‘objective’ APIs, but I intend to, now that the Obj-C option is there.
Yes, I now. I just meant I am able to enter the obj-c selector now. This is not for NSClassFromString. I guess I already found it out how the new external declare work. That’s really cool.
