New blog post: "Fifty Shades of OOP." Put in a surprising amount of research for this one!
New blog post: "Fifty Shades of OOP." Put in a surprising amount of research for this one!
@lesley @aartaka One thought I've had for a while is that programming languages and the rhetoric around it focus too much on tangible things like member variables and methods.
David Parnas was the first to point out [1] that each piece of a system -- whether you call it a function or method or object or class -- should exist to "protect" a single coherent invariant. That's the thing we need to ensure we preserve in the course of extension, not any particular member or method.
[1] David Parnas, "On the Criteria To Be Used in Decomposing Systems into Modules," 1972
@lesley Hmm, I think this is more about pragmatics. I want the syntax of a programming language to guide you to think more clearly about the problem. Should a member variable be public or private? It's irrelevant. What matters is whether an invariant is violated at some point in a program. Languages should better emphasize invariants.
Hmm, I wonder what Eiffel did? No, https://en.wikipedia.org/wiki/Eiffel_(programming_language)#Scoping also seems weird. So I'm suggesting some speculative new research direction.
@akkartik Ahh. I misunderstood what you said.
D also supports an `invariant` keyword. I wonder whether this has a performance implication (do they assert the invariant all the time?) It is kind of interesting, but I don't see many languages following Eiffel's footsteps.