|
Wednesday, July 22, 2026 (#203)
|
|
I think I'm going to set a naming convention for quasiconstructors wherein if the basic idea is to construct the object using $A but that means it will also need $B to provide missing information, I will not name the function something like "FromAAndB()" (nor even something clearer but more awkward like "From_A_and_B()") but rather just referencing the starter-info, $A -- like "FromA()".
It looks like I have to expand Sunday's narrative a bit:
Starting from a URL (USpec) string:
- The
Node quasiconstructor creates a Node object, which then can create on demand:
USpec object (parses USpec string, provides PSpec string)PSpec object (parses PSpec string, provides filepath calculations)VenType object (class determined by USpec object's protocol-type)VenConn object (class determined by VenType, provisioned from USpec object's connection info)VenNode object (class determined by VenType, provisioned from USpec object's filespec)
- The
VenNode object can then create on demand:
- Each of these objects except Node and the ?Spec clades is derived from Aspect and (therefore) has a pointer to its Node-object.
- The main change here is to introduce VenConn, which wraps the connection information for the protocol specified by VenType but does not have a filespec.