@LexManos sorry for ping, but I've realized I left out the inverse statements of #2 and #3. are those also true? i.e. "if getCap() is null then hasCap() must be false" and same for nonnull/true
I'm assuming yes, but I want to be clear
LexManos - Today at 7:40 PM
Undefined
i dont see of any case where it would matter
tterrag - Today at 7:40 PM
well it matters due to your answer to #1
LexManos - Today at 7:40 PM
How so?
tterrag - Today at 7:40 PM
if I skip hasCap, and assume that a nonnull return from getCap means it supports the capability, doesn't that skip a check?
if getCap() is not contractually bound to hasCap()
then I cannot rely on getCap()!=null as meaning the cap is supported
LexManos - Today at 7:41 PM
does it matter if has says it doesnt support it if it decided to give you it in the first place?
tterrag - Today at 7:42 PM
doesn't it? I'm kind of asking you that :stuck_out_tongue:
LexManos - Today at 7:42 PM
The point of has is to be performant when it comes to users who dont care about the actual cap
tterrag - Today at 7:42 PM
should hasCap be respected always?
or is it safe to ignore conflicting returns
LexManos - Today at 7:43 PM
ignore conflicting returns?
dunno
I cant think of any lofical place where get != null and has != true