On Esperanto / Pri Esperanto

Pri bjalioj

Se bjalioj venas el Bjalistoko, kaj Zamenhof estis Bjalistokano, ĉu Zamenhof iam ajn manĝis bjaliojn?

On computer science

On APIs

On state

Prefer stateless APIs whenever possible. Relegate necessary state modification to a small number of functions that only modify state. This simplifies use and reduces bugs.

On memory allocation

For opaque structures, prefer allocation by the callee.

For transparent structures, prefer allocation by the caller.

On data

On labelled tuples

On dynamicity and heterogenity
On run-time introspection
On schema (in)compatibility

I recently encountered a JSON framework which, by default, rejected JSON objects which contained “extra” fields compared to some schema.

Why would anyone ever want to do this? By default, nonetheless.

The supporter would likely claim that an unexpectedly present field indicates a schema change. One should not process a datum which one does not fully understand.

Yet, the presence of an unexpected field in a labelled tuple is neither a necessary, nor sufficient, symptom of a mismatched schema. It is not necessary, for the meaning of a field may have changed without a new field being added (regardless of whether such a change is sound practice). It is not sufficient, for the additional field need not change the meaning of any existing field; indeed, this latter case is the foundation of object-oriented polymorphism.

While indeed, the presence of such a field may be a strong correlate with a change in schema, correlation does not inform logical rules. We are, after all, computer scientists, not statisticians.

Therefore, the presence of an unexpected field in a labelled tuple should always be ignored.

On the contrary, the absence of an expected field should never be ignored: this is a sufficient indicator of a logic error on the part of either the producer or consumer.

Dually, the presence of an unknown tag in field of enumerated type is a sufficient (albeit not necessary) indicator of a schema change. What can this unknown tag mean? If any computation depends on the field’s value, the unknown tag cannot simply be ignored, or substituted for some default value.

Likewise dually, the absence of a known tag in a field of enumerated type can, and should, safely be ignored. It is indistinguishable from the case that the tag is simply never used.