Comment Re:Second category (Score 1) 427
You can't get an expensive watch to last 5 years? OMG, what is wrong with you?
You can't get an expensive watch to last 5 years? OMG, what is wrong with you?
Yeah, because it is e-paper like a kindle. Which is fine for some things, but not others.
This is outrageous, and what's worse, once the public believes the police will lie to secure the verdict they want, the confidence in the entire justice system is undermined.
So before, ONLY the washington redskins could use this marks, but now EVERYONE can use them, now their protection is removed. This helps the supposed problem?
Errm, as far as I know, in Apple's version of Objective-C you are never supposed to call myObject.someMethod() unless it is an accessor. i.e. it returns a value and has no arguments. In that case, and only in that case it is equivalent to [myObject someMethod]. Your notes look wrong to me.
There's nothing mysterious about it. The Apple compiler I think even lets you mix C++ and Objective-C in the one source file. You just write your business logic in C or C++ and call it from your gui code in objective-C. As long as your business logic is easily callable from a C interface, it isn't hard. Of course, mixing languages is always painful to some extent.
I don't see why QT can't support this. Swift and Objective-C objects map 1:1. Objective-C objects are just blobs of memory to other C-like languages. You'll be able to wrap all method calls with C wrappers.
Will it be easy? No. But it won't be any harder than it was with Objective-C. It's always hard to wrap an object framework with a foreign language.
As for Metro, I'd imagine it would be possible IF Microsoft allowed you to run non-Metro programs from their app store. I know nothing about it, but I suspect they might not. Would it be easy to wrap Metro? No, pretty hard. But it doesn't sound impossible. If there's a C interface, use that. If not, you feed method calls to the Metro engine as text strings.
Well, um, Objective-C is very dynamic by nature. This is useful when you want to do dynamic linking to new versions of libraries, or plugin style libraries with known interfaces, and so forth. It's a feature, and its pretty useful. I never heard of anyone saying it was a security issue.
Which frameworks? Cocoa in particular, but basically their entire OS-X stack.
The problem it solves is that Objective-C has its peculiarities: no garbage collection, named parameters, etc etc, and there aren't any other languages I can think of that are modern, full featured, and have those peculiarities. Without those peculiarities they'd have to rewrite Cocoa, and all their apps, and it wouldn't be easy for developers to make a slow transition.
Define proprietary. Java is pretty much proprietary, even though its been copied by now. C# is proprietary, but its been copied too. Actually, I'd have to dispute your claim that proprietary languages don't do well.
Yeah but MS hadn't redesigned their windows programming framework since the early 90s. They had to improve on a win32 C API that was truly awful. Apple on the other hand had its NeXT inspired gui framework which people actually LIKED. Nobody was really falling over themselves to throw it away, because it was pretty nice, even with all its faults.
I think there is a bit more to it than merely compiler expediency. Objective-C is very Smalltalk like, and no doubt the designers were inspired. In any case, the compiler can't be too stupid, because square brackets have meaning in C as well.
The reason why to create a new language is that the basic model of Objective-C needed to be retained for backwards compatibility. They tried to bolt garbage collection onto Objective-C, and I actually thought it was OK, but I gather they had a lot of problems, and it was buggy. Similarly, Objective-C assumes a lot of things about how objects work and stuff that you can't map precisely to any other language. A compromise, yes. But its never been easy for an OS to support any and every programming language. OSes and their native language tend to be pretty tightly integrated, unfortunately. But if you think the problems are so easy to overcome, feel free to integrate your favourite language on top. I think it won't be easy.
I'm sure the design parameters required it to be basically an enhanced Objective-C. Otherwise the entire Cocoa stack and all the libraries would need re-writing from scratch, and that ain't easy. So yeah, it's a bit pointless to compare it to other stuff.
I haven't checked, but its a great idea to have override as a mandatory descriptor (If it is). Java now has @Override, but code quality suffers from it not being compulsory, leading later to subtle bugs. As for func and let, I imagine it makes it easier to make a scripting language to have less ambiguity about what you are trying to declare up front. I mean, without func, would the line "area()" be the start of a declaration, or a call to a function? Sure, you could wait for a semi-colon to finalise the decision, but then you've got to have semi-colons.
"The four building blocks of the universe are fire, water, gravel and vinyl." -- Dave Barry