masklinn
Joined 17 years ago
Joined 17 years ago
> A field in the RenderState should not have a guard unless it has its own mutex!
I don’t agree with that. The original mutex gives access to the field via its guard, nothing wrong with keeping the guard and the field and getting rid of the stricture around it (for the purpose of access). It’s not like mutex guards have a static identity relationship to their mutex.
And with the inclusion of rust in the kernel, and thus the kernel’s need to express its own abstractions and requirements (as well as the impossibility to use alloc and thus box) the limitations (ergonomic and otherwise) of “userland” smart pointers are more salient and relevant than ever.
The problem is that built-in pointers (references and box) are already special cased in the compiler to Just Work (tm), so this creates confusion when switching between those builtins and third-party pointers, or even stdlib pointers which aren’t special cased by the compiler.
So this is less about “potential implicitness on every .” and more about making places more first-class, and non-builtin smart pointers (both first and third class) being better able to express their semantics to the compiler, to lift every pointer to the ergonomic capabilities of builtins.
And the average cooking or dessert apples doesn't make for great cider. While sugar is important (and cider apples can have more than dessert or cooking apples), tanins, acidity, and phenols are also very useful to cidermaking even though they make the apples themselves rather unpalatable.
Reminder: oracle is also an acronym, and you might want to take a gander at what its subject is up to.
There is no future in which oracle is the good guy no matter the axis. Least of all the subject of AI.
That is a false dichotomy. Some enumerations have reasons to likely change in the future, others (most) either have no such thing or their changing would be so impactful to the system it needs to be signaled loudly.
That’s really no different than any other type information.
> It's always a tradeoff and you can also always fork or propose your own improved version of the concept
You are the person asserting that the concept as defined is incorrect.
Defaulting to exhaustive pattern matches is correct, it’s by far the most frequent case (which is why essentially every modern language does that); being able to prevent exhaustive matching is useful for libraries; and using a private subclass is a completely obvious way to implement that in Java.
See private extensible variants for the same capability in OCaml. Or the non_exhaustive attribute in Rust. Or the nonexhaustive attribute in Swift (or alternatively opting into library-evolution which reverses the defaults).
First time I heard of rabbit being considered to taste like chicken, they taste nothing alike.
Congratulation on reinventing HTML.
Yeah and then we could have called it xhtml5. Too bad that does not exist. Oh wait https://html.spec.whatwg.org/multipage/xhtml.html
> But the anti-XML sentiment was explicit and spiteful.
No, xhtml was just a bad idea creating tons of problems and solving none.
Seems like he’s giving a ballpark of 150 here.