LOG4PHP-211

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

LOG4PHP-211

Michel Feldheim
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?
Reply | Threaded
Open this post in threaded view
|

Re: LOG4PHP-211

Sven Rautenberg
You must implement the interface as it is, or you wouldn't be implementing it.

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.

BTW: Would be nice to use PSR-4 autoloading as well - which means using namespaces. Which is also incompatible.

On 24. Februar 2015 15:41:57 MEZ, Michel Feldheim <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: LOG4PHP-211

Christian grobmeier
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 <[hidden email]> 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
 
Reply | Threaded
Open this post in threaded view
|

Re: LOG4PHP-211

Michel Feldheim
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
>> <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

PHP minimum req for 3.x (was: Re: LOG4PHP-211)

Christian Grobmeier-3
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
> >> <[hidden email]> 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
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: PHP minimum req for 3.x

Michel Feldheim
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
>>>> <[hidden email]> 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
>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: PHP minimum req for 3.x (was: Re: LOG4PHP-211)

Sven Rautenberg
In reply to this post by Christian Grobmeier-3
Drop support for 5.3? Yes. Absolutely. It's unmaintained.

Jump to bleeding edge 5.6? I don't like it because I use 5.5. And I think 5.4 still gets bug fixes, doesn't it?

Making the currently maintained PHP version the minimum requirement sounds like a good guideline.

On 25. Februar 2015 10:00:18 MEZ, Christian Grobmeier <[hidden email]> 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
<[hidden email]> 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





Sven