The smartness required to implement and/use a language feature which could catch some given error such as this at compile/parse time would be much greater than the smartest that today's OO has/requires.
I agree that encapsulation and full object-orientation are pretty much ideological - an object encapsulating what would otherwise be a two-member structure but with twenty members is an example of OO's horror. But if you avoid Bondage and Discipline Languages (java, c#), OO doesn't have to be that.
I've gone from Ruby back to c++ with Qt, and I find c++ nearly as good IF I let myself be comfortable with public member variable since I have access to easy, flexible list/hash object via Qt.
The simple approach - small objects that interface in an ad-hoc way with each PLUS big, well defined, flexible interfaces between real, functional divisions of the code. It does require a thought-out design separate from the immediate implementation but a little thinking is good. Not all the "big, upfront design" stuff was bad.
I agree that encapsulation and full object-orientation are pretty much ideological - an object encapsulating what would otherwise be a two-member structure but with twenty members is an example of OO's horror. But if you avoid Bondage and Discipline Languages (java, c#), OO doesn't have to be that.
I've gone from Ruby back to c++ with Qt, and I find c++ nearly as good IF I let myself be comfortable with public member variable since I have access to easy, flexible list/hash object via Qt.
The simple approach - small objects that interface in an ad-hoc way with each PLUS big, well defined, flexible interfaces between real, functional divisions of the code. It does require a thought-out design separate from the immediate implementation but a little thinking is good. Not all the "big, upfront design" stuff was bad.