He also says that framework "shouldn't imply a link between open source and open standards"
Aside from a citation at the beginning of the document, "open source" and "open standards" are not tied together anywhere in the document. The framework itself only recommends that projects make "use of open standards" and "assess the benefits of open source software" along with other things such as security, accessibility and multilingualism as general principles to foster interoperability. And from the standpoint of interoperability, it only makes sense to do so.
Fundamentally, open source and open standards are completely orthogonal concepts. Commercial sofware may implement open standards. Open source software may make use of non-standard protocols or file formats. The only relation between them should be that a standard to be considered truly open should be implementable in open source form (in other words, anybody should be able to implement a specification, no royalties required).
how is it anything like java? Maybe I'm missing the obvious, but all the 'old' scripts I have still work pretty good - without stopping any browser for 15 seconds (java) while it does its thing
Are you talking about Java applets (and the time the VM takes to be loaded by the browser)? Java applets play a *very* minor role in today's Java picture. Java is used much more often on the server side, running in the web server (generating web pages as PHP does), or in application servers (implementing business logic and doing database transactions). Java has got a lot of momentum in the last 5-6 years. Making PHP more easily integrated with Java will enable it to fit into that picture, probably being a better choice than using Java itself for generating web pages. Not mentioning the huge number of Java libraries (for every application you can think of) - if PHP could call Java code without compromising performance, all those libraries would be readily available for use in PHP scripts.
"That's one of the real problems in today's programming language architecture for exception handling. Each component should list the exceptions that were"That's one of the real problems in today's programming language architecture for exception handling. Each component should list the exceptions that were raised: typically if I call you and you say that you can raise A, B, and C, but you can call Joe who can raise D, E, and F, and you ignore D, E, and F, then I'm suddenly faced with D, E, and F at my level and there's nothing in your interface that said D, E, and F errors were things you caused. That seems to be ubiquitous in the programming and the language facilities. You are never required to say these are all the errors that might escape from a call to me. And that's because you're allowed to ignore errors."
I bet he didn't look into Java. Java (at least) allows and enforces that. A method will only throw an exception if declares to do so. A caller is forced to provide appropriate handlers or to declare it throws the exceptions not handled at its level. If a method can throw A, B or C but gets D during its execution, it has to in some way map D to either A, B or C (or not throw an exception at all).
Of course, I am talking here about checked exceptions. Unchecked exceptions are supposed to represent *bugs*, and nobody should be trying to capture those.
The sad thing is that even seasoned Java programmers do not understand how to write code w.r.t. exception handling. And beginners are usually turned off by the verbosity required by exception handling, so it is usual to see code where people capture (because they are forced by the language) and ignore exceptions (because they are too lazy and/or stupid to understand the consequences).
Kylix (http://www.borland.com/kylix/) is Borland's IDE for Object Pascal and C++ development for Linux. They even have an Open Edition, which is free but requires the code developed with it to be GPL'd. They have enterprise-level offerings too.
Slashdot Mirror
"What to do if you see a violation of the GNU GPL, LGPL or FDL"
He also says that framework "shouldn't imply a link between open source and open standards"
Aside from a citation at the beginning of the document, "open source" and "open standards" are not tied together anywhere in the document. The framework itself only recommends that projects make "use of open standards" and "assess the benefits of open source software" along with other things such as security, accessibility and multilingualism as general principles to foster interoperability. And from the standpoint of interoperability, it only makes sense to do so.Fundamentally, open source and open standards are completely orthogonal concepts. Commercial sofware may implement open standards. Open source software may make use of non-standard protocols or file formats. The only relation between them should be that a standard to be considered truly open should be implementable in open source form (in other words, anybody should be able to implement a specification, no royalties required).
RCAre you talking about Java applets (and the time the VM takes to be loaded by the browser)? Java applets play a *very* minor role in today's Java picture. Java is used much more often on the server side, running in the web server (generating web pages as PHP does), or in application servers (implementing business logic and doing database transactions). Java has got a lot of momentum in the last 5-6 years. Making PHP more easily integrated with Java will enable it to fit into that picture, probably being a better choice than using Java itself for generating web pages. Not mentioning the huge number of Java libraries (for every application you can think of) - if PHP could call Java code without compromising performance, all those libraries would be readily available for use in PHP scripts.
--Lose your sig in two weeks - ask me how!
I bet he didn't look into Java. Java (at least) allows and enforces that. A method will only throw an exception if declares to do so. A caller is forced to provide appropriate handlers or to declare it throws the exceptions not handled at its level. If a method can throw A, B or C but gets D during its execution, it has to in some way map D to either A, B or C (or not throw an exception at all).
Of course, I am talking here about checked exceptions. Unchecked exceptions are supposed to represent *bugs*, and nobody should be trying to capture those.
The sad thing is that even seasoned Java programmers do not understand how to write code w.r.t. exception handling. And beginners are usually turned off by the verbosity required by exception handling, so it is usual to see code where people capture (because they are forced by the language) and ignore exceptions (because they are too lazy and/or stupid to understand the consequences).
Kylix (http://www.borland.com/kylix/) is Borland's IDE for Object Pascal and C++ development for Linux. They even have an Open Edition, which is free but requires the code developed with it to be GPL'd. They have enterprise-level offerings too.