Some things are passed by name because they are, by definition circular dependencies - a DPathCompileInfo points to its parent, which points to its child. Those linkages are created by way of the common lazy and call-by-name idiom that lets objects be allocated before all the args to the constructors have been evaluated.
The intent, was other than the above case, everything else would be strict - not lazy. This strictness however, can lead to coupling and circularity bugs when the DPathCompileInfo objects have members that are accessed by the schema compiler. For the RuntimeData objects, those members are intended for use by the runtime system, so the schema compiler shouldn't be using them really. But....Given that we have to compile DPath expressions in the schema compiler, the notion that these DPathCompileInfo objects are "runtime system" data structures is simply not the case. (Historically, the DPathCompileInfo objects were split out of the regular RuntimeData objects, in order to allow expressions to be compiled by the DPath compiler at "runtime" in the interactive debugger when paused at a breakpoint. In hindsight, it is not clear this was helpful long term. It does increase separation of concerns between the DPath expression language implementation and everything else about the runtime system. ) Given the heavy use of lazy evaluation in the schema compiler, and that these DPathCompileInfo objects will force all evaluations when they are serialized for the runtime system, I'm not sure we shouldn't change this behavior and just make all the parts of the DPathCompileInfo objects lazy. ________________________________ From: Sloane, Brandon <[email protected]> Sent: Thursday, June 27, 2019 10:20:40 AM To: [email protected] Subject: Justification for seperate DPathCompileInfo object The comment on DPathCompileInfo says: " What makes the circularity is that the runtime data structures (ElementRuntimeData in particular), are not lazy. Everything part of them is forced to be evaluated when those are constructed. So anything that needs even one member of an ERD is artificially dependent on *everything* in the ERD." This isn't true, is it? Everything in ElementRuntimeData is passed by-name and assigned to a lazy member field. Brandon T. Sloane Associate, Services [email protected] | tresys.com
