Type Aliases and Macros

Type Aliases
These could not only solve the harshness of the API 2.0 transition, but they can be used to enhance declare operation. The idea is that you can specify an alias, and what type or object it maps to for each target.

Example:

Alias "canvasClass" as canvas; target:desktop; architecture:all; api:1.0
Alias "canvasClass" as desktopCanvas; target:desktop; architecture:all; api:2.0
Alias "canvasClass" as iOSCanvas; target:iOS; architecture:all; api:all
Alias "canvasClass" as androidCanvas; target:android; architecture:all; api:all
Alias "canvasClass" as webCanvas; target:web; architecture:all; api:all
Alias "canvasClass" as macCanvas; target:macOS; architecture:all; api:3.0

This way a single method or property can accept a “canvasClass”, while methods can use conditional compiling to target the specifics.

Another example is with declares:

Alias "NSObject" as integer; target:macOS; architecture:all; api:all
Alias "NSView" as NSObject; target:macOS; architecture:all; api:all
Alias "NSImageView" as NSView: target:macOS; architecture:all; api:all
Alias "NSImage" as NSObject; target:macOS; architecture:all; api:all

Now I can have the external method:
declare sub "image" lib appKit.kLibrary selector "setImage:" ( imageView as NSImageView, assigns value as NSImage )

Which means in code, I can type the following, and the IDE can use typing hints to help me & others choose the correct subroutine or function.
NSImageView( imageWell.handle ).image = templateImage

Yes, I know I can do this with classes, but these add overheads and classes do not support stripping of unused methods or constants, so not only do classes have a performance penalty, but also a memory penalty.

Macros
These are used in other languages, think of macros as like an inline functions, where at compile time, the macro name is replaced with the macro contents. This avoids the overhead of having to access a function to do a calculation, so they can be used to gain in performance.

macro "radian( inAngle as double) as double" = "( inAngle * 0.01745329251994 )"; target:all; architecture:all; api:all

So the following Xojo code
labelValue.angle = radian( currentAngle )

when compiled it becomes
labelValue.angle = ( currentAngle * 0.01745329251994 )

by adding the target, architecture and API attributes to the macro, this allows different code to be inlined for specific targets, architectures and even API.

macro "durationToString( inDurationAsSeconds as double ) as string" = "<useMacOSFunction>"; target:macOS; architecture:all; api:all
macro "durationToString( inDurationAsSeconds as double ) as string" = "<codeToFormatInDuration>"; target:all; architecture:all; api:all
macro "durationToString( inDurationAsSeconds as double ) as string" = "<API2.0codeToFormatInDuration>"; target:all; architecture:all; api:2.0

Type Aliases feedback Xojo: Account Login
Macro feedback Xojo: Account Login

It is my honest belief that these feature requests would not only help smooth the transition to API 2.0 (for those who’re considering it), but also allow us to create faster and more memory efficient applications (which should be a goal on everyone’s list).

Edit: To Xojo staff, I would be more than happy to help guide or work on these features, and to proof them before you release them.

2 Likes

I would love to see more aliasing support in Xojo. Since before the first days of the planned event renaming I’ve been lobbying for aliasing to be implemented. I’d most like to see it in Events/Parameters. Xojo could change an event name to whatever they want, but the event would be linked against using an Alias. They could change a Parameter name and it wouldn’t matter as long as the Parameter order is the same (like AddHandler where the parameter names don’t matter; JavaScript, at least, does this). Allow users to change the name then just update the base event for the Alias in user projects when a change has been made in the framework allowing their project to continue using the name they had provided. If they didn’t change the name then Xojo can just update it and move on – though I’m always wary of anything that modifies my work in an automated fashion. It could get confusing if you were unfamiliar with the concept, but I don’t suspect those new to programming or Xojo would take advantage of it the way us old-timers would, and the IDE can just handle it for those users who aren’t implementing it, or just leave it alone so they aren’t overly confused when the open their project after a version change and get the compiler error.

I’d also love to see, and have requested many times over the years, having a single class for a single concept in Mobile, Web or Desktop – as you propose – so I have “Canvas” everywhere, but Xojo knows based on target which class I actually want. This would make cross-platform code so much easier. It would take us closer back to “Write once, deploy anywhere” that we had before Web. Of course it would be understood that not everything functions or exists on each target the same, but writing cross-target code would be much easier. Need generic operations? Reference the “Canvas” object. Need something specific to desktop? Cast it to a DesktopCanvas. How about some method that only exists on macOS? Cast it to macOSCanvas.

All of these proposals would add no small amount of complexity to both Xojo internally, but also user projects. That’s to be expected. But it would also result in significant functionality gains in my opinion.

4 Likes

Which is what many of want.

No argument here. There are a lot of things over the years that many of us have suggested that I’d love to see in Xojo…in a perfect world. But I understand that not everything can be done as quickly or easily as we suggest, especially given the behemoth that Xojo is. Project and business management decisions like this royally suck, and I don’t envy anyone who has to make calls like this at a significant scale because you can practically never win.

1 Like