We currently have 18 choices which use this pattern.
The way choices work is fairly complicated to handle the use case of modeling fluid equip functions in tank, pump, valve, and pipe. This specific use case is examined in the separate sub-proposal 936.
I propose to simplify choice as a simple exclusive set of marker tags defined via subtyping.
// current design
def: ^point
pointFunction: ^pointFunctionType
---
def: ^pointFunction
is: ^choice
of: ^pointFunctionType
---
def: ^pointFunctionType
is: ^marker
---
def: ^sensor
is: ^pointFunctionType
---
def: ^cmd
is: ^pointFunctionType
---
def: ^sp
is: ^pointFunctionType
Proposed new design:
// proposed new design
def: ^pointFunction
is: ^choice
tagOn: ^point
---
def: ^sensor
is: ^pointFunction
---
def: ^cmd
is: ^pointFunction
---
def: ^sp
is: ^pointFunction
Key aspects of the new design:
Choice subtypes from maker now instead of symbol
This collapses all the pointFunction vs pointFunctionType twin defs into a single def
Choices are registered using tagOn just like any other tag and no longer added a tag on the entity def itself
Choice subtype hierarchies must be flat. A subtype of choice must have no subtypes of its own
Gareth David JohnsonThu 12 Aug 2021
Great idea. This is far easier for people to understand and consume.
Steve EynonSat 18 Sep 2021
This is a lot simpler and makes a lot of sense, great work!
I'm not sure why anyone would want to subclass a choice subtype (!?) so not much loss there.
Mike MelilloWed 29 Sep 2021
Echoing the above, this looks great, simpler and more natural thought process.
I've caught myself multiple times having to review the docs when trying to implement a choice with the current implementation.
Jason BriggsMon 6 Dec 2021
I know I'm late to the party, but I totally agree
Brian FrankWed 23 Mar 2022
I have pushed these design changes - see changeset
Brian Frank Mon 19 Jul 2021
This is a sub-proposal of the broader 940 Haystack 4 proposal.
The common use for choices is to model an exclusive set of markers. This pattern is used extensively in the ontology:
We currently have 18 choices which use this pattern.
The way choices work is fairly complicated to handle the use case of modeling fluid equip functions in tank, pump, valve, and pipe. This specific use case is examined in the separate sub-proposal 936.
I propose to simplify choice as a simple exclusive set of marker tags defined via subtyping.
Proposed new design:
Key aspects of the new design:
tagOn
just like any other tag and no longer added a tag on the entity def itselfGareth David Johnson Thu 12 Aug 2021
Great idea. This is far easier for people to understand and consume.
Steve Eynon Sat 18 Sep 2021
This is a lot simpler and makes a lot of sense, great work!
I'm not sure why anyone would want to subclass a
choice
subtype (!?) so not much loss there.Mike Melillo Wed 29 Sep 2021
Echoing the above, this looks great, simpler and more natural thought process.
I've caught myself multiple times having to review the docs when trying to implement a choice with the current implementation.
Jason Briggs Mon 6 Dec 2021
I know I'm late to the party, but I totally agree
Brian Frank Wed 23 Mar 2022
I have pushed these design changes - see changeset