Hi! > PEAR and PECL that work with PHP5.4 out of the box? > At least the core of PEAR that does not throw strict warnings from a stock > install of PHP5.4 as E_STRICT is on.
For PEAR is think it is a wrong list, as for PECL most extensions are maintained by their maintainers, and internals specifically works only on the core. > I think that this is the problem here. "fixing bad code" is simply not a > statement that I recognise! I am not fixing bad code, I am re-writing much of > it > simply because the style is no longer acceptable, or somebody changed a > default You are trying to reframe the same meaning with different words, but the meaning does not change - the code that is no longer acceptable in 5.4 is not acceptable for a reason. Usually the reason is that the code is broken or using PHP in a wrong way - such as silently converting nulls to objects, strings to arrays, arrays to strings, etc. > setting without considering the consequences ( <?= not working in PHP5.3 is > STILL biting as ISP are only upgrading to PHP5.3! ) Err, I'm not sure what you mean - <?= certainly works in 5.3. > I still have not had a proper answer to a question I repeatedly ask. "Please > can > we have some tutorials on how 'strict' styling should be used?" I'm fixing > the > warnings created but I still do not fully understand what I am fixing. The > main I, for one, do not understand what you are asking. If somebody could explain it would be nice. "Strict" warnings are issued when your code is doing something that the designers of the engine consider a bad idea, which in vast majority of cases means a bug. > rework area has been not being able to use '$this' in static functions, even > if > the function checks $this and defaults to the static code internally. Adding Good example. "static" function is called static for a reason, and the reason is it does not belong to an object but to a class, thus it can not and should not have $this. Code that uses $this in a static function is thus broken and needs to be fixed. In overwhelming majority of the code this is a bug. If some code used it as feature, it was a bad idea, and the time of this bad idea is gone now. > 'public/private/protected/static/self ...' and using them in the right places > is > well documented in bits and pieces, but there is no general 'how to' put the > whole together? I suppose someone will want to add traits and the rest to > that, How to put what together? The manual page for static states explicitly: Because static methods are callable without an instance of the object created, the pseudo-variable $this is not available inside the method declared as static. What other howto is needed for this? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
