I'd opine that it's only VERY backwards compatible if the PHP4 that you're upgrading isn't primarily OO.
I mean, to get it to compile all you need is run the code thru a simple pre-processor to turn (basically) this:
class stdClass {
var someVar;
function stdClass() {... }
function someFunc() {... }
function _privateFunc() {... }
function m_otherPrivateFunc() {... } }
Into this:
class stdClass {
public someVar;
function __constructor() {... }
public function someFunc() {... }
private function _privateFunc() {... }
private function m_otherPrivateFunc() {... } }
And even of that the change to the constructor isn't necessary.
Basically just add access modifiers.
HOWEVER.. that doesn't mean backwards compatibility.
If you're writing real OOD PHP applications, and not just using some "helper objects" (like for DB access, error handling, etc) then there's a good chance that you'll find at least one bug.
See, they added destructors, interfaces, and access modifiers. But there wasn't many CHANGES.
There was a big one though: In PHP4 objects are COPIED when passed unless otherwise specified.
In PHP5 objects are REFERENCED when passed unless otherwise specified.
So imagine code like this:
function processObject($obj) {// Process the object in some fashion and returned a slightly modified object. }
$obj = new someClass(); $objCopy = processObject($obj);
In PHP4, a copy is made when passing to processObject.
Any modification to the object inside processobject happens on the copy. $obj remains untouched.
However, after upgrading, that's changed now to implicitly pass by reference.
This can make some subtle bugs.
Usually pass-by-value is a mistake and a waste of resources.
But it's easy for devs (especially not those familiar w/ OOD in another language) to write code that relies on implicit byval without realizing it.
That code will all still compile. They'll just be some funny behavior reported that doesn't make sense and is eventually tracked down to an errant byval call that's now an implicit byref.
But you'll be so lovin' the interfaces and class variables and access modifiers that you'll forgive it.
Isn't it about as basic as it gets that code (outside of Java) should be developed on the same platform that it will ultimately be deployed upon?
If he had done that, all he'd have needed to do was get a copy of the binary as compiled for use on the production server, and their php.ini. Install, copy in the php.ini, and he's up and running in an environment identical to the Prod server.
Barring that, if he'd had gotten their php.ini anyone w/ any PHP experience would be able to see what non-std components were included, and the version everything is running at. Download it, compile it, install, and copy-in the php.ini.
If he's spending a "good fraction" to get a "test bed" then he really should stick to tech support or network administration or whatever he's done over the past few years full time for a living.
First of all, if you don't re-indent your after adding another nesting level, you are making your code hard to read, and if I have to work on it after you, I will hate you for it. This is one of the reasons that Python is so pleasant. It forces people to write decent code.
Secondly, if you're manually indenting each line of code, you should start using a modern text editor.
Aren't you contradicting yourself here?
More pointedly: If poorly-indented code is so troublesome that you'd "hate" the offending developer, you should start using a modern IDE.
Just curious -- what's stopping you from running Fox Pro 9 until the bits crumble into sand?
For example, in the early part of this decade my partner and I were able to cut a small niche out for ourselves doing data-level integration w/ the Symantec ACT! program.
The reason I bring it up is that Act! uses a Fox Pro DB. We still get change and support requests and when we do it's a bit like taking a time warp because I just use all the same tools and all the same custom libraries that we wrote 7 years ago.
(VB6, coincidentally enough)
Anyway, every situation is different, I'm just curious why the lack of an upgrade path is a bad thing. It's not as if Microsoft has disabled FoxPro and is requiring a migration over to SQL Server Express or something?
Is your experience in using a botnet to harvest personal data from users?
Because in this particular case, the value of the data is nothing more than its sunk cost + opportunity cost.
It was collected so quickly, that those are both low.
If you can get 100 more CC numbers and bank accounts in a day/week/whatev the value of the data is less.
Kinda like how if you make $120 an hour you can justify spending $4 on a cup of coffee where you really can't if you're out there making $6.50 an hour.
"Same here, which is why we avoid Microsoft lock-in like the plague it is"
Plague? Oh, please. But if it was really "same here" for you -- if sales growth was important -- then you would be happy to embrace a ubiquitous business platform.
We use OSS tools, as well. Not much Java, but plenty of LAMPP.
"Do you have the luxury of watching your hard work vaporize because the next version of Word drops some of the functions you use, and the current version won't run on Windows 7"
Honestly, I've been doing this for an awfully long time and this has NEVER happened to me in any meaningful way.
I mean, were you just pulling the "drops some of the fucntions" line out of thin air? I've been doing VBA scripting and/or COM-based integration since Office 97 (when it was introduced, I think) and we still do maintenance and change requests on apps from that era.
I really doubt you're a dumb guy -- based on your UID alone I'd like to think you know what you're talking about -- but you do realize that backwards compatibility has been sacrosanct in Windows and office?
And that Windows 7 currently is nothing more than rumor, but if it does ship to the specifications talked about today, it will all be source compatible? And that it may, via a VM, be binary compatible?
Further, are you suggesting that Unix, Linux, and OSX will never break binary compatibility? (Especially considering OSX already has).
Honestly, the only platform on which I'd feel backwards compatibility is more assured than on Windows is on Mainframes/X-Series Minis.
And that's an entirely different beast.
Ya know.. I'm a fan of elegance. Elegant code. Elegant solutions. Windows is not elegant. My daughters and wife use macbooks. For non-work computing, I use one as well.
But having dogmatic "principles" in software development is an academic exercise that just has no place in a small company that wants to be successful. And really, it's a joke to me anyway. It makes about as much sense, to me, as arguing Ford versus Chevy. Or Coke versus Pepsi.
There's nothing wrong with specialization. Nothing wrong with a company specializing on fixing Chevy's or building solutions using only OSS software.
But if you reached that decision not based on your assessment of market needs and personal competence, but instead based on some missionary-like notion that you need to save the world from the "plague" that is Microsoft, then honestly, your business deserves to fail.
No, it's just that for most people compatibility no longer an issue.
I can't recall the last time I sent a Word/Excel doc to somebody who couldn't open it.
Nor can I recall having a WP file sent to me in the last decade or so. Besides, Word CAN open up WP docs saved in the WP5 or WP6 formats.
Now.. as a developer, I have done some pretty great things with Office. Not so much using Office as the platform (although everyones done a bit of that at some point), but moreso just automating it in C#/Visual C++ using its COM wrapper.
A good example is an MRP we wrote in C# that uses Excel as a reporting platform.
Many here just can't get past the idea that it's closed-source, a MSFT product, etc. Me? I just want to deliver the best software I can. We're a small company. Top Line growth is important. And I don't have the luxury of indulging personal preferences.
What's likely is that if you were to steal a credit card number, you'd also steal 20 others that day, and 20 more the next, and so on.
And all of a sudden the value of a given CC is almost zero.
A more apt analogy would be like a bank robber stealing $100,000 and fretting over each $100 bill. If YOU dropped $500 finding it would be your #1 priority. The same could not be said of that bank robber.
When you can collect that much data that quickly it has very little value.
Even if all the data were compromised and all the CC/Acct numbers changed before the harvester could use it, the only thing truly lost is the opportunity costs involved in gathering the data itself.
It just makes no sense to spend time securing the data and coming up with an authentication mechanism (After all, this server needs to accept uploaded data from their botnet.)
That time would be better spent just creating more systems to harvest more data.
Nobody ever suggested that.Net would REPLACE the Win32 API.
It was sold as a simple abstraction layer. That's it.
Microsoft DID, however say that managed code was the future. And it is.
Those that point to the "failure" of managed code in Vista are oversimplifying. Look at the Singularity concept. A managed code OS works. The problem was the mixing of managed and unmanaged code.
For example, when they were developing the windowing system, every unmanaged library the new managed-code windowing system called had to have a managed-code wrapper. At the OS level this caused too much a performance hit.
Now, if all the libraries were native, there wouldn't be that problem.
Anyway, I'm getting off target:.Net was ANYTHING but "hastily cobbled." They hired Anders just for.Net. The project began in the mid/late 90s.
And the results are excellent..Net is an excellent environment, a PLEASURE to use, which is more than I can say about template metaprogramming in C++.
And actually,.Net isn't tied to a single platform. I've written about a dozen C# apps of all sizes, from simple CLI apps to more complex client/server apps. 11/12 runs flawlessly on Mono.
C++ isn't going away for a long, long time. But Managed code is here to stay.
Pesonally, I don't think.Net will ever be ported to a different underlying platform, but there's no technical reason that it couldn't be.
There's absolutely no reason why the thin wrappers that you (correctly) point out couldn't be turned into more complex abstraction layers.
Now, I think this will never happen because it's not what.Net was designed for. It's never been sold as a future-proof platform that will carry binary compatability far past the win32 days.
It's merely a much better organized and standardized interface to the API.
"especially since we all remember a time when it was basically impossible to do"
Sure, if you mean specifically using the XMLHttpRequest object.
Personally, I've been using hidden iFrames (and/or <img> tags) and document.write (in the pre DOM 2.0 days) to accomplish the same thing since the late 90s.
I wrote a tiny framework (which I named Jespecial, a name I still like more than AJAX) in both PHP4 and ASP that would take a server-side array and create a JavaScript array out of it. The array would be pushed down into JS code written on an iFrame refresh.
You know.. I'm a software developer... and I've never been much of an OSS enthusiast (although I am writing this from Firefox. I'm not a moron).
But for things like this, I agree with you. The upside potential is just too great. A rogue coder (or rogue CEO) could too easily effect a contest with FAR too great of payoff.
And for those tin foil hat types, a NSA or CIA could even create an start-up that looks legit just for the purpose of creating the voting machines. Now THAT is one scary f'in scenario.
As does the Thinkpad on my desk that was purchased in the late 90's/early00s that I'm now using as my on-the-go staging server.
This company generally buys high-end, so I'm sure this was a helluva expensive laptop when they bought it, but still, it's 10 years old and includes the motion sensors.
IIRC, they had some commercials about this feature.. showing a laptop flying off a desk in slo-mo while the narrator talks about how the Hard Disk won't push the platters into the heads because the laptop knows when it's falling.
Personally, I always thought that they'd probably sell more computers if they made the damn thing play a WAV of a person screaming as it fell. I'm sure some people would drop it just for the fun. Surely enough people would fumble the catch that IBM could recoup the costs of including the sound effect!
Slashdot Mirror
I'd opine that it's only VERY backwards compatible if the PHP4 that you're upgrading isn't primarily OO.
... }
... }
... }
... }
... }
... }
... }
... }
// Process the object in some fashion and returned a slightly modified object.
I mean, to get it to compile all you need is run the code thru a simple pre-processor to turn (basically) this:
class stdClass {
var someVar;
function stdClass() {
function someFunc() {
function _privateFunc() {
function m_otherPrivateFunc() {
}
Into this:
class stdClass {
public someVar;
function __constructor() {
public function someFunc() {
private function _privateFunc() {
private function m_otherPrivateFunc() {
}
And even of that the change to the constructor isn't necessary.
Basically just add access modifiers.
HOWEVER.. that doesn't mean backwards compatibility.
If you're writing real OOD PHP applications, and not just using some "helper objects" (like for DB access, error handling, etc) then there's a good chance that you'll find at least one bug.
See, they added destructors, interfaces, and access modifiers. But there wasn't many CHANGES.
There was a big one though: In PHP4 objects are COPIED when passed unless otherwise specified.
In PHP5 objects are REFERENCED when passed unless otherwise specified.
So imagine code like this:
function processObject($obj) {
}
$obj = new someClass();
$objCopy = processObject($obj);
In PHP4, a copy is made when passing to processObject.
Any modification to the object inside processobject happens on the copy. $obj remains untouched.
However, after upgrading, that's changed now to implicitly pass by reference.
This can make some subtle bugs.
Usually pass-by-value is a mistake and a waste of resources.
But it's easy for devs (especially not those familiar w/ OOD in another language) to write code that relies on implicit byval without realizing it.
That code will all still compile. They'll just be some funny behavior reported that doesn't make sense and is eventually tracked down to an errant byval call that's now an implicit byref.
But you'll be so lovin' the interfaces and class variables and access modifiers that you'll forgive it.
Well, most users should be saved just by coincidence.
// Assuming magic_quotes is on...
/* Let $_GET['username'] = testUser */
...now...
Using the example in the article:
<?php
$sql = "INSERT INTO USERS (USERNAME) VALUES $_GET['username']";
?>
If magic quotes is, indeed, on, the database will see a query that looks like this:
INSERT INTO USERS (USERNAME) VALUES 'testUser'
if magic quotes is turned off, sure, an injection attack is possible, as the query will become:
INSERT INTO USERS (USERNAME) VALUES testUser
And as long as a dev tests their code after upgrading to v6.0 they'd notice that the DBMS has thrown a 'testUser is not a column/udf/sproc' error.
...He took the "contract." Nobody was forced.
But his post is inane.
Isn't it about as basic as it gets that code (outside of Java) should be developed on the same platform that it will ultimately be deployed upon?
If he had done that, all he'd have needed to do was get a copy of the binary as compiled for use on the production server, and their php.ini. Install, copy in the php.ini, and he's up and running in an environment identical to the Prod server.
Barring that, if he'd had gotten their php.ini anyone w/ any PHP experience would be able to see what non-std components were included, and the version everything is running at. Download it, compile it, install, and copy-in the php.ini.
If he's spending a "good fraction" to get a "test bed" then he really should stick to tech support or network administration or whatever he's done over the past few years full time for a living.
Secondly, if you're manually indenting each line of code, you should start using a modern text editor.
Aren't you contradicting yourself here?
More pointedly: If poorly-indented code is so troublesome that you'd "hate" the offending developer, you should start using a modern IDE.
Really?
Like what?
Really, can you give me one example of the "hard work" you're talking about?
...You have to... burn the keyboard?
Just curious -- what's stopping you from running Fox Pro 9 until the bits crumble into sand?
For example, in the early part of this decade my partner and I were able to cut a small niche out for ourselves doing data-level integration w/ the Symantec ACT! program.
The reason I bring it up is that Act! uses a Fox Pro DB. We still get change and support requests and when we do it's a bit like taking a time warp because I just use all the same tools and all the same custom libraries that we wrote 7 years ago.
(VB6, coincidentally enough)
Anyway, every situation is different, I'm just curious why the lack of an upgrade path is a bad thing. It's not as if Microsoft has disabled FoxPro and is requiring a migration over to SQL Server Express or something?
Is your experience in using a botnet to harvest personal data from users?
Because in this particular case, the value of the data is nothing more than its sunk cost + opportunity cost.
It was collected so quickly, that those are both low.
If you can get 100 more CC numbers and bank accounts in a day/week/whatev the value of the data is less.
Kinda like how if you make $120 an hour you can justify spending $4 on a cup of coffee where you really can't if you're out there making $6.50 an hour.
So there you go, now re-correlate.
"Same here, which is why we avoid Microsoft lock-in like the plague it is"
Plague? Oh, please. But if it was really "same here" for you -- if sales growth was important -- then you would be happy to embrace a ubiquitous business platform.
We use OSS tools, as well. Not much Java, but plenty of LAMPP.
"Do you have the luxury of watching your hard work vaporize because the next version of Word drops some of the functions you use, and the current version won't run on Windows 7"
Honestly, I've been doing this for an awfully long time and this has NEVER happened to me in any meaningful way.
I mean, were you just pulling the "drops some of the fucntions" line out of thin air? I've been doing VBA scripting and/or COM-based integration since Office 97 (when it was introduced, I think) and we still do maintenance and change requests on apps from that era.
I really doubt you're a dumb guy -- based on your UID alone I'd like to think you know what you're talking about -- but you do realize that backwards compatibility has been sacrosanct in Windows and office?
And that Windows 7 currently is nothing more than rumor, but if it does ship to the specifications talked about today, it will all be source compatible? And that it may, via a VM, be binary compatible?
Further, are you suggesting that Unix, Linux, and OSX will never break binary compatibility? (Especially considering OSX already has).
Honestly, the only platform on which I'd feel backwards compatibility is more assured than on Windows is on Mainframes/X-Series Minis.
And that's an entirely different beast.
Ya know.. I'm a fan of elegance. Elegant code. Elegant solutions. Windows is not elegant. My daughters and wife use macbooks. For non-work computing, I use one as well.
But having dogmatic "principles" in software development is an academic exercise that just has no place in a small company that wants to be successful. And really, it's a joke to me anyway. It makes about as much sense, to me, as arguing Ford versus Chevy. Or Coke versus Pepsi.
There's nothing wrong with specialization. Nothing wrong with a company specializing on fixing Chevy's or building solutions using only OSS software.
But if you reached that decision not based on your assessment of market needs and personal competence, but instead based on some missionary-like notion that you need to save the world from the "plague" that is Microsoft, then honestly, your business deserves to fail.
No, it's just that for most people compatibility no longer an issue.
I can't recall the last time I sent a Word/Excel doc to somebody who couldn't open it.
Nor can I recall having a WP file sent to me in the last decade or so. Besides, Word CAN open up WP docs saved in the WP5 or WP6 formats.
Now.. as a developer, I have done some pretty great things with Office. Not so much using Office as the platform (although everyones done a bit of that at some point), but moreso just automating it in C#/Visual C++ using its COM wrapper.
A good example is an MRP we wrote in C# that uses Excel as a reporting platform.
Many here just can't get past the idea that it's closed-source, a MSFT product, etc. Me? I just want to deliver the best software I can. We're a small company. Top Line growth is important. And I don't have the luxury of indulging personal preferences.
Eat shit and die, troll. ...oh, wait...
Sure. But that's not a likely scenario.
What's likely is that if you were to steal a credit card number, you'd also steal 20 others that day, and 20 more the next, and so on.
And all of a sudden the value of a given CC is almost zero.
A more apt analogy would be like a bank robber stealing $100,000 and fretting over each $100 bill. If YOU dropped $500 finding it would be your #1 priority. The same could not be said of that bank robber.
But that's honestly a little naive.
It's like the guy that steals your mail to get your account numbers. Do you think he shreds those when he's done with it?
The cost of data-loss to these criminals is so low to nearly be non-existent.
It's simple threat assessment / risk analysis.
So what?
When you can collect that much data that quickly it has very little value.
Even if all the data were compromised and all the CC/Acct numbers changed before the harvester could use it, the only thing truly lost is the opportunity costs involved in gathering the data itself.
It just makes no sense to spend time securing the data and coming up with an authentication mechanism (After all, this server needs to accept uploaded data from their botnet.)
That time would be better spent just creating more systems to harvest more data.
Huh?
.Net would REPLACE the Win32 API.
.Net was ANYTHING but "hastily cobbled." They hired Anders just for .Net. The project began in the mid/late 90s.
.Net is an excellent environment, a PLEASURE to use, which is more than I can say about template metaprogramming in C++.
.Net isn't tied to a single platform. I've written about a dozen C# apps of all sizes, from simple CLI apps to more complex client/server apps. 11/12 runs flawlessly on Mono.
.Net really is a pretty good start.
Nobody ever suggested that
It was sold as a simple abstraction layer. That's it.
Microsoft DID, however say that managed code was the future. And it is.
Those that point to the "failure" of managed code in Vista are oversimplifying. Look at the Singularity concept. A managed code OS works. The problem was the mixing of managed and unmanaged code.
For example, when they were developing the windowing system, every unmanaged library the new managed-code windowing system called had to have a managed-code wrapper. At the OS level this caused too much a performance hit.
Now, if all the libraries were native, there wouldn't be that problem.
Anyway, I'm getting off target:
And the results are excellent.
And actually,
C++ isn't going away for a long, long time. But Managed code is here to stay.
And
Pesonally, I don't think .Net will ever be ported to a different underlying platform, but there's no technical reason that it couldn't be.
.Net was designed for. It's never been sold as a future-proof platform that will carry binary compatability far past the win32 days.
There's absolutely no reason why the thin wrappers that you (correctly) point out couldn't be turned into more complex abstraction layers.
Now, I think this will never happen because it's not what
It's merely a much better organized and standardized interface to the API.
"crappy binary blob formats."
..i wonder if they have NIC cards in ATM machines... .... Just f'in w/ ya
Speaking of that..
"especially since we all remember a time when it was basically impossible to do"
Sure, if you mean specifically using the XMLHttpRequest object.
Personally, I've been using hidden iFrames (and/or <img> tags) and document.write (in the pre DOM 2.0 days) to accomplish the same thing since the late 90s.
I wrote a tiny framework (which I named Jespecial, a name I still like more than AJAX) in both PHP4 and ASP that would take a server-side array and create a JavaScript array out of it. The array would be pushed down into JS code written on an iFrame refresh.
I'm just sayin'...
Read the fricken snopes article linked above.
Does your mother still feed you off the teat or do you help yourself when you're hungry?
Exactly.
Lost what game?
Pointing out (rather correctly) that you're a douchebag? All I have to do is click on my name to get to your comment. It's so easy I can't NOT do it.
You've actually bookmarked this thread (or you navigate to it manually?) just so you can argue... what, exactly?
I do have fun when your type sticks their head up. Makes a pretty easy target. So I do very much encourage you to keep it up.
Tell me this: where is the contradiction?
I said "eary 00s." So, clearly, right up front, I put it out there that it's possibly as new as 2003 (2004 would have to be considered mid-00's, IMO).
The problem is you've taken an obvious hyperbole as a literal. A figure of speech as regular is metaphor, simile, sarcasm, etc.
So maybe it's some sort of learning disorder? Like aspergers for reading comprehension -- you never learned how to use context clues?
I do hope you come back for more. This is very enjoyable.
But do tell me more about how I "lost the game."
You should get some sorta award here :)
The Russians (And the US) did, indeed, use pencils.
And NASA did, indeed, commission the creation of the pen.
So that's a "yes" to my question? Good. Glad you could concede that point.
Here's another estimate: I estimate that you're a pedantic douche-bag.
And I'm willing to bet I'm at least 75% correct on that one.
I'm sorry, does 2003 not qualify as "early 00s" ?
You know.. I'm a software developer... and I've never been much of an OSS enthusiast (although I am writing this from Firefox. I'm not a moron).
But for things like this, I agree with you. The upside potential is just too great. A rogue coder (or rogue CEO) could too easily effect a contest with FAR too great of payoff.
And for those tin foil hat types, a NSA or CIA could even create an start-up that looks legit just for the purpose of creating the voting machines. Now THAT is one scary f'in scenario.
As does the Thinkpad on my desk that was purchased in the late 90's/early00s that I'm now using as my on-the-go staging server.
This company generally buys high-end, so I'm sure this was a helluva expensive laptop when they bought it, but still, it's 10 years old and includes the motion sensors.
IIRC, they had some commercials about this feature.. showing a laptop flying off a desk in slo-mo while the narrator talks about how the Hard Disk won't push the platters into the heads because the laptop knows when it's falling.
Personally, I always thought that they'd probably sell more computers if they made the damn thing play a WAV of a person screaming as it fell. I'm sure some people would drop it just for the fun. Surely enough people would fumble the catch that IBM could recoup the costs of including the sound effect!