You are damn fast
Yes, that would have been better, but I still find the multiple layers of indirection confusing, and am reminded why, when I first tried out C++ and was delighted by the idea of operator overloading, I gave up on it very rapidly when I first tried to actually use it.
I loathe the idea of writing any of that. Apart from not understanding
auto, I only want to write:
KeyAddr k = 12;
…which I can do with a typedef, and now I’m not sure if it can be done with your version. It is so complex, for something so simple, that it makes me want to give up the whole project, and just fork Kaleidoscope now and write my own separate version for personal use and stop trying to contribute to the main codeline.
Sure, that might be even more descriptive. The indirection is there for
- portability (KALEIDOSCOPE_KEY_ADDR_STORAGE_TYPE being defined through the build system) and
- encapsulation (a class informs about the types it uses, i.e. StorageType (or KeyAddrInternalType).
But as mentioned before, no-one should ever be forced to look at the implementation.
Check out e.g. the documentation of Eigen. I never ever looked at the implementation and I am using it for more than ten years now. And please, don’t look at Eigen’s implementation, at least not without sunglasses
Thanks. I read something similar last night, but there weren’t enough examples for me to understand it. Maybe I’ll get it this time, but I’d just rather not have to learn it at all.
There is a line in my above code example that reads
at the bottom in the main function.
How about developers who want to contribute to the core, or port Kaleidoscope to other hardware (e.g. Planck)? This makes it much harder for them.
That is a misuse of encapsulation. With proper encapsulation you have only an opaque container and ought not ever care about what is inside.
If an opaque box (i.e. object) has to have a mechanism to tell you the details of its implementation then things have already gone off the rails.
If outside code has to care about the internal implementation details of an object, then either the object is done wrong or an object is the wrong solution.
I know I cannot convince you. And developers should of course understand the code. And, writing this on a Planck, I am really interested in a port. So, if you can do it if we stick with a typedef, I will certainly opt for the typedef
But seriously. A port to another keyboard would not require touching the code of
KeyAddr. That’s an important aspect of portability. The only thing that needs to be done, concerning the
KeyAddr class, is to define other values for the macros
KALEIDOSCOPE_MATRIX_ACCESS_TYPE KALEIDOSCOPE_KEY_ADDR_STORAGE_TYPE KALEIDOSCOPE_KEYBOARD_ROW_SIZE
in a hardware/platform specific type definition header.
Interesting. Just ask google for ‘c++ vector iterator’ and click on an arbitrary hit, e.g.
If it was true what you say then the whole STL has ‘gone off the rails’. Public typedefs in classes are part of an interface, not the implementation. Actually, everything that is defined in the public section of a class is part of its interface and not ‘inside’.
That makes your class very well implemented indeed, but it may simply be the best implementation of a wrong approach.
Ok, guys. I won’t continue to insist in any type of implementation. My class sketch of
KeyAddr was just a suggestion.
Possible. Eventually, programming discussions always end at philosophy, same as parties end in the kitchen (not sure if this saying exists in english).
And I think it has.
I’ve worked with C++ when templates were still relatively new, and I’ve worked with the Boost STL. And I prefer not to work with C++ any more. I don’t think these things are completely unrelated.
I continuously work with C++ for almost 20 years now. It’s not that bad. Actually, It’s my favorite language. No other language allows to generate such lengthy discussions
Have you not heard of Perl 6?
We can. The hard part with a Planck port is the Teensy, because that needs a different HID library, as far as I remember. There has been same work on that front before, and I plan to revisit that soon for various reasons. Once we make it easier to use different HID libraries, and dispatch events between them, a whole lot of things get easier. Including porting to Teensy-based platforms. Once that code is in, the Planck port should be doable in an afternoon.
Key addressing is a non-issue when porting to keyboards that use the exact same MCU under the hood (the Teensy in the Planck has the same Atmega32u4 processor in it as the Model01, the Shortcut, and Raise). It would become an issue only when porting to a keyboard with more than 255 positions in its matrix. I don’t see that happening anytime soon. And even then, putting the typedef in the hardware plugin would solve most of the portability problems.
I must honestly confess that I switched from Perl to Python before Perl 6 came along. But I seem to have missed something.
Nice. Thank’s for the info. I am looking forward to the Teensy port. My ErgoDox might like it too.
I was referring primarily to the 15 years it took from the start of the design discussions to the “1.0” release.