Result = Process(Data)All data is the result of a process.
-- PeterLynch
Process = Data.Do is true when Data is source code and s-expressions, but not for all things.Result = Process(Data) is a syntax which encourages semantic clarity in any operation we perform, because it is the way we do many things in the real world. It gives a context in which to view the problem which encourages naming the process and considering what Data need to be given to it in the form of arguments. Anything reduced to that form is implementable. For example, it encourages me to write this to express the contrary view -
Data = Eval(Process)
This appears to be "behaviorism", which is a candidate for DefinitionsForOo (at least it used to be). This is to be contrasted with declarative interfaces. See DataCentricVersusBehaviorCentricThinking. I feel that data-centric interfaces are often better because they can be shared with more languages and attributes have more "maths" than behavior at this stage in history. --top
A data-centric interface is eventually used in the above form. Assuming that you are taking the view that the above excludes database languages, it does not. But it could be said that any interaction between process and database can be expressed in the above form. I believe you are doing that in TopsQueryLanguage. --PeterLynch
I agree that "Result = Process(Data)" is the clearest syntax for encapsulation. Example:
mysum = Sum(3,4,5)To illustrate the opposite, consider the equivalent in common excess OO style with factory and delegate!
ComputatorFactory factory = new ComputatorFactory(); Computator computator = factory.GetComputator(); computator.AddParameter(3); computator.AddParameter(4); computator.AddParameter(5); computator.SetFunction(Computator.ADD); computator.Execute(); mysum = computator.GetResult();Eeek!
-- DaveEaton
Related to "bloated" expressions: ExpressionApiComplaints
See also: DataAndCodeAreTheSameThing