[
https://issues.apache.org/jira/browse/LOG4J2-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14662652#comment-14662652
]
Gary Gregory edited comment on LOG4J2-599 at 8/7/15 11:35 PM:
--------------------------------------------------------------
My point is that there is no good normal name for such an interface.
In the old MSFT days of COM, they would extend a Foo with a Foo2. I've also
seen FooExt in other code bases.
For example, ICommDlgBrowser3 extends ICommDlgBrowser2 extends ICommDlgBrowser,
see
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776127(v=vs.85).aspx
Another example IFileDialog2 extends IFileDialog, see
https://msdn.microsoft.com/en-us/library/windows/desktop/dd378363(v=vs.85).aspx
Say the goal is to augment the public {{Logger}} API with two features: (1)
Lambdas APIs and (2) APIs that do not force the creation of a temp array when a
log level is disabled. How do we do that and remain binary compatible?
In our case, we first thought "hey these APIs are all lambda related, so let's
add a LambdaLogger interface". I'm saying, if we are going to extend the public
Logger API and remain binary compatible then, yes, we can have a FooLogger
extend Logger but we should put all that we've missing been in there, as in the
2 API sets above.
Then there is no good name, hence the use of numbers.
was (Author: garydgregory):
My point is that there is no good normal name for such an interface.
In the old MSFT days of COM, they would extend a Foo with a Foo2. I've also
seen FooExt in other code bases.
For example, ICommDlgBrowser3 extends ICommDlgBrowser2 extends ICommDlgBrowser,
see
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776127(v=vs.85).aspx
Another example IFileDialog2 extends IFileDialog, see
https://msdn.microsoft.com/en-us/library/windows/desktop/dd378363(v=vs.85).aspx
Say the goal is to augment the public {{Logger}} API with two features: (1)
Lambdas APIs and (2) APIs that do not force the creation of a temp array when a
log level is disabled. How do we do that and remain binary compatible?
In our case, we first thought "hey these APIs are all lambda related, so let's
add a LambdaLogger interface. I'm saying, if we are going to extend the public
Logger API and remain binary compatible then, yes, we can have a FooLogger
extend Logger but we should put all that we've missing been in there, as in the
2 API sets above.
Then there is no good name, hence the use of numbers.
> Support lambda functions (or similar) for log message parameters
> ----------------------------------------------------------------
>
> Key: LOG4J2-599
> URL: https://issues.apache.org/jira/browse/LOG4J2-599
> Project: Log4j 2
> Issue Type: Brainstorming
> Components: Core
> Reporter: Matt Sicker
> Priority: Minor
> Labels: Java8
>
> It would be nice if we could support 0-param lambda functions (or the
> equivalent: interfaces with a single empty-parameter message call), or more
> simply, allow Runnables (or something similar) to be passed which will be
> dynamically executed if the log message is enabled.
> The use case here is that although string construction of the log message is
> a performance issue that is already solved quite well, the problem of adding
> in information to the log message that makes other calculations still needs
> to be wrapped in an if check.
> I'm not sure if it'd be best to just use Runnable, or create a new interface,
> or try to emulate how Java 1.8 lambdas work via an interface with a single
> method defined. The details here would still need to be fleshed out, but I
> think this sort of feature could be rather handy (especially in a Java 1.8+
> environment, or in Groovy/Scala/etc.).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
