ernado commented on a change in pull request #323: URL: https://github.com/apache/pulsar-client-go/pull/323#discussion_r474474194
########## File path: pulsar/log/logger.go ########## @@ -0,0 +1,57 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +package log + +// Logger and Entry interfaces are inspired by sirupsen/logrus + +// Fields type, used to pass to `WithFields`. +type Fields map[string]interface{} + +// Logger describes the interface that must be implemeted by all loggers. +type Logger interface { + SubLogger(fields Fields) Logger + + WithFields(fields Fields) Entry + WithField(name string, value interface{}) Entry + + Debug(args ...interface{}) + Info(args ...interface{}) + Warn(args ...interface{}) + Error(args ...interface{}) + + Debugf(format string, args ...interface{}) + Infof(format string, args ...interface{}) + Warnf(format string, args ...interface{}) + Errorf(format string, args ...interface{}) +} + +// Entry describes the interface for the logger entry. +type Entry interface { Review comment: Agree, but it seems like logrus approach with fields (`map[string]interface{}`) will reduce benefits from pooling. Moreover, attempt to abstract logging is already limits performance optimizations due to usage of interfaces instead of structures, so I'm not sure that having both interfaces will simplify something performance-related. There is another point: we are pre-v1, so it is OK to break backward compatibility at some point. If one decide to switch to zap or zerolog and employ it's performance benefits, they will be forced to change interfaces (but I still think that it is nearly impossible to create both abstracted and performant logger interfaces) ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
