summaryrefslogtreecommitdiffstatshomepage
path: root/src/mame/drivers/zr107.cpp
diff options
context:
space:
mode:
author npwoods <npwoods@mess.org>2019-06-23 12:18:38 -0400
committer npwoods <npwoods@mess.org>2019-07-01 08:16:12 -0400
commit7d76dfbac3045dd032bf9e6cb6453f976b49a175 (patch)
tree3c82d2ceb65b569ed89dccbc66f66849a9668e73 /src/mame/drivers/zr107.cpp
parent2c298ab197f7c7a5b8093ced690ea7754a4d7728 (diff)
Changing LUA code to get mame_ui_manager by dynamic cast rather than
mame_machine_manager::instance()->ui() Dynamic casts are never one's first choice, but this is superior to grabbing a global singleton. Upon merging more worker_ui changes, it will be possible for machine().ui() to be an implementation of ui_manager distinct from mame_ui_manager, so this code is being changed to gracefully handle this scenario. Plus, global singletons like mame_machine_manager::instance are just plain ugly. Lastly, I would like someone familiar with the LUA integration to look at this, not just for correctness, but to validate my approach of keeping LUA's mame_machine_manager::ui() equivalent returning the mame_ui_manager while changing how it is implemented. Even if getting rid of mame_machine_manager::ui() is the right way to go, there is an argument to be made that we should change the LUA integration even if it breaks compatibility with existing scripts (though obviously I did not take that approach).
Diffstat (limited to 'src/mame/drivers/zr107.cpp')
0 files changed, 0 insertions, 0 deletions