That would be a terribly depressing eight minute journey. Unless you became a human comet and smashed into Mercury or something, which would just be badass.
Why not just search for "teeth medicine" then? Google hasn't done direct keyword matching only in years now (for example, a search for "computer" may yield results containing synonyms such as "PC" or "Mac" even if the original keyword of "computer" isn't contained at all on the site).
Remember that Yahoo started out as a category browser in its very early days, and now categories are really just another keyword. Google and all of the other search engines are designed to work well for the lowest common denominator of internet users - as someone with a 3-digit UID, I imagine you're not in that group. Trying to outsmart Google will probably just make its algorithm feel unnatural/broken.
That's under the completely unsafe assumption that forms are being used properly. There have been numerous instances of people putting full SQL queries (with DB connection data) in a GET form - see TheDailyWTF.
Though I suppose that's a bad example, as it would be really damn easy for Google to index THOSE sites. Just swap in a SELECT * and you're all set:)
That's what I told them - I'm done with them, their shoddy products, their DRM, and their bad attitude. A few days later, I got a follow-up email asking me to complete a survey about their customer support.
What do you mean that's not open development? Someone has to create the standard, whether someone is a team of engineers at Google, a bunch of people in an irc room attached to sourceforge, or some kid with a good idea. As long as the documentation is given on how to implement and use that system, there's no issue.
Creating a UNIFIED open standard is an entirely separate issue. And given how many different login systems we've all used over the years, I don't see any implementation of openID changing that in any significant way for at least five years.
Look how many sites use OpenID, and then look at how many use ReCaptcha. Two completely different concepts of course, but they've both been around for roughly the same amount of time, both provide documentation for anyone to implement it, and both provide very commonly sought-after functionality. But ReCaptcha is really easy to implement for developers and provides user interface that's simple and familiar, where OpenID is quite a bit more painful to put in place and is usually implemented in a way where it's a very unconventional login system. Guess which one is in wider use.
If Google forks OpenID, provides a system that's easier to use for users (looks like it, from TFA), and implements it in such a way that's not excessively painful for developers (haven't looked at the documentation, but the docs are there for your perusal), then it will win out.
The fact that it only currently seems to work with a gmail address (or, from what I saw, handles the requests differently if one is detected) is a separate issue, and they certainly have every reason to encourage people to have a Google account, even if us cynical slashdot types will give them shit for it.
This whole thing would practically be a non-issue if mail servers could implement this directly, but that's true for a lot of things. Ideally, your email account (any standard pop/imap/exchange account) could have some tab for identity management, where you can see the authorized domains and update passwords for each domain on a per-site basis. The service provider could post a request off to the mail server, the mail server would do its thing based off the email address, password, and sending domain, and return an appropriate response.
But alas, that's not the case. So if something that Google creates pushes us towards a login system that WILL ACTUALLY SEE ADOPTION, then so much the better IMO, even counting their vendor lock-in attempts.
And this would be a serious problem? I bet that emailing random Slashdot usernames at gmail.com (and a couple of the other big ones) would get me in touch with a large percent of slashdotters; the same for the plethora of web forums out there.
Regardless, login ID != display name. There are myriad sites that log you in with your email address yet don't have it publicly displayed (or give you the option to have it shown or not).
At the end of the day, providing a system that's consistent with the other systems out there is going to bring the most adoption. I know I signed up with one of the OpenID providers at one point, have used it maybe once on a site I've never been back to, and now also have my yahoo email and flickr email both as providers too. For a system that's supposed to unify login information, I have way too many accounts with it. If all websites started using email addresses, I'd be quite OK with that, and it would be more secure than having the unified password that openID (theoretically) provides.
That, and there are plenty of completely legitimate users for having multiple accounts. Leo Laporte for example (who arguably got the ball rolling for them with an early-on podcast) has several - personal, one for TWiT updates, etc. And given that he's the third most-followed user on the service, you can bet that the Twitter crew are well aware. Plenty of other people with businesses do the same, myself included. Different content for different audiences - unlike proper blogging, you can't easily break out tweets by tags or categories.
It's crazy-verbose, but I think that kind of unnecessary clarification would be good coming from the government.
Well, until you actually see the results: <congress> <lawspassed> <law>bigoil++</law> <law>screw you</law> </lawspassed> <worthless>true</worthless> </congress>
I guess it would be a start anyways. No more spending $150k on wardrobes when you can just give a freelancer $150 for a new XSL, at the very least.
Yeah, but that record I'm pretty sure has been broken several times by Obama since.
I still wonder what the political ads would look like today had Paul somehow managed to get the Republican nomination (not that I honestly believe that the people whose votes actually count would have voted for him, regardless of the primary results). And I really wonder what the people who still approve of Bush would do, once they get out of the hospital for aneurism treatment of course.
Who constantly goes through their own web interface? EVERYONE goes through their third-party client of choice, which rely on that API. It could have taken off without the API, sure, but it absolutely would have been much slower to happen, and someone else could have easily come in before Twitter hit the tipping point.
Honestly, I don't 3x damages really make the risk/reward ratio enough to buy legitimately for anyone. The current 30,000x or so are way out of whack on the other end of things, but if you plan to deter piracy through lawsuits, you have to make people believe that they'll come out ahead financially by purchasing. There's no way to have a one in three chance of getting sued.
Don't get me wrong, I don't support maintaining a dead business model through litigation, but knowing that the most you could be fined for downloading an album is $29.97 tells people to go out and DDOS TPB because the amount they'd likely have litigated out of them is far less than the retail value of the product. It's like why you can't steal a TV, and then offer retail as payment if you get caught.
No, often times downloaders are getting sued too. And while everyone reading Slashdot knows that it's copyright infringement, I'd put money on there being a fair few people that have been sued who don't know a damn thing about copyright law, and even a couple who honestly didn't know it was illegal at all or consider it wrong (back in the original Napster days, I sure as hell didn't know any better, though I was in sixth grade or so at the time). Remember, common sense isn't nearly as common as it once was. Granted, this doesn't make ignorance of the law acceptable, but it makes six-figure settlements that much more insane. I could see $1000 as the upper limit of what I could consider even somewhat reasonable (for a downloader) - it's more than enough to send the message, but won't drive people to take out a large life insurance policy and then go suicide bomb the RIAA HQ.
For uploading the material, I certainly understand a harsher fine, but what they're asking for in damages is still insane. Of the little music I've purchased in the last five years or so, I've pirated 100% of it first, and of what I've pirated and haven't bought, I just don't listen. Not everyone is like that of course, but what they're claiming for damages is completely unreasonable given what percentage of downloads actually are legitimate lost sales.
Twitter's scaling issues (which seem to be far less problematic recently) are far more related to their internal infrastructure than anything related to IPv4, TCP/IP, or any of the other "bad" internet protocols. Sure, their mostly-unrelated issues take some credibility out of his argument nonetheless, but that doesn't invalidate his points even if it makes it more difficult to take him seriously.
I'll definitely give him SMTP. There are so many stupid email-related problems (spam being a big one) that could be avoided by having a better system in place, but back when it was being drafted there simply wasn't the hardware or bandwidth to support what would have made a better system. And you're right - it's very easy to look back on it and see its shortcomings. That doesn't mean that we couldn't work on phasing in a better system on top of the existing protocols (send a request to see if the receiving server supports the new protocol, and if so then use it, if not then fall back to SMTP... it could be done in time, especially if the big providers got on board)
Well, given that Twitter really only took off because of it's API (which is XML-based), you could say that it really is taking off, especially with how many other user-content-driven sites have APIs. Beats the hell out of page scraping, anyways.
The problem is that serving straight-up XML with an XSLT is rather flaky cross-browser (especially on mobile devices), and adds a level of confusion that not only isn't necessary in 99% of websites but is best piped through a semi-regulated system. Twitter is an awful example as they still don't have a business model (or even a revenue stream at all AFAIK), but providing premium access to certain sections of an API or an increased request limit is certainly a valid way to monetize a service like Twitter, and that will quickly fall apart if were to serve straight-up XML.
Other than cross-browser standards support and a couple of quirky CSS attributes, there's really nothing wrong with separating the content and presentation with the systems that are widely in use today. They also allow users to override the presentation with their own stylesheet. Sure, you'd generally have to do it on a site-by-site basis as there's neither a <content> or <menu> tag (but rather divs and lists with IDs set, with no cross-site consistency at all), but implementing that kind of system effectively would be beyond a nightmare. I suppose you could link out to a semantic XML version of a page via a meta tag like how we currently handle RSS feeds (could just be another xmlns attribute for this kind of thing, though you could get most of the info off of a full rss feed anyways), but there are so few people that would want to override the default presentation of a site (and even fewer who would be bothered to do so) that it just doesn't make any sense, especially as there's currently no monetary incentive to do so.
a) Google Gears. Get it. Now. b) It'd also take down your email and numerous other systems, and as a Slashdotter I assume you have a tech-oriented business that rather relies on internet connectivity so you'd be largely screwed regardless of how you manage your documents.
Yes, but they're not platform-specific for client requirements. And the clients tend to be other web servers rather than a computer that a person is actually using.
But at their heart, they're all (the above examples anyways) just a web service interface to a giant pool of resources. Anyone can throw requests at Amazon S3 for example and start storing files online. You can do it though your own little mini web app, any of dozens of different prebuilt libraries for a plethora of languages, many FTP clients, and even directly through CURL if you're so inclined.
Azure is (in my five seconds worth of understanding) a locally-installed OS that does most of that stuff for you automatically. Rather than needing an FTP client to interact with S3, a browser to use the various Google apps, and whatever else, your desktop apps will do it. Not unlike Fluid (fluidapp.com) or other single-site browsers. Except you'll need to sacrifice your firstborn to Ballmer first.
Basically, MS is sick to death of piracy and will take the MMO pricing model to your operating system. Blah. I'll pass on that one, thanks.
True, but for whatever reason it's still 10x faster than Transmission with identical settings. I guess a lot of trackers still hate it because of some long-since resolved issues with the libtransmission engine.
A real shame; Azureus/Vuze seems to be the only decently-performing client for the Mac as a result (only a couple support encryption, and many use the same libtransmission engine). The UI has always been terrible, and the extra bloat added in the transition from Azureus to Vuze was interesting for about five minutes and then just drags this awful mess of Java to a whole new level of painful. Luckily my workhorse system now has 10GB of RAM as it still sucks down half a gig (and did the same on my old 1GB systems from a while back too) so it's not too painful from a resources standpoint.
Your point is moot, a pirated copy will work on any powerful enough PC without extra expense or serious drawbacks while modding the xbox to play pirate games costs a fair bit, voids the warranty and removes accessibility to Xbox live. Not to mention the added hassle of getting the correct version to burn for each region. I think I can see which one I'd rather pirate on.
And you think that a PC with the horsepower to run Gears at Xbox 360 quality comes cheap? You can now pick up the baseline 360 for $200. You'd probably spend twice that on just your graphics card to run Gears PC at 720p.
Yes, you can download and play the games more easily on a PC than on a 360, but I've seen the high-end graphics card from a generation after mine called ancient recently, and my card (a 7900GT) is only a couple years old. For the cost of updating my graphics card to something that would run FC2, Crysis, and other recent games at good quality (I can just barely run Crysis at mostly-playable framerates at 1680x1050 at lowest everything else which is pretty fugly, FC2 is even worse at 1100x700 or something in that vague range with all settings low-medium, and 360 ports are almost always far slower than they should be), I could get a spare 360 and whatever hardware I'd need to play pirated games, and a hefty stack of dual layer discs.
Aside from the complete failure of scientific notation, you need to take into account that if we suddenly came across a black hole made of pure accessible gold or oil, the prices on said commodity would drop to below nothing.
Wouldn't it be {foo\$name} ? That would be more consistent with how static variables are accessed, and I think would only cause potential visual problem if you were accessing namespaced class constants, i.e. "{foo\bar\name}" meaning namespace foo; class bar{const name='baz';} and not some random string with a unix line break.
Yes, but if you've looked at the existing documentation for how namespace resolution was going to be implemented with the double-colon in PHP, that was equally insane. The idea was that given use A::B; (or use A::B as B;) B::C() could run: Class B method C() in the global namespace function C() in namespace A::B Class B method C() in namespace A function C() in namespace B
Or something crazy like that. I couldn't tell you if that's exactly the right explanation and I'm sure the order is wrong (can't tell you what the right order is though) but you can see the problem.
Now using a backslash as a seperator is still stupid (the pipe | isn't used for anything that I can thing of, other than comparison operators, might have made sense), but at least the way they were implementing it initially,:: would be a terrible choice.
Just being a bit more strict about name resolution would probably also have fixed the problem. Maybe requiring specifying the global NS in the use statement would have fixed it, i.e., use a::b::c as c; would have to be use::a::b::c as c specifying whatever file declared namespace a::b::c. And then use c::d would resolve to::a::b::c::d if the above was in place, and throw a fatal error if something wasn't already declaring the use of the c namespace.
Dunno. For now, I'll be sticking with the standard prefix1_prefix2_classname{} until they figure it out.
Epic failure. An ambiguous example is even linked in the summary. For starters it causes tremendous confusion in reflection; for instance if you have a namespace Foo containing a class tBar, then a string reference written 'Foo\tBar' or "Foo\\tBar" is correct, whereas "Foo\tBar" is an error as the double-quotes cause a tab character to be escaped. How awful is that?
And why would you be echoing a namespace anyways? You'll do your "use net\firehed\something as shortname;" and be done with it If you're insistent on not using 'use' then you'll wrap the whole thing in curly braces like you would for almost any other OO vars (echo "I've got a few words for you, {name\space\$user->name['first']}."; I would think).
Honestly, that problem is largely avoided by having an editor that does decent syntax highlighting. I find myself bouncing between them all the time, it really depends what I'm doing. More often than not, I'll use whichever approach allows the least escaping of quotes, since the backslashes all over the place IMO make for even worse readability than the concatenated strings.
Then again, I'm also doing my best to avoid all of the random mixing of languages that everyone does when first starting out with PHP (echoing HTML as part of a script as compared to having a standard HTML page with little bits of <?php echo $inlineVar; ?> as needed. Chances are that most people that know enough about coding to actually use namespaces (read: not most PHP coders) are doing the same. Having said that, I still think the originally-intended double-colon namespace separator would make more sense with the existing OO syntax in place. Or I do five minutes after reading the summary; the more clearly-declared intentions that using a backslash will bring will probably grow on me, even if I'm not a big fan of paying homage to old DOS folders.
Slashdot Mirror
That would be a terribly depressing eight minute journey. Unless you became a human comet and smashed into Mercury or something, which would just be badass.
Why not just search for "teeth medicine" then? Google hasn't done direct keyword matching only in years now (for example, a search for "computer" may yield results containing synonyms such as "PC" or "Mac" even if the original keyword of "computer" isn't contained at all on the site).
Remember that Yahoo started out as a category browser in its very early days, and now categories are really just another keyword. Google and all of the other search engines are designed to work well for the lowest common denominator of internet users - as someone with a 3-digit UID, I imagine you're not in that group. Trying to outsmart Google will probably just make its algorithm feel unnatural/broken.
That's under the completely unsafe assumption that forms are being used properly. There have been numerous instances of people putting full SQL queries (with DB connection data) in a GET form - see TheDailyWTF.
Though I suppose that's a bad example, as it would be really damn easy for Google to index THOSE sites. Just swap in a SELECT * and you're all set :)
More like scroll lock and SysRq, whatever the hell they're good for these days. Good riddance.
That's what I told them - I'm done with them, their shoddy products, their DRM, and their bad attitude. A few days later, I got a follow-up email asking me to complete a survey about their customer support.
Seriously.
What do you mean that's not open development? Someone has to create the standard, whether someone is a team of engineers at Google, a bunch of people in an irc room attached to sourceforge, or some kid with a good idea. As long as the documentation is given on how to implement and use that system, there's no issue.
Creating a UNIFIED open standard is an entirely separate issue. And given how many different login systems we've all used over the years, I don't see any implementation of openID changing that in any significant way for at least five years.
Look how many sites use OpenID, and then look at how many use ReCaptcha. Two completely different concepts of course, but they've both been around for roughly the same amount of time, both provide documentation for anyone to implement it, and both provide very commonly sought-after functionality. But ReCaptcha is really easy to implement for developers and provides user interface that's simple and familiar, where OpenID is quite a bit more painful to put in place and is usually implemented in a way where it's a very unconventional login system. Guess which one is in wider use.
If Google forks OpenID, provides a system that's easier to use for users (looks like it, from TFA), and implements it in such a way that's not excessively painful for developers (haven't looked at the documentation, but the docs are there for your perusal), then it will win out.
The fact that it only currently seems to work with a gmail address (or, from what I saw, handles the requests differently if one is detected) is a separate issue, and they certainly have every reason to encourage people to have a Google account, even if us cynical slashdot types will give them shit for it.
This whole thing would practically be a non-issue if mail servers could implement this directly, but that's true for a lot of things. Ideally, your email account (any standard pop/imap/exchange account) could have some tab for identity management, where you can see the authorized domains and update passwords for each domain on a per-site basis. The service provider could post a request off to the mail server, the mail server would do its thing based off the email address, password, and sending domain, and return an appropriate response.
But alas, that's not the case. So if something that Google creates pushes us towards a login system that WILL ACTUALLY SEE ADOPTION, then so much the better IMO, even counting their vendor lock-in attempts.
And this would be a serious problem? I bet that emailing random Slashdot usernames at gmail.com (and a couple of the other big ones) would get me in touch with a large percent of slashdotters; the same for the plethora of web forums out there.
Regardless, login ID != display name. There are myriad sites that log you in with your email address yet don't have it publicly displayed (or give you the option to have it shown or not).
At the end of the day, providing a system that's consistent with the other systems out there is going to bring the most adoption. I know I signed up with one of the OpenID providers at one point, have used it maybe once on a site I've never been back to, and now also have my yahoo email and flickr email both as providers too. For a system that's supposed to unify login information, I have way too many accounts with it. If all websites started using email addresses, I'd be quite OK with that, and it would be more secure than having the unified password that openID (theoretically) provides.
That, and there are plenty of completely legitimate users for having multiple accounts. Leo Laporte for example (who arguably got the ball rolling for them with an early-on podcast) has several - personal, one for TWiT updates, etc. And given that he's the third most-followed user on the service, you can bet that the Twitter crew are well aware. Plenty of other people with businesses do the same, myself included. Different content for different audiences - unlike proper blogging, you can't easily break out tweets by tags or categories.
It's crazy-verbose, but I think that kind of unnecessary clarification would be good coming from the government.
Well, until you actually see the results:
<congress>
<lawspassed>
<law>bigoil++</law>
<law>screw you</law>
</lawspassed>
<worthless>true</worthless>
</congress>
I guess it would be a start anyways. No more spending $150k on wardrobes when you can just give a freelancer $150 for a new XSL, at the very least.
Yeah, but that record I'm pretty sure has been broken several times by Obama since.
I still wonder what the political ads would look like today had Paul somehow managed to get the Republican nomination (not that I honestly believe that the people whose votes actually count would have voted for him, regardless of the primary results). And I really wonder what the people who still approve of Bush would do, once they get out of the hospital for aneurism treatment of course.
Who constantly goes through their own web interface? EVERYONE goes through their third-party client of choice, which rely on that API. It could have taken off without the API, sure, but it absolutely would have been much slower to happen, and someone else could have easily come in before Twitter hit the tipping point.
Honestly, I don't 3x damages really make the risk/reward ratio enough to buy legitimately for anyone. The current 30,000x or so are way out of whack on the other end of things, but if you plan to deter piracy through lawsuits, you have to make people believe that they'll come out ahead financially by purchasing. There's no way to have a one in three chance of getting sued.
Don't get me wrong, I don't support maintaining a dead business model through litigation, but knowing that the most you could be fined for downloading an album is $29.97 tells people to go out and DDOS TPB because the amount they'd likely have litigated out of them is far less than the retail value of the product. It's like why you can't steal a TV, and then offer retail as payment if you get caught.
No, often times downloaders are getting sued too. And while everyone reading Slashdot knows that it's copyright infringement, I'd put money on there being a fair few people that have been sued who don't know a damn thing about copyright law, and even a couple who honestly didn't know it was illegal at all or consider it wrong (back in the original Napster days, I sure as hell didn't know any better, though I was in sixth grade or so at the time). Remember, common sense isn't nearly as common as it once was. Granted, this doesn't make ignorance of the law acceptable, but it makes six-figure settlements that much more insane. I could see $1000 as the upper limit of what I could consider even somewhat reasonable (for a downloader) - it's more than enough to send the message, but won't drive people to take out a large life insurance policy and then go suicide bomb the RIAA HQ.
For uploading the material, I certainly understand a harsher fine, but what they're asking for in damages is still insane. Of the little music I've purchased in the last five years or so, I've pirated 100% of it first, and of what I've pirated and haven't bought, I just don't listen. Not everyone is like that of course, but what they're claiming for damages is completely unreasonable given what percentage of downloads actually are legitimate lost sales.
Yes, but Twitter has the audience already. Being the first is often far more important than being the best, unfortunately.
Twitter's scaling issues (which seem to be far less problematic recently) are far more related to their internal infrastructure than anything related to IPv4, TCP/IP, or any of the other "bad" internet protocols. Sure, their mostly-unrelated issues take some credibility out of his argument nonetheless, but that doesn't invalidate his points even if it makes it more difficult to take him seriously.
I'll definitely give him SMTP. There are so many stupid email-related problems (spam being a big one) that could be avoided by having a better system in place, but back when it was being drafted there simply wasn't the hardware or bandwidth to support what would have made a better system. And you're right - it's very easy to look back on it and see its shortcomings. That doesn't mean that we couldn't work on phasing in a better system on top of the existing protocols (send a request to see if the receiving server supports the new protocol, and if so then use it, if not then fall back to SMTP... it could be done in time, especially if the big providers got on board)
Well, given that Twitter really only took off because of it's API (which is XML-based), you could say that it really is taking off, especially with how many other user-content-driven sites have APIs. Beats the hell out of page scraping, anyways.
The problem is that serving straight-up XML with an XSLT is rather flaky cross-browser (especially on mobile devices), and adds a level of confusion that not only isn't necessary in 99% of websites but is best piped through a semi-regulated system. Twitter is an awful example as they still don't have a business model (or even a revenue stream at all AFAIK), but providing premium access to certain sections of an API or an increased request limit is certainly a valid way to monetize a service like Twitter, and that will quickly fall apart if were to serve straight-up XML.
Other than cross-browser standards support and a couple of quirky CSS attributes, there's really nothing wrong with separating the content and presentation with the systems that are widely in use today. They also allow users to override the presentation with their own stylesheet. Sure, you'd generally have to do it on a site-by-site basis as there's neither a <content> or <menu> tag (but rather divs and lists with IDs set, with no cross-site consistency at all), but implementing that kind of system effectively would be beyond a nightmare. I suppose you could link out to a semantic XML version of a page via a meta tag like how we currently handle RSS feeds (could just be another xmlns attribute for this kind of thing, though you could get most of the info off of a full rss feed anyways), but there are so few people that would want to override the default presentation of a site (and even fewer who would be bothered to do so) that it just doesn't make any sense, especially as there's currently no monetary incentive to do so.
a) Google Gears. Get it. Now.
b) It'd also take down your email and numerous other systems, and as a Slashdotter I assume you have a tech-oriented business that rather relies on internet connectivity so you'd be largely screwed regardless of how you manage your documents.
Yes, but they're not platform-specific for client requirements. And the clients tend to be other web servers rather than a computer that a person is actually using.
But at their heart, they're all (the above examples anyways) just a web service interface to a giant pool of resources. Anyone can throw requests at Amazon S3 for example and start storing files online. You can do it though your own little mini web app, any of dozens of different prebuilt libraries for a plethora of languages, many FTP clients, and even directly through CURL if you're so inclined.
Azure is (in my five seconds worth of understanding) a locally-installed OS that does most of that stuff for you automatically. Rather than needing an FTP client to interact with S3, a browser to use the various Google apps, and whatever else, your desktop apps will do it. Not unlike Fluid (fluidapp.com) or other single-site browsers. Except you'll need to sacrifice your firstborn to Ballmer first.
Basically, MS is sick to death of piracy and will take the MMO pricing model to your operating system. Blah. I'll pass on that one, thanks.
True, but for whatever reason it's still 10x faster than Transmission with identical settings. I guess a lot of trackers still hate it because of some long-since resolved issues with the libtransmission engine.
A real shame; Azureus/Vuze seems to be the only decently-performing client for the Mac as a result (only a couple support encryption, and many use the same libtransmission engine). The UI has always been terrible, and the extra bloat added in the transition from Azureus to Vuze was interesting for about five minutes and then just drags this awful mess of Java to a whole new level of painful. Luckily my workhorse system now has 10GB of RAM as it still sucks down half a gig (and did the same on my old 1GB systems from a while back too) so it's not too painful from a resources standpoint.
Your point is moot, a pirated copy will work on any powerful enough PC without extra expense or serious drawbacks while modding the xbox to play pirate games costs a fair bit, voids the warranty and removes accessibility to Xbox live. Not to mention the added hassle of getting the correct version to burn for each region. I think I can see which one I'd rather pirate on.
And you think that a PC with the horsepower to run Gears at Xbox 360 quality comes cheap? You can now pick up the baseline 360 for $200. You'd probably spend twice that on just your graphics card to run Gears PC at 720p.
Yes, you can download and play the games more easily on a PC than on a 360, but I've seen the high-end graphics card from a generation after mine called ancient recently, and my card (a 7900GT) is only a couple years old. For the cost of updating my graphics card to something that would run FC2, Crysis, and other recent games at good quality (I can just barely run Crysis at mostly-playable framerates at 1680x1050 at lowest everything else which is pretty fugly, FC2 is even worse at 1100x700 or something in that vague range with all settings low-medium, and 360 ports are almost always far slower than they should be), I could get a spare 360 and whatever hardware I'd need to play pirated games, and a hefty stack of dual layer discs.
Aside from the complete failure of scientific notation, you need to take into account that if we suddenly came across a black hole made of pure accessible gold or oil, the prices on said commodity would drop to below nothing.
Wouldn't it be {foo\$name} ? That would be more consistent with how static variables are accessed, and I think would only cause potential visual problem if you were accessing namespaced class constants, i.e. "{foo\bar\name}" meaning namespace foo; class bar{const name='baz';} and not some random string with a unix line break.
Yes, but if you've looked at the existing documentation for how namespace resolution was going to be implemented with the double-colon in PHP, that was equally insane. The idea was that given
use A::B; (or use A::B as B;)
B::C() could run:
Class B method C() in the global namespace
function C() in namespace A::B
Class B method C() in namespace A
function C() in namespace B
Or something crazy like that. I couldn't tell you if that's exactly the right explanation and I'm sure the order is wrong (can't tell you what the right order is though) but you can see the problem.
Now using a backslash as a seperator is still stupid (the pipe | isn't used for anything that I can thing of, other than comparison operators, might have made sense), but at least the way they were implementing it initially, :: would be a terrible choice.
Just being a bit more strict about name resolution would probably also have fixed the problem. Maybe requiring specifying the global NS in the use statement would have fixed it, i.e., use a::b::c as c; would have to be use ::a::b::c as c specifying whatever file declared namespace a::b::c. And then use c::d would resolve to ::a::b::c::d if the above was in place, and throw a fatal error if something wasn't already declaring the use of the c namespace.
Dunno. For now, I'll be sticking with the standard prefix1_prefix2_classname{} until they figure it out.
Epic failure. An ambiguous example is even linked in the summary. For starters it causes tremendous confusion in reflection; for instance if you have a namespace Foo containing a class tBar, then a string reference written 'Foo\tBar' or "Foo\\tBar" is correct, whereas "Foo\tBar" is an error as the double-quotes cause a tab character to be escaped. How awful is that?
And why would you be echoing a namespace anyways? You'll do your "use net\firehed\something as shortname;" and be done with it If you're insistent on not using 'use' then you'll wrap the whole thing in curly braces like you would for almost any other OO vars (echo "I've got a few words for you, {name\space\$user->name['first']}."; I would think).
Honestly, that problem is largely avoided by having an editor that does decent syntax highlighting. I find myself bouncing between them all the time, it really depends what I'm doing. More often than not, I'll use whichever approach allows the least escaping of quotes, since the backslashes all over the place IMO make for even worse readability than the concatenated strings.
Then again, I'm also doing my best to avoid all of the random mixing of languages that everyone does when first starting out with PHP (echoing HTML as part of a script as compared to having a standard HTML page with little bits of <?php echo $inlineVar; ?> as needed. Chances are that most people that know enough about coding to actually use namespaces (read: not most PHP coders) are doing the same. Having said that, I still think the originally-intended double-colon namespace separator would make more sense with the existing OO syntax in place. Or I do five minutes after reading the summary; the more clearly-declared intentions that using a backslash will bring will probably grow on me, even if I'm not a big fan of paying homage to old DOS folders.