as a base for this discussion:
overview over language-specific features introduces since PHP 5.3
PHP 5.3
- namespaces
- late static binding (static::)
- goto (yay)
- closures
- nowdocs
- const outside of classes
- terniary operator shorthand ?:
- nested exceptions
PHP 5.4
- traits
- short array syntax ([])
- function array dereferencing (func()[0])
- closures can use $this
- class member access on instantiation (new Foo)->bar()
- "dynamic" static method calls Class::{expr}()
- binary number format 0b001100
PHP 5.5
- yield keyword
- finally keyword for try-catch blocks
- foreach supports list
- array and string literal dereferening (echo [1,2,3][0], echo '123'[0])
- class name resolution using ::class
- integrated OPcache extension
- foreach supports non-scalar keys
PHP 5.6
- constant expressions (const three = two + 1)
- variadic functions (function variadic($param, ...$optional_params))
- argument unpacking (function any($param, $param2){}; any(1, ...$params)
- ** exponentiation operator
- use function and use const
On 02/25/2015 10:00 AM, Christian Grobmeier wrote:
Actually the question is, if we should go with PHP 5.3 or just take the
fancy features of 5.6.
Some might argue "we don't need all features necessarily". Thats often
an argument in Java land, and people stick with Java 5 or 6 in some
frameworks because it can be done without.
I think good and fancy code also attracts committers. Esp in the PHP
world I assume that nicely written, modern PHP based on 5.6 would
attract more people than working code with 5.3.
5.3 is already phasing out in addition, and I think migrations are done
quicker than in the Java world.
whats your ideas here?
On Wed, Feb 25, 2015, at 09:34, Michel Feldheim wrote:
Thanks guys for clarifying.
Agree, PSR-4 autoloading would be another improvement.
Introducing Namespaces increases the PHP requirement from currently
>=5.2.7 (according to the composer.json) to >=5.3.0
On 02/24/2015 07:34 PM, Christian Grobmeier wrote:
Hey all,
On Tue, Feb 24, 2015, at 19:22, Sven Rautenberg wrote:
You must implement the interface as it is, or you wouldn't be
implementing it.
+1. Either implementing it, or not. As Sven said, 3.x can break bc. We
use semver.org.
Offering PSR-3 is incompatible. Releasing version 3.0 signals
"incompatible to 2.x" all over it. Note that the log levels defined in
the RFC PSR-3 is based on are partly incompatible to the ones of Log4PHP
2.x. So this will be incompatible in any case.
The only chance would be to keep the old interface for conveniance but
make them some kind of bridge to the new interfaces. Not sure if it is
worth the effort though.
BTW: Would be nice to use PSR-4 autoloading as well - which means using
namespaces. Which is also incompatible.
Absolutely. There is an issue open for that, and I think Ivan already
created a branch working this task. However Ivan is currently pretty
busy, so PRs are surely welcome.
My personal taste is to make use of all the fancy new things PHP has to
offer for the moment. They will deprecate soon enough. And if we do a
3.x then make it proper and shiny.
Cheers Christian
On 24. Februar 2015 15:41:57 MEZ, Michel Feldheim
<[email protected]> wrote:
Hey guys,
working on
https://issues.apache.org/jira/browse/LOG4PHP-211?jql=project%20%3D%20LOG4PHP
PSR-3 interface implementation
(https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md#13-context)
PSR-3 defines a common interface for logging libraries.
If implementing this interface, the usage of log4php would slightly
change.
Currently you can pass any throwable as argument into every log
method
https://github.com/apache/logging-log4php/blob/master/src/main/php/Logger.php#L171
e.g.$logger->warn('message', $exception);
the PSR-3 interface enforces $context array or null as parameter
https://github.com/php-fig/log/blob/master/Psr/Log/LoggerInterface.php#L113
e.g.$logger->warn('message {placeholder}, array('placeholder' =>
'senseless', 'exception' => $exception));
I could go the strict way and implement their interface, then 3.0.0
would not be downward compatible or slightly modify the interface to
not enforce type array
What's your preference?
Regards,
Sven
