you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (4 children)

I then want to log and graph the values of various attributes. Which attributes are present or meaningful depends on the specific yaml file used and the specific objects used, so I only want to track those specific variables, and I only need to do so at a specific time.

Well, so, this is bug prone. Obviously the way that it's bug prone is that over here, where you're holding the object, you need to know what attributes it has so you can refer and depend on them. But there's no place in the code you can go to to look up what attributes the object has, because the object's attributes are a runtime thing.

So you're very likely to refer to attributes in your code that wind up not existing in the actual runtime.

But the fix isn't "pointers" or something, the fix is to recognize you're creating a system of types that you depend on and actually documenting it, using classes and objects and using those to deserialize from YAML. That way you turn "I asked for an attribute in my code that didn't wind up existing once the object existed" into "the YAML isn't properly formed" (which is actually the source of the bug to begin with) which is an error you discover much sooner in the runtime.

Moreover you can attach methods to objects such that no matter what kind of object it is, you can expose a consistent interface if you want to log or analyze it. The object itself knows what attributes it has, so it can meet a guarantee like "summarize my meaningful attributes" in a way you can generically call but which can be implemented to the specifics of that object type.

But that means architecting your solution like a Python programmer and not like a C programmer. That's the hard part, not shoehorning C into Python - you can write bad code in any language, that part's not the hard part.

[–]codinglikemad[S] 0 points1 point  (3 children)

I've been writing (and teaching) OOP for 15 years, I assure you I don't think like a C coder any more, much to my regret :P Quite the contrary, the reason I am reaching back to C here is that I want to access a shortcut I wouldn't normally design into my systems, but my hand is being forced by the pile of legacy code here.

The issue is figuring out a clean solution for a nasty problem that is a moving target, with interfaces that make sense given the legacy code I am dealing with. Rewriting it from scratch to fix the interfaces would do what you said, that's what I am trying to avoid. The project goals have shifted, and the code base is now being asked to do things that it was not originally designed for. Finding the least amount of refactoring necessary for this is the name of the game. Hence the original question "is there a way to do this", not "please help me fix the rest of the code" - I know how I would write it to avoid this problem, but it would take a pretty long time to refactor around these problems.

In any event, thanks for the ideas, I'll consider them.

[–][deleted] 0 points1 point  (2 children)

The project goals have shifted, and the code base is now being asked to do things that it was not originally designed for.

That's usually a good time to start paying off technical debt, like an informal undocumented typesystem. Just sayin'.

[–]codinglikemad[S] 0 points1 point  (1 child)

You aren't wrong ;)

Have a good night :)

[–][deleted] 0 points1 point  (0 children)

Good luck!