I have spent months at a time getting 7-8 (amid years of 5-6). I never notice any difference and am actually surprised my body can do 7-8 to no purpose.
I don't understand what you are objecting to. What would the causal hypothesis be, "this syndrome causes no diseases"? It's just an ordinary claim that if the syndrome is harmful, it's not as immediately apparent as something like sniffing glue. It's saying "this is harmless" can't be ruled out.
> There are no known health problems caused by this syndrome
This is a causal hypothesis framed as a statement. The rhetorics indicate an authoritative statement of fact regarding what the syndrome does cause, which is fundamentally an impossible conclusion to draw empirically.
The only hedge in the sentence is "known", which is tautological.
Of course, it's impossible to eliminate all variables, making authoritative claims about lack of causal relation impossible. But at least they could make the effort to frame this uncertainty in reasonable terms.
> What would the causal hypothesis be, "this syndrome causes no diseases"?
EDIT: but c'mon, just read the article. It's extremely bold in its claims with no evidence. "If you have short sleeper syndrome, you don’t need as much sleep as others. You can expect this to continue throughout your life." "Natural short sleepers don’t experience the same health risks as people who don’t get enough sleep." etc.
I don't see any semantic difference between this and "this syndrome causes no known diseases". (or "SSS doesn’t pose any known health risks." as the actual quotation states.)
You underestimate antisemites if you think they won't be aware of whether the people the government is punishing at Columbia are the antisemites or the Jews. Rather, there are two kinds of antisemites and the racist kind is fine with cancelling the woke kind.
The last three paragraphs are like, "Forget the headline and the rest of the article, this tech actually sucks and we plan to stop using it." Confusing.
Could you excerpt which part of the paper constitutes said dunk? I searched "Marx" and "labor" unsuccessfully. Also it would be helpful to use your knowledge of Marx to explain how price and value are not interchangeable in this case.
If it's this length but about the history of S3, I can easily stay engaged for each new story. When it's a bunch of hypothetical syntaxes that will get thrown away, I'm only staying if I entered the article with the purpose of "I want to understand React Server Components".
I thought the example comment should strive to be shorter than this:
// Currently, key can be spread in as a prop. This causes a potential
// issue if key is also explicitly declared (ie. <div {...props} key="Hi" />
// or <div key="Hi" {...props} /> ). We want to deprecate key spread,
// but as an intermediary step, we will use jsxDEV for everything except
// <div {...props} key="Hi" />, because we aren't currently able to tell if
// key is explicitly declared to be undefined or not.
if (maybeKey !== undefined) {
key = '' + maybeKey
}
But I found while trying to shorten it that a) it couldn't be that much shorter and b) it actually contained all the info I needed to understand it, which is the goal. Rewriting to my preference would just be my way of understanding it.
Anyway, here's what I would write to explain the why:
// If the JSX key was passed explicitly, use it. This may overwrite a `key`
// from spread props, e.g. <div {...props} key="Hi" />. We can't distinguish
// that from <div key="Hi" {...props} />, so until key spreading is deprecated,
// we ask people to use `jsxDEV` instead of `jsx` for all cases except
// <div {...props} key="Hi" />.
This explains:
* Why the line of code is here: to ensure explicitly passed `key` wins. The 'what' is "coerce maybeKey to a string", which doesn't clearly address the issue of key spread
* State the issue with _this line of code_, which is that it overwrites user-specified keys in props, not just that it's "a potential issue".
* State which example is good and which is bad and requires jsxDEV -- actionable advice.
I also think the `key` param should be documented to say
This will overwrite `key` in spread props. Use `jsxDEV` if you want to do <div key="Hi" {...props} />.
Otherwise, you've only explained the issue to internal developers, while framework users get no warning until they're so far into debugging they've narrowed it down to this function.
I built up a lot of expectation that this article was going to be self-referential and link to a hidden well of info. At the very least it ought to link to one example of such an article so we know you aren't describing something theoretical.
I don't feel bad for being unable to conceive of the "navigation bar" containing a link to the page's real content. That's the most effective camouflage possible.
reply