Yeah, all cars produced between Feb & Oct had a faulty part. That's over half the year so more than half the cars.
It's irrelevant going forward. It doesn't mean that percentage of cars will be recalled. Nor does it have anything to do with how many cars they will make.
An increase of 300% over what? How many X & S they are making? Well, those production lines are not going away. This is all additive. And it's a car designed to be far simpler and easier to mass produce, and for this year at least will have no factory fitted options. Just one model. So that seems perfectly doable.
No one is saying nulls are always bad. What's being said is that nulls should never mean "indeterminate state". They should always mean something.
You say it's a missing relationship. But that's one example of a meaning for null. One that makes sense to someone who's doing database work all the time, or who thinks of object graphs as databases. It's certainly not the only use people make of nulls.
For a given function, null return either has a meaning or it does not. "Something went wrong" is not a good enough reason to return null, unless your function documentation says what might go wrong and what that null therefore means.
If null has no meaning then make it a notnull return, or in Swift a non-optional.
I used to work with a programmer that used to make all returns optional "just in case". I wanted to punch him.
I'm not going to argue your interpretation of individual phrases. This patent is for a phone placed where a touchscreen would be in a laptop, so that it can be used for both touch and display.
The Atrix Lapdock had the phone vertically behind the laptop screen where it could not be used for touch or a secondary display.
I didn't say every claim contained something new. But the patent does. 2 examples:
"4. The electronic accessory device as recited in claim 3, wherein the operational component comprises an accessory display configured to present visual content. "
"5. The electronic accessory device as recited in claim 4, wherein the electronic host device comprises an input device configured to detect a touch event. "
Neither of these are present in the Atrix Lapdock, as it places the phone behind the laptop screen. The Apple patent has the phone placed where a touchscreen would be in a laptop, and that's what make these two claims possible.
This is a fundamental misunderstanding of patents. All patents have prior art. Indeed they list the prior art in the patent. Patents take something that is already patented, and add some new things. Patents are never for something that is entirely new, the always build on what came before.
The automated car doesn't have to be better than humans for every single case. It just has to statistically have less collisions and less fatalities than when the cars are people are driving.
Because whining about the $99 in every iOS development thread for the last 10 years *is* time-wasting. It's a trivial sum. If you think it's significant, then you are not a developer, you're a time waster.
As a matter of fact I was developing iOS apps on a 2012 Mac until last year. Then I had to work on the Android version on one, and the Mac wasn't good enough. It would compile, but it took 10 minutes to do so. Obviously that's not practical. It's Android that required me to upgrade my Mac, not iOS development.
The reason for the law is because stupid fucks like you don't realise it's not acceptable to use a hand-held phone, because you are more likely to kill people.
It's perfectly simple. Holding a mobile phone whilst driving reduces your control of the vehicle, and makes you more dangerous to other road users. People are killed because of assholes that do that every day. Therefore there are laws against it. You demented libertarian fucknut.
Slashdot Mirror
No. That's got the danger that someone might try to talk to you.
Yeah, all cars produced between Feb & Oct had a faulty part. That's over half the year so more than half the cars.
It's irrelevant going forward. It doesn't mean that percentage of cars will be recalled. Nor does it have anything to do with how many cars they will make.
An increase of 300% over what? How many X & S they are making? Well, those production lines are not going away. This is all additive. And it's a car designed to be far simpler and easier to mass produce, and for this year at least will have no factory fitted options. Just one model. So that seems perfectly doable.
Create your own smartphone?
No one is saying nulls are always bad. What's being said is that nulls should never mean "indeterminate state". They should always mean something.
You say it's a missing relationship. But that's one example of a meaning for null. One that makes sense to someone who's doing database work all the time, or who thinks of object graphs as databases. It's certainly not the only use people make of nulls.
Absolutely, loading something from a file is a case where you would want to allow null returns, optionally also an error code.
But many other functions are either guaranteed to be able to return the correct value, or to have a suitable default.
My point is to know the difference, and only allow nulls when you have a good reason to. Never because of an ill-defined "there might be an error".
Null has to mean something. It should never be a vague possibility because "shit happens".
I don't think we have different opinions on this.
Swift helps a bit with this, in that it insists you either cover all possible values, or have a default clause.
Of course you can just leave the default empty. But at least that's a visual clue you missed the error handling.
For a given function, null return either has a meaning or it does not. "Something went wrong" is not a good enough reason to return null, unless your function documentation says what might go wrong and what that null therefore means.
If null has no meaning then make it a notnull return, or in Swift a non-optional.
I used to work with a programmer that used to make all returns optional "just in case". I wanted to punch him.
I did. It's shit.
The Atrix Lapdock didn't use the phone for either touch or display.
I'm not going to argue your interpretation of individual phrases. This patent is for a phone placed where a touchscreen would be in a laptop, so that it can be used for both touch and display.
The Atrix Lapdock had the phone vertically behind the laptop screen where it could not be used for touch or a secondary display.
Completely different.
I didn't say every claim contained something new. But the patent does. 2 examples:
"4. The electronic accessory device as recited in claim 3, wherein the operational component comprises an accessory display configured to present visual content. "
"5. The electronic accessory device as recited in claim 4, wherein the electronic host device comprises an input device configured to detect a touch event. "
Neither of these are present in the Atrix Lapdock, as it places the phone behind the laptop screen. The Apple patent has the phone placed where a touchscreen would be in a laptop, and that's what make these two claims possible.
This is a fundamental misunderstanding of patents. All patents have prior art. Indeed they list the prior art in the patent. Patents take something that is already patented, and add some new things. Patents are never for something that is entirely new, the always build on what came before.
The automated car doesn't have to be better than humans for every single case. It just has to statistically have less collisions and less fatalities than when the cars are people are driving.
Reacting to stuff in the road in front of you like your 2 examples is the easy stuff where automation is already better than you are.
Because whining about the $99 in every iOS development thread for the last 10 years *is* time-wasting. It's a trivial sum. If you think it's significant, then you are not a developer, you're a time waster.
I don't know specifically about those apps. But many apps do it as a natural result of them being little more than web-apps running in web-view.
That kind of dynamic programming is more or less dead when you switch to Swift anyway.
Web content, including Javascript is an explicit exception to the rule banning downloading code.
And if Apple know you're charging a fee, via whatever method, to get around app store fees, then they'll reject the app.
To back up the claim that you've been saying this for 4 years, you'd have to do a link to a post of yours from 4 years ago. Not one from today.
$99 is just a token sum to keep out the complete time wasters. Like you.
A 2010 Mac is not "recent".
As a matter of fact I was developing iOS apps on a 2012 Mac until last year. Then I had to work on the Android version on one, and the Mac wasn't good enough. It would compile, but it took 10 minutes to do so. Obviously that's not practical. It's Android that required me to upgrade my Mac, not iOS development.
The reason for the law is because stupid fucks like you don't realise it's not acceptable to use a hand-held phone, because you are more likely to kill people.
Clearly, libertarianism is a mental illness.
This isn't abstract you stupid jerk. People are dying because other people are using mobile phones rather than concentrating on driving.
It's perfectly simple. Holding a mobile phone whilst driving reduces your control of the vehicle, and makes you more dangerous to other road users. People are killed because of assholes that do that every day. Therefore there are laws against it. You demented libertarian fucknut.
Agreed. All the controls you might need whilst driving should be physical buttons.