Notes on Better Code: Relationships

Some thoughts on this presentation:

@dabrahams

• Here it says a relation is "distinct from a function in that the first entity does not uniquely determine the second.”

  Phrasing could be confusing depending on interpretation. For example, sin(x) is a function. sin(0) = 0 and sin(π) = 0. So you could say the first entity (domain) does not uniquely determine the second (range): there are (at least) two elements of the domain that produce the same range value.

  It would be more easily grasped to say that a relationship can be one-to-many, many-to-many, etc, and that a function is a special subclass of relation that is one-to-one or many-to-one. I think that’s also more useful than just saying they’re distinct because it shows that functions are a refinement of relations.

• Here "is married to" is given as an example of a relationship, but an opportunity is missed to say that this is a symmetric relationship, and not all relationships are like that. I'd give a > b as an asymmetric relationship.

• On constraints this example doesn't illustrate clearly how the dependent thing is a relationship: what are the related entities in ”for the result of division to be well-defined?” It's just not obvious on its face. I could see, for example, ”b <= a is required for a % b == 0 (a to be divisible by b) where a, b are natural numbers.” b <= a is the constraint and the dependent relationship is a is divisible by b. But that doesn't make a very compelling case for the importance of constraints. So it's unclear what you're getting at by defining the term.

• Then it goes on to say that constraints are related to implication without describing what that relationship is. Why so vague? If a is a constraint for b, then b implies a; it's that simple!

• Here there is a presentation of a notation that seems to conflict with the initial definition of a relation being a set of ordered pairs mapping entities from a domain to a range. The diagram shows three entities, not a pair. Where are the domain and range?

• Here directionality is added to the diagram and it is stated that (entities) “b and c implies a.” What other kind of entities can imply other entities? Only logical assertions, i.e. predicates, i.e. relationships. So this description only makes sense if the entities are themselves relationships. I don't know what's being aimed for, but it doesn't make any sense to me.

• The use of “severed” to describe what can happen when a thing is copied is confusing. In the example, there was a relationship between you and your wife, which was maintained, not severed, when you were cloned. The question is whether the relationship is copied along with the value of “you.”

  IMO the section fails to make the clarifying distinction between values and objects (i.e. memory regions). If moving a value severs a relationship, it's because the relationship existed or was represented between objects, not between values. If we “clone” you by copying a person value and the "is married to" relationship is recorded in a hash table that's keyed on person values, then that clone is not a different entity from the original person.

  In general, recording relationships based on objects, i.e. addresses, means working with pointers, which is doable but generally fraught, and I think better code ought to be discouraging that. Other representations of identity are generally more stable and definitely safer. For example, if you represent the identity of an entity as its index in some array, you can have a stable witnessed relationship to that entity that even survives the original object being destroyed due to a reallocation.

• In the discussion on structure there's a lot of discussion of objects and none of values, and I'm asking myself whether it would be helpful to distinguish those here. For example, a value—not just an object—that has lost its meaning is invalid, whether the value has an address or not. And note that not all values exist in memory. Also, FWIW, Valid and Value have the same latin root.

• By this point, where it is stated that ”two objects are equal if their values correspond to the same entity,“ I am fully convinced that a distinction between object and value would be clarifying. Earlier in the presentation, the entities involved in relationships were often (assumed to be) objects. Now I would say that values of objects are—or at least represent—(rather than correspond to) entities. And the objects themselves may or may not be (meaningful) entities depending on how your program is written. For example, the way I write Swift, objects are almost never meaningful entities. I would not at this point talk about the equality of objects at all, just the equality of values; that's meaningful. Equality of noncopyable objects, if we're going to bring it up, could potentially involve their addresses, which is a complication that I don't think we want to get into.

• Here there's a discussion of the axioms for equality and the misconception that those axioms define equality. IMO that will be lost on most people without an example. The simplest one is we could say x == y for all x and y in ℕ, which obeys the laws but doesn't represent what it means for two numbers to be equal.