summaryrefslogtreecommitdiff
path: root/doc/todo/type_level_OS_requirements/comment_7_6fd5354f19ec624d3eaa1c5eb427ebed._comment
blob: 6a3b15c09bc7b2fbab65a34446d38a8a04e9d022 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
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!
"""]]