Assume I want to create a class called “light_LED” such that:
Class light_LED(self, LED, rgb, brightness) <== this may not be correct, but it should do for the example.
LED = which LED to light
rgb = a tuple with the R, G, B) colors defined as colors in the range of 0-255
brightness = an intensity value in the range of 0-100.
I want “brightness” to be an optional parameter with a default value of “50” (50% brightness). And yes, I know that if I want the brightness to be visually linear, I have to gamma-correct it - but that’s a different problem.
The idea being that, (for example), if I want to create a new version of easygopigo3, (or something else), I can replace it in such a way that existing code won’t break, but new implementations can use the optional parameter to set the brightness of the LEDs.
So far, my research on-line does not say anything about optional class parameters. The only thing I can find are optional function parameters.
I may have - finally! - found an answer after several days of searching.
Apparently when searching, semantics are important. Searching for “classes with optional parameters” produces a lot of nonsense. Searching for "classes with optional arguments ", produced the results I wanted.
Viz.:
If I understood the article correctly, the way to specify an “optional” argument with a default value is to assign it a value within the declaration of the class. That is:
Class light_LED(self, LED, rgb, brightness)
becomes
Class light_LED(self, LED, rgb, brightness=50)
Which is similar to the way optional parameters are defined in a function.
With this, if I skip the last argument, it is automatically replaced by the default value instead of throwing an exception.
Of course, the proof is in the pudding, as they say. . . I will have to experiment with this and see what happens.
Do any of you folks have any experience with this or advice you could offer?
You might peruse how I “created a new version” of easy_inertial_measurement_unit that uses the existing, and adds new functions. (I cheated rather than super classing.)
(It is also possible to overload an existing class (super classing) or method to be different or to enhance it before and after calling the base class existing method.)
I’m going to have to look at this when it’s NOT 2:30 in the morning. . !
I am curious about defining classes and such - as a “next step” in my education in programming. I want to start by creating simple classes that do simple things - like control an LED on the GoPiGo board.
Then, I want to “enhance” the functionality of my simple class by doing something extra - like controlling the brightness of the LED, independently of the color definition. This is where the “optional” argument comes in.
Then I want to make the effect more linear and color-correct over the entire brightness range by including gamma correction.
Then, I can try using my “improved” LED code, (for example), to overload the existing LED code in the gopigo/easygopigo libraries.
Once I’ve done that - looking at all the example code I can find, yours most gratefully included! - I want to experiment with other aspects of the robot’s behavior.
The whole goal of this isn’t necessarily to remodel the easygopigo libraries, but to peek at them, learn from them, and see what happens. Like my projects with the control panel and the remote camera robot - I learn a lot by poking and prodding stuff. Then I try doing something like that myself. . . After the smoke clears, I go back and try to learn from what I did wrong.
