Ho ho, except for where it puts the photos. Those go into a subfolder of the system photos folder, and there's no configuration (yet you can configure the "shared photos" location)
And then, should you try to set up OneDrive (despite Microsoft's shenanigans, it does simplify taking care of non-tech-savvy relatives), it will refuse to sync the photos folder because 'it contains another cloud storage' and you'll genuinely wonder how or why anyone uses computers anymore
Thankfully, since then, Chrome and all other major browsers now ask the user for permission before letting websites send requests to localhost or any local IP addresses. Obviously some users may click through that, but it prevents the behavior from being invisible to the user at least, and gives them a way to say no.
PS: I still recommend never installing Meta apps on your phone.
PPS: There are legitimate uses of this functionality, so as a web dev I'm happy the functionality wasn't silently blocked. This gives an opportunity to explain to the user why the permission is needed if the use is legitimate. Would be nice if it could be further scoped though.
> But this type of article is bad science writing. It shows why one hypothesis as to why a warmer color temperature would result in one other physiological change isn't supported
I don't know if I'd even give them that credit (emphasis mine):
> Halving the luminance, at best (around 20 lux baseline) might get you from 50% to 25% melatonin suppression.
I think you are both unknowingly talking past each other: my understanding is that Smalltalk-style "object-oriented programming" ("everything is a message!") is quite distinct from C++/C#/Java/Rust "object-oriented programming" ("my structs have methods!")
They are both OOP, just as a "football" can be either spherical or oblong.
Functional programming is not "encapsulating data in 'objects'". Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming (which emphasizes immutability, pure functions, composition, etc.)
> They are both OOP, just as a "football" can be either spherical or oblong.
They are both OOP like a football can be something that you use in a sport and something that flies you to the moon. Except it is not clear what flies you to the moon goes by "football".
> Such a model would naturally feature methods like "void Die.roll()", "void list.Add(element)" which are definitely not functional programming
Exactly, functional programming. `Die` and `list` encapsulate data and use higher order functions to operate on it, which is what defines functional programming.
> which emphasizes [...] pure functions
Functions without encapsulation is imperative programming. If you introduce encapsulation then, yes, you have functional programming, just like your examples above.
Immutability is a disjoined property that can optionally apply to all of these programming paradigms. OOP, functional, and imperative programs can all be immutable, or not.
Composition and encapsulation go hand in hand, so that one is also functional programming, yes. And certainly composition is core to languages like C++/Java/Rust/etc. Naturally, them being functional languages.
To reiterate:
- Imperative programming: Data and functions are separate.
- Functional programming: Data is grouped with functions.
- Object-oriented programming: Data is grouped with message
responders.
You're welcome to insist that your definitions are canonical ("the objective in football is to kick the ball into the net"), but they are at odds with the rest of the thread
Just as you are welcome to come up with other definitions. Although last time you tried they ended up being quite inconsistent, so one does need to be careful if you want them to be useful.
These definitions are not at odds with the discussion at hand at all. It was clearly stated that Swift has better OO support. Which is obviously true because it tries to be compatible with Objective-C, and therefore needs to have some level of OO support. That is something that Rust has no interest in doing, and rightfully so.
Your redefinition violates the claim, and therefore we can logically determine that it is not what was being used in the rest of the thread. That is, aside from the confused Rust guy that set this tangent in motion, but the remainder of this thread was merely clarifying to him what was originally intended. "He has a different definition for OOP" doesn't really help his understanding. That is what this thread branch has always been about, so it is not clear where you are trying to go with that.
Yeah, I recently stumbled on some other devblogs post very similar in quality to the one that was linked here, which was basically wholesale plagiarism of a stackoverflow answer. I found it while searching for an error message.
Nor horses...
reply