comment

1 files changed, 45 insertions, 0 deletions

diff --git a/doc/todo/type_level_OS_requirements/comment_7_6fd5354f19ec624d3eaa1c5eb427ebed._comment b/doc/todo/type_level_OS_requirements/comment_7_6fd5354f19ec624d3eaa1c5eb427ebed._comment
new file mode 100644
index 00000000..6a3b15c0
--- /dev/null
+++ b/doc/todo/type_level_OS_requirements/comment_7_6fd5354f19ec624d3eaa1c5eb427ebed._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2016-03-17T17:30:44Z"
+ content="""
+This looks to be adding a new type parameter:
+
+`Property NoInfo DebianOnly`
+
+So does [[type_level_resource_conflict_detection|type_level_port_conflict_detection]].
+
+Would it make sense to include both targeted OS's and used resources in the
+same list of types? Otherwise, we end up with 4 type parameters, which is
+increasingly a mouthful to write:
+
+`Property NoInfo DebianOnly '[]`
+
+Since most properties use no ports or other resources, combining the
+resources lets type alises like DebianOnly be all that needs to be
+specified:
+
+`Property NoInfo DebianOnly`
+
+When there is a resource, can use `':` to add it to the list:
+
+`Property NoInfo (Port 80 ': Port 443 ': DebianOnly)`
+
+Seems reasonable. The implementation of combining such type lists may get
+complicated, because there will be different rules for target OS's vs
+resources.
+
+----
+
+Could also move the NoInfo|HasInfo into the type list. A list without
+HasInfo would be used instead of an explicit NoInfo, so:
+
+`Property (HasInfo ': DebianOnly)`
+
+Hmm, this should also allow ensureProperty to be used on Property HasInfo.
+Because the new version of ensureProperty has access to the type list of the
+outer property, it could just enforce that, when the inner property HasInfo,
+so does the outer property.
+
+Cool!
+"""]]