RFC: Slight change to Mixin class naming scheme

[ThistleSifter]

The current naming scheme for mixin classes is as follows:

FCM* - Modified FC* classes that retain backwards compatibility with the underlying class
FCX* - Customised classes with no resrictions or requirement for backwards compatibility

Now that the mixin codebase has been expanding and it has seen use in actual scripts, it seems to me that maintaining backwards compatibility in FCM* classes is turning out to be more of a headache than anything else.

It's impacting on code organisation, with code having to be split up between related FCM* and FCX* classes for no tangible benefit that I can see (eg FCMCustomLuaWindow and FCXCustomLuaWindow or FCMCtrlStatic and FCMCtrlStatic). This splitting up is also leading to unnecessary code duplication and I can only see this becoming more of a problem as more mixins are written and more RGPLua features are added.

I think that having that backwards compatibility is to a degree an illusion, since the mixin library facilitates unlimited modification anyway.

So I'm proposing that we embrace this and remove the requirement for strict backwards compatibility, so that small things like inserting the window object as the first argument to a handler don't necessitate creating a whole new class.

[rpatters1]

Is there a need to continue with two versions FCX and FCM? Or can they be consolidated? I'm all for reducing complexity of mixin code, and I agree that the strict backwards compatibility might not be that valuable given the tradeoff.

[ThistleSifter]

They could be consolidated but I would prefer to keep them so that there is a clear distinction between mixins that modify or enhance FC* classes and mixins that extend or customise or just make something completely different.

So as the mixins stand, combining would leave us with the following classes:

FCM*:
__FCMUserWindow
FCMControl
FCMCtrlButton
FCMCtrlCheckbox
FCMCtrlDataList
FCMCtrlEdit
FCMCtrlListBox
FCMCtrlPopup
FCMCtrlSlider
FCMCtrlStatic
FCMCtrlSwitcher
FCMCtrlTree
FCMCtrlUpDown
FCMCustomLuaWindow
FCMCustomWindow
FCMNoteEntry
FCMNoteEntryCell
FCMPage
FCMString
FCMStrings
FCMTreeNode
FCMUI

FCX*:
FCXCtrlMeasurementEdit
FCXCtrlMeasurementUnitPopup
FCXCtrlPageSizePopup

There is also the possibility of removing __FCMUserWindow and FCMCustomWindow.

[rpatters1]

I'm cool with whatever you think is the best approach.

[cv-on-hub]

Just five of my scripts use mixin (basically FCXCustomLuaWindow) and backwards compatibility is moot.