Go Back

Is MDU -e Idempotent?

Idempotence is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application. The concept of idempotence arises in a number of places in abstract algebra (in particular, in the theory of projectors and closure operators) and functional programming (in which it is connected to the property of referential transparency).

In this case if given the same input x into MDU -e (https://www.synergex.com/docs/index.htm#xfnl/xfnlChap2Methoddefinitionutility.htm) am I guaranteed to get the same output y? Specifically I am concerned about the order in which the methods are ordered. We are willing to take a performance hit in order to guarantee consistent ordering/idempotence.

It is critical that this property be preserved as this will allow us to implement a Tattler process to observe when code changes affect the SMC. Leveraging modern DevOps procedures we have thrown this process into CI and then attached a Tattler to alert us when a developer messed up. This is heavily reliant on our ability to quickly perform a diff against the committed version.

1 Answer
0   | Posted by Ace Olszowka to xfServerPlus on 5/20/2019 10:19 PM
Ace Olszowka
The short answer to this is: No.

The long answer is: Kinda.

The exported SMC has several pieces of meta-data that for our intents and purposes are useless; specifically:
  • The date for which the smc was exported is stamped in as a comment
    • This is what fails the test
  • The path of repository and SMC are exported as part of the file which are useless when ran in different environments.
    • To be technically correct this is still idempotent as if your x is the same path always this is the same. However in the real world no two developers are setup identically and this usually results in a bunch of "noise" in a version control system.

Because the exported SMC is simply XML it is left as an exercise to the reader to create a custom equality comparer. This is trivial if you do not care to commit the result back to Version Control; it becomes much more difficult (non-trivial) if you are attempting to create a usable patch for developers to apply.

The question though still stands; are we guaranteed to have the ordering consistent? Failure to do so will drastically increase the complexity of this comparer.

We are happy to create an Idea that asks that this be documented to be idempotent such that future redesigns take this into account.

5/20/2019 10:26 PM   0  
Please log in to comment or answer this question.