TclOO Logging Mixin

I wrote this code (below) trying to figure out more about TclOO mixin classes.

a. is there a more direct way to write the concrete class name from the mixin constructor?

> set concls [lindex [self call] 0 end end-1]

b. is there a way to simplify the mixin class using self requiring no additional calls (e.g. init) other than mixin (as below) when using it? (cross checked with https://stackoverflow.com/questions/50352363/tcloo-class-logger-mixin , not clear)

> mixin ::demo::utils::LoggingMixin

package require TclOO
package require try
package require logger

namespace eval ::demo::utils {}
namespace eval ::demo::naming {}

::oo::class create ::demo::utils::LoggingMixin {
    variable log
    
    constructor {args} {
        set concls [lindex [self call] 0 end end-1]
        try {
            set log [::logger::servicecmd $concls]
        } trap {LOGGER NO_SUCH_SERVICE} {} {
            set log [::logger::init $concls]
        }

        # check for next
        if {[llength [self next]] > 0} {
            next {*}$args
        }
    }
}

::oo::class create ::demo::naming::GenericNaming {
    mixin ::demo::utils::LoggingMixin
    
    variable log
    
    constructor {args} {
        ${log}::info "hello world"
    }
}

::oo::class create ::demo::naming::NewNaming {
    mixin ::demo::utils::LoggingMixin
    
    variable log
    
    constructor {args} {
        ${log}::info "new world"
    }

}


::demo::naming::GenericNaming new

::demo::naming::NewNaming new

expected output:

$ tclsh ./mixin.tcl  
[Sun Jun 04 21:39:22 BST 2023] [::demo::naming::GenericNaming] [info] 'hello world'
[Sun Jun 04 21:39:22 BST 2023] [::demo::naming::NewNaming] [info] 'new world'

To get the class of the object being created, it is sufficient to do this in the constructor:

set concls [info object class [self]]

You don't need to pick through the arguments (good, as that's more error-prone when there are complex forwardings in place or new and/or create have been overridden).

Tcl 8.6 doesn't need you to package require TclOO or package require try; both are built-in features these days.

I'd be inclined to set up the logging mixin like this:

oo::class create ::demo::utils::LoggingMixin {
    variable log
    
    constructor {args} {
        set concls [info object class [self]]
        try {
            set log [::logger::servicecmd $concls]
        } trap {LOGGER NO_SUCH_SERVICE} {} {
            set log [::logger::init $concls]
        }
        next {*}$args
    }

    # TODO: Add methods for other wanted logging levels
    method LogInfo args {
        tailcall ${log}::info {*}$args
    }
}

Because then the subclass could be just this:

oo::class create LoggingDemo {
    mixin ::demo::utils::LoggingMixin
    constructor {args} {
        my LogInfo "new world"
    }
}

Or I might even make some procedures to improve the syntax further:

    constructor {args} {
        set concls [info object class [self]]
        try {
            set log [::logger::servicecmd $concls]
        } trap {LOGGER NO_SUCH_SERVICE} {} {
            set log [::logger::init $concls]
        }
        proc logInfo args {
            variable log; # Need to be explicit with this
            tailcall ${log}::info {*}$args
        }
        next {*}$args
    }

Another approach is to make the mixin provide logging methods that are self-initializing:

oo::class create ::demo::utils::LoggingMixin {
    variable LoggingMixinLog
    
    method GetLog {level} {
        if {![info exist LoggingMixinLog]} {
            set concls [info object class [self]]
            try {
                set LoggingMixinLog [::logger::servicecmd $concls]
            } trap {LOGGER NO_SUCH_SERVICE} {} {
                set LoggingMixinLog [::logger::init $concls]
            }
        }
        return ${LoggingMixinLog}::$level
    }

    method LogInfo args {
        tailcall [my GetLog info] {*}$args
    }
}

oo::class create LoggingDemo {
    mixin ::demo::utils::LoggingMixin
    constructor {args} {
        my LogInfo "new world"
    }
}

That has the advantage of supporting mixing into objects or classes after the fact.

If you make logging wrappers, calling them with either tailcall or uplevel 1 is advisable so that the current stack frame is the one that wants to make the log entry, not the little proxy helper method/procedure.