Re: Structs
- Posted by petelomax Jun 22, 2019
- 4015 views
The only reason I'd go with a more complicated spec with a block definition is so structs can eventually have private/public variables and, eventually, methods. 
You invent OOP
Almost, but that's not the intent.
Oh yes it is.
Some brief thoughts about object orientation:
- It is a perfectly valid programming paradigm, sometimes.
- Other perfectly valid programming paradigms do exist.[1]
- Problems arise when shoe-horning (parts of) a solution into an inappropriate programming paradigm.[1]
- The best solution is probably quite often a mixture of different programming paradigms.[2]
- Fundamental radicalism is almost as bad in programming as it is in politics and religion.[2]
- Trivial components in no way guarantee that the larger system is automatically bug free.[3]
- Thousands of trivial components do not make complicated problems any easier to find.[3]
- Making something harder to debug does not help anyone, ever.
- Forcing someone to use something they hate or do not understand does not usually help much either.
- Allowing someone else to do things in their own (peculiar) way is just plain old fashioned common decency.
Footnotes: Repeat firmly and calmly [1]yes they do [2]yes it is [3]no they do not. Resist temptation to shout.
Anyway, enough of that. If we can sneak in a few little extras in a way everyone is comfortable with, we should.
Whether you love or hate oop, I think we can all agree we all want something like this:
Suppose you have say struct rectangle, struct square, struct circle, and struct triangle.
Do you want to be able to pass any of those to a generic routine that accepts a struct shape?
If so, how do we define struct shape, and something else, say struct address, that naturally cannot be(/type checks if) passed into a struct shape parameter?
How do we best express that sort of relationship in a simple, natural and intuitive way?
PS Let's just all agree not to even consider multiple inheritance!
