Declaration of QQSubQuerySqlNode::GetColumnAlias() should be compatible...
Wed, 12/23/2009 - 16:12
Hi, had a working version of Qcodo and now we are creating another local version to do both refactoring and continue to develop and I get this:
Declaration of QQSubQuerySqlNode::GetColumnAlias() should be compatible with that of QQNode::GetColumnAlias()Can anybody help me start to drill in and figure out what this means and where to look?
Thanks!
When are you getting this error message? On/after code generation?
Which version of QCubed are you running? Also, is your PHP version 5.3?
yeah, should be version 5.3, but let me check, new developer instance...
Is there a dependency on specific .release, not just 5.x? Did a quick scan of the set-up documentation, only said PHP 5....what is the requirement?
There is no dependency on PHP 5.3. On the contrary, PHP 5.3 has been giving us trouble (Zend/PHP broke lots of backward-compatibility with the PHP 5.3 release).
Please answer the rest of the questions from above.
We are using the stable release and it is at code generation...which seems odd...
okay got it fixed....thanks.
Good to hear. I'm curious what caused it - if it's something with the framework, we'd be interested in fixing it.
I actually don't know how it got resolved, I asked the developer to do a clean install and it appeared to work...we'll see, migrating code that was build on qcodo beta 3 and hoping it works....
OK :-) Sounds good, good luck! You shouldn't see any major issues - 1.0 branch of QCubed is perfectly backward-compatible with QCodo. Just in case, we're here to support you - if you need any help, we're a forum post away.
thank you I appreciate it -- we're going deep into qcube land from qcodo so glad to hear it....
You should note that it's a E_STRICT error. It's an important information.
Unavoidable E_STRICT errors like this one are along all the QQNode subclasses' method declarations (and probably subclasses in other parts of the framework).
Code to reproduce:
<?php
class A {
function F($arg1, $arg2) {}
}
class B extends A {
function F($arg1) {}
}
?>
Declaration of method F in class B triggers the E_STRICT error, as method declaration doesn't match exactly the parent one.
Nothin to do, except avoiding the strict mode at all cost. Bad practice, yes... but this is PHP, and the framework makes extensive use of its weaknesses.
Fernando - we are definitely on the same page around E_STRICT. Error messages generated in that mode are valuable; our framework should not be using features that aren't allowed by the E_STRICT mode.
Your statement about "E_STRICT errors like this one are along all the QQNode subclasses' method declarations" is incorrect. I'm running a large application with E_STRICT recently turned on, and besides the few E_STRICT mistakes that we did make (and fix - see Trac for tickets related to this), there are no currently known and unfixed E_STRICT incompatibilities.
If you are aware of any E_STRICT incompatibilities in either 1.1 or 1.0.1 releases, please let us know - we'll fix them!
He's right actually. The QQNode system is riddled with overrides with different function definitions than their parents. I'm completely baffled as to why people aren't seeing E_STRICT errors with these.
Please, think twice before stating other person's proven facts as "incorrect" just because you haven't experienced them.
If you (and plenty of other people) are not seeing those E_STRICT errors is just because you use an earlier version of PHP that still doesn't consider this "uncompatible" method declarations as E_STRICT errors. In a previous message you wrongly assumed that it's not a PHP version-dependant error, but it is.
And in fact this proves that the E_STRICT mode is not always as absolutely useful as you think. It can trick you to think you're applying good practices when in fact you're not. Knowing by first hand how your code is implemented is the only way to apply good practices. The E_STRICT mode may be useful sometimes, but it's never an oracle.
If you're serious when you say "our framework should not be using features that aren't allowed by the E_STRICT mode", prepare to rebuild the entire framework from scratch. You should better relax that PHP purism and know the code you're working with, as the Qcodo/QCubed core makes extensive use of the PHP weaknesses.
We are prepared to rebuild the entire framework if necessary to eliminate any E_STRICT warnings. But there's no need to as of yet, so I'm unsure why you bring that up.
There are a few function definitions that seem like they should trigger E_STRICT warnings, but as far as we can tell, even on the latest version of PHP, they do not.
If you do encounter any E_STRICT warnings in _any_ version of php (5.1 or greater), please let us know. We WILL fix it.
I'm with VexedPanda here. If you have ANY warnings, please let us know (or create a ticket) and we'll fix it, just like with did in the past.
I've just started a project using the 2.0 branch with PHP 5.3, and so far no issues have been found with the PHP version.