fooyc
> Most Java objects set every field to be private and make all fields accessible only through accessor methods for reading and writing.
> Unfortunately, there are no language enforced conventions for defining accessors; you could give the getter for foo the name getBar, and it’ll still work fine, except for the fact that it would confuse anybody trying to access bar and not `foo'.
Scala supports pattern matching on objects implementing the `unapply` method.
Is this considered harmful? Why didn’t Java follow this route?
- Content sites implement Web Integrity API to block bots
- But they still allow Google crawlers, because Google is their source of traffic
- Google competitors are locked out
How do attesters solve this problem?
News sites will implement these DRMs, but of course they will still allow Google because it is their source of traffic. Alternative search engines and good bots will be locked out.
Stable coins can be exchanged against other crypto currencies on chain. So if you are willing to trade crypto currencies, stable coins are more practical than USD.
There are also tax implications: Depending on where you live, crypto-to-crypto profits are not taxable. You will be taxed if you sell crypto currencies for USD, but not if you sell crypto currencies for a stable coin.
But in the end, it’s just fancy words for union and intersection types, or am I missing something ?
> jo normally treats value as a literal string value, unless it begins with one of the following characters:
> value action
> @file substitute the contents of file as-is
> %file substitute the contents of file in base64-encoded form
> :file interpret the contents of file as JSON, and substitute the result
This is convenient but also very dangerous. This feature will cause the content of an arbitrary file to be embed in the JSON if any value starts with a `@`, `%`, or `:`.This will be a source of bugs or security issues for any script generating json with dynamic values.
What we need is a low that forces websites to obey the "do not track" header.
Websites can track you with localStorage, ETag headers and other cache-based methods, etc.
Some methods don’t event require any persistence on the client side, e.g. fingerprinting.
However it’s not only about cookies: What we abusively call the cookie law and cookie popups are about tracking, and there are many ways to track you without cookies, some of which are not easily blocked by browsers.
Ideally the browsers would indicate the user’s preference via a headers (e.g. the DNT header) and websites would be constrained by law to obey that.