> > > That's ugly, and more typing. The actual user-and-documentation-friendly way > would > > be > > > for it to reset "cart1" each time there's a device that adds another slot. This > > > reinforces that it's the same kind of cart slot each time. > > > > That's literally the stupidest thing I've seen all week and falls apart like a > house > > of cards the moment you start dealing with systems that have multiple slots, which > > can have devices added which themselves add multiple slots. Your proposal > essentially > > results in a parameter-ambiguity fuckfest. > > Sure, it wouldn't work in a complex parameter-ambiguous situation (then you'd need to > fall back to your syntax), but for the relatively common case of a chain of things > with identical slots on both ends it does simplify things. It makes the easy things > easier without further complicating the hard things.
in reality you're going to have 'simple' cases and complex cases..
in the end the long syntax will probably end up becoming
mame64 megadriv -slot megadriv:cart,32x:edge -slot 32x:cart,tempo:edge
of something like that
of course you could assume certain things, like if no first parameter is specified it's the base machine, and if no 2nd parameter is specified it's the only connector but even then you'd have
mame64 megadriv -slot :cart,32x:edge -slot 32x:cart,tempo:
which is still ugly..
of course you could go on compatible interfaces, so that you could also assume the 32x:edge goes in the megadriv:cart and reduce what you need to specify further..
but yeah, at some point we're going to have to be able to specify which slot we're using on BOTH sides without simply indexing them.
keeping a simplified version of it around for the most common use cases makes a lot of sense tho.
|