DevLog Team DevLog Phil7 - Update 2024-03-25 - Breaking Changes?

[Phil7]

Hey Everyone!

I am going to try out some changes that could be called "breaking changes" as they could make changes to you your code base necessary or that need a special config setting to make it work like before. That said, I am announcing this before I put it on GitHub and I also plan have those changes in a "experimental" branch first for everyone to see and check out for themselves.

Those are my current plans for changes:

Changed behaviour	Potential issues with it	Optional setting to get original behaviour
Make return type "Void" optional for functions/methods in "Strict" mode.	No real issue. Only if you switch from non strict to "Strict" mode, methods without type change from Int to Void.	Hard coded into Trans -> No setting available
Change return type of App callback methods to "Void", i.e. OnCreate(), OnRender(), ...	You need to change the return type of your overwriting methods to make them fire again.	Set #USE_COMPATIBILITY_MODE=True on top of imports in your main source file.
Add global draw functions like with Canvas and DrawList	Those global functions could be shadowed if you are using the same names.	Set #MOJO2_DEFAULTCANVAS_ENABLED=False on top of imports in your main source file.

You might ask why I'd like to apply those changes. The main reason is to make Cerberus X as easy as possible to start with especially for beginners. With the current version of mojo2 I even find myself using old mojo whenever I try things that are not graphics related just to avoid the additional boilerplate code. With the beforementioned changes simple examples boil down to something like this:

Strict

Import mojo2

Function Main:Int()
    New MyApp()
    Return 0
End

Class MyApp Extends App
    Method OnRender()
        Clear()
        DrawText("Hello World!", DeviceWidth()*0.5, DeviceHeight()*0.5, 0.5)
    End
End

I recently started using this on a regular basis to make sure it has no unwanted side effects. If you have any objections please call them out.
The reason I am coming up with those changes now is because if I need to change something about how Cerberus operates it is best to do it now before I release the new docs and rewrite the examples with it, and of course before I invest heavily into getting new users on our site.

Let me know what you think!

All the best,

Phil

 

[dawlane]

You have to be careful with using void. There is a reason as to why void parameters were disallowed in functions. Kind of buggered up wxMonkey that relied on them.

 

[MikeHart]

Functionality behind OnClose is actively using the return value on Desktop.

 

[Phil7]

You have to be careful with using void. There is a reason as to why void parameters were disallowed in functions. Kind of buggered up wxMonkey that relied on them.

I am only referring to return values nothing else. Could you explain what could be an issue there?

 

[Phil7]

Functionality behind OnClose is actively using the return value on Desktop.

Could you point me to the file/line you found this?

 

[dawlane]

I am only referring to return values nothing else. Could you explain what could be an issue there?

Read up on the void operator and return for javascript and java before you decided to make any changes.
Also make sure that it doesn't cause trouble with the reflection filter.

 

[Phil7]

@dawlane I will read your suggestions. Do you know of any issues that could come up in a practical sense? This would help me to direct my focus on the right things.
Are you referring to the change of trans (No return type -> void type) or the change to the App class?

 

[MikeHart]

Sorry @Phil7 i have mixed something up with a different tool.

 

[mag]

I support the idea of simplifying the language. However, it seems inconsistent with the current CerberusX (CX) language, where any identifier created without specifying a type defaults to an integer:

local A = 10 // A by default becomes int

Nevertheless, I agree that allowing methods and functions without specified types to default to void makes sense. Although it deviates slightly from the original language, it's a feasible adjustment. Methods and functions do seem cleaner with void as the default return type.

Regarding changing the return type of App callbacks OnCreate() and OnRender() to void, I also agree. In my experience, there's rarely a need for an integer return type in these methods. While considering OnUpdate(), I'm uncertain if a return value would be useful. However, if you decide to omit it, I'm okay with that. I can resort to using globals if necessary. Overall, having these methods return void does contribute to a cleaner codebase.

On the topic of creating #USE_COMPATIBILITY_MODE=True, I don't think it's a good idea. It seems messy. Instead, providing a help note about these changes for those migrating to the new version would suffice.

However, for #MOJO2_DEFAULTCANVAS_ENABLED=False, if you desided to add a global draw function, I support adding this configuration. It provides flexibility and aligns with the purpose of a config.

Additionally, I do appreciate the concept of a default canvas, which can significantly ease the learning curve for newcomers.

 

[Wingnut]

On the topic of creating #USE_COMPATIBILITY_MODE=True, I don't think it's a good idea. It seems messy. Instead, providing a help note about these changes for those migrating to the new version would suffice.

I second that.

 

[Phil7]

@mag @Wingnut Thanks for your input! We could go that route and a help note for the migration is needed for sure. I could also add that note as a warning Print in case the OnRender() method is not overwritten. The other callback methods are kind of optional so it doesn't make sense there.
If there still comes up the need for a fallback to the old App behaviour I could alternatively provide the old App class renamed to something like DeprecatedApp or CompatApp. This could serve as an isolated intermediate solution and could be spotted easily in code when it finally gets removed.