https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-05-30T09:40:51ZOpen Source Mobile CommunicationsOsmoGSMTester - Bug #2307: osmo-gsm-tester: Proper object-oriented structure to handle different objectshttps://osmocom.org/issues/2307?journal_id=41432017-05-30T09:40:51Zpespin
<ul><li><strong>Assignee</strong> set to <i>55360</i></li></ul> OsmoGSMTester - Bug #2307: osmo-gsm-tester: Proper object-oriented structure to handle different objectshttps://osmocom.org/issues/2307?journal_id=41482017-05-30T12:12:18Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>I agree to remove code duplication, but I would like to emphasize that the aim is not polymorphism per se. I have for a long time used class inheritance quite heavily, but have realized that it often creates more confusion and problems than it solves. So if having a base class indeed makes it easier to un-duplicate the code, then let's use that. But in Python we have near total freedom, and we should also consider other methods of sharing code, choosing the simpler way as we go.</p>
<p>Also let me note here that we are most probably not going to test the OsmoNITB for a long time, so time invested in polishing the code to have both NITB and MSC+BSC in clean non-duplicating code is most probably wasted. See also <a class="issue tracker-2 status-6 priority-1 priority-lowest closed" title="Feature: add abstract API to picking which "core" network setup (NITB or MSC+BSC) to use by scenario (Rejected)" href="https://osmocom.org/issues/2270">#2270</a></p>
<p>For different BTSes, this ticket remains fully valid. At first, while the implementations were in high flux, I decided to write the code by duplicating. A reasonable amount of code duplication (if it helps to show what is really happening) is also acceptable, but as the code stabilizes we may now identify common parts and unify.</p> OsmoGSMTester - Bug #2307: osmo-gsm-tester: Proper object-oriented structure to handle different objectshttps://osmocom.org/issues/2307?journal_id=41492017-05-30T12:12:30Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-1 priority-lowest closed" href="/issues/2270">Feature #2270</a>: add abstract API to picking which "core" network setup (NITB or MSC+BSC) to use by scenario</i> added</li></ul> OsmoGSMTester - Bug #2307: osmo-gsm-tester: Proper object-oriented structure to handle different objectshttps://osmocom.org/issues/2307?journal_id=127842018-11-29T12:18:22Zpespin
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>This has been implemented for BTS classes a long time ago. For NITB we don't care anymore since it's mostly deprecated nowadays, and no further development will be done there.</p>