function ini() local llOk llOk = dodefault() this.Addobject("oDmitry", "empty") return m.llOk function ErrorHandler(tnError, tcSys16, tnLineno) = AddProperty(this.oDmitry, "cAlias", Alias()) return dodefault(m.tnError, m.tcSys16, m.tnLineno)over a hook based approach
function ErrorHandler(tnError, tcSys16, tnLineno) local luRet this.Hook_ErrorHandler_Before(m.tnError, m.tcSys16, m.tnLineno) luRet = dodefault(m.tnError, m.tcSys16, m.tnLineno) this.Hook_ErrorHandler_Done(m.tnError, m.tcSys16, m.tnLineno) return m.luRetto a construct where you set specific objects for each hook type or before/done
function ErrorHandler(tnError, tcSys16, tnLineno) local luRet this.oHookBefore.ErrorHandler(m.tnError, m.tcSys16, m.tnLineno) luRet = dodefault(m.tnError, m.tcSys16, m.tnLineno) this.oHookDone.ErrorHandler(m.tnError, m.tcSys16, m.tnLineno) return m.luRetin your specific .Init due to another settings object as factory specifying each class, allowing you more freedom in subclassing/specialising. Yes, last approach IS overenginered on purpose to give you an idea how far you might proceed for problems having much wider application range...
>lcError = lcErrorObj + '.ErrorHandler(error(), sys(16), lineno())'
>
>>lcError = lcErrorObj + '.ErrorHandler(error(), sys(16), lineno(), ALIAS())'
>
>