You probably meant [object Object] :) Since arrays have their own default toString implementation (its own can of worms that is the basis for JSFuck[0]), you'd have to go out of your way with Object.prototype.toString.call to get [object Array]
[0]: https://jsfuck.com/ relies on Array#toString for casting values to strings
I intentionally corrected it, because vanilla JS arrays used to behave like this in some contexts, but I'm not even sure about which ones still.
Since the "Array" is a reference to the prototype, I think it might be outdated due to changes in undefined behavior of runtimes when serializing array objects, or logging them.
I'm pretty sure that [object Array] used to be the result of logging an array at some point.
Object.prototype.toString
always returns the result of
Array.prototype.join
per spec, afaik, so for an empty array it's the empty string.
In general the language uses `null` if it would otherwise return an object (similar to Java; this is also why null is an object but not really in both languages), while `undefined` is used if it could otherwise return any value.
Could the language have done without both null and undefined? Definitely. But it's here and here to stay.
Though, it's not the only language with two nulls. Julia has nothing and missing, though their semantics are more well defined and with different behaviors than in JavaScript.
You can just use --first-parent to skip past commits in merged branches. Squash merges complicate stacked PRs.
But I agree on not rebasing PRs. Another benefit to avoiding force merges is that it's easier for reviewers to compare changes since their last review.
Yes, but they can't do anything about it anyway. The FSF resolution on this matter, though, essentially means that they might just as well pull Euro-Office patches into OnlyOffice. So in the end, the product will be formed by combined effort.
The codebase will diverge quickly; the Russian one is heavily obfuscated with s ton of Russian in it and obscure commit messages. A large portion of prep work by Nextcloud was cleaning and translating. OnlyOffice was also known for refusing PRs, too.
> Pursuant to Section 7 of AGPLv3, the copyright holder is expressly entitled to impose additional conditions. In the case of ONLYOFFICE, such conditions include, in particular:
>the obligation to retain the original product logo (Section 7(b));
>the denial of any rights to use the copyright holder’s trademarks (Section 7(e)).
In other words you must use our logo and you must not use our logo. Good luck enforcing that.
Terminals and things that live in terminals have relied on wcwidth() to handle this since time immemorial (which is always fun when they are out of sync, e. g. remote over ssh, but in the vast majority of the cases it just works).
This is bad advice. You should only use rem for text, e.g. font sizes and paragraph margins.
If the user is on a phone and has a larger default font size due to vision difficulties, making padding scale with the font size takes screen real estate away from the larger text the user needs.
Thanks for the tip. That does make sense, although I do think having your default CSS-defined font sizes (across your whole app, not just the main content) be a reasonable size should be the first priority.
Also, not having ridiculously oversized margins, like so many 2019-2022 websites trying to look "modern" used to use.
old.reddit.com is one example where the paddings still look good when magnification is set to 150-170% (which I have to do because of the tiny default font size). I think doing it that way but with better readability at 100% zoom, would be a decent solution.
This is true. I use increased font size on my phone, and so many websites are borderline unusable because of massive unnecessary padding. But I am also a culprit of using rem for everything. What is the alternative? Pixels?
Perfect example for you: indeed.com (desktop site). unless its been fixed recently, huge swaths of area are already empty padded space, made worse by zooming
It's not that it's unreliable, it's just lazy research. Wikipedia, like all encyclopedias, is a tertiary source, but ideally your essay should be a mix of primary and secondary sources, while Wikipedia discourages original research and prefers only secondary sources. Wikipedia itself recommends against citing it as research[0] for this reason.
All secondary sources can be just as wrong, while standards of course might differ being published doesn't prove much on its own. Also of course in many/most non theoretical fields you find plenty of conflicting sources so relying on a "consensus" based high quality encyclopaedia article seems like a more reliable approach if you are new to the field and don't really understand what you are reading.
Wikipedia and text bots are unreliable sources for the exact same reason---they are anonymous. The point of a citation is stating that "I know this because X told me". The validity of that argument entirely depends on the authority and reputational harm X would suffer for being wrong.
The changelog design has been like that since last year,[0] which predates today's slop design of small caps and monospace text (probably because they both are based on the same design trend). A year ago, vibe coded websites leaned more on sans serif and gradient text.
[0]: https://jsfuck.com/ relies on Array#toString for casting values to strings
reply