Alternative: Module -- Re: fake class in OE
- Posted by katsmeow Feb 25, 2021
- 1148 views
Responding to mitgedanken ...
The problem with export function get_horns() is the same problem with most computer languages, and some people: it's fixed, the system is fixed, you cannot add a get_ anything else while the program is running, or any sort of parameter which you may discover next week. With this way of doing things, the programmer must know in advance all the possible things that could be setted or getted, and write code for it, which if you think about all the things in the world you know parameters about, is going to make for a terribly bloated application.
... Kat
That's correct. There may be a way to avoid that problem, however,if the base class has 3 routines: add_property(), set_property(), and get_property(), along with a dictionary or db to store the name/value pairs (and perhaps a function to be called to override the one declared in the base class?).
I had imagined add_ would be part of set_, but yes, having them be separate makes it easier to apply different rules and error checking to each. It's also more possible (as in, without breaking anything) for a new feature that cannot be properly described yet. You must be thinking of the platypus problem?
There's other database management tasks unrelated to the class which would need tending to. I had imagined a OE layer to deal with the class work, and interface to your choice of database behind, because once the db is working, it becomes just a "black box" you no longer think about. Simple small stuff may be dealing with only (only?) a game (class = "habitat") and be stored in nested sequences, but for real dealing with taxonomy of animals may need a semi-pro database first thing (and occasionally forking the db into subclasses). Etc. I suggest working on the class stuff first, and use sequences to store the data (even then.. split(), store(), load(), etc).
Kat
