RE: [aus-dotnet] Whidbey Beta2 and the "Go Live"

[Sean Malloy]

> Thanks for the idea etc.
> Serialize is not the only type of processing I do on logging 
> a message etc.
> Think about it. Basically any string operation you do, 
> constants and all,
> can be done there.
> The point it to make the calling logging code simpler, not 
> more complex and
> to have less of it.
> 
> I don't know of a nice generic way to do what you've shown. 
> Again, the goal
> is simple client code. ==> Simpler than what it currently is.
> 
> I'm open to any ideas.
> Thanks

IMO, custom domain objects for handling your logging requirements is a
simpler solution than having some Lazy Evaluation attributes tacked on to
the runtime.

Alternatively you could implement ToString() on your domain object, which
internally just returns SerializeToXML(), and use a single generic Raise
function:

public function Raise (myEventSource as EventSource, eventPublishLogLevel
    as Integer, msgToLog as Object)
    If (eventPublishLogLevel > applicationLogLevel) And
        EventSource.Application.IsEnabledForType(GetType(TraceMessageEvent))
Then
           actualLog(myEventSource, eventPublishLogLevel,
msgToLog.ToString())
    End If
end function

That way you could pass in a String, or a custom object which overrides
ToString()

Or perhaps you could use Delegates. Even better with C# 2.0 and anonymous
delegates, which give you more room to play similar to Smalltalk blocks

Either way, the use of attributes to add functionality like lazy
initialisation or execution seems abhorrent to me. I guess I must be the
only person who feels this way.

Regards,

Sean
_________________
You are a part of the Australian "dotnet" mailing list.
To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet Your Name" in the body of the email to: imailsrv@xxxxxxxxxxx
List managed by: http://www.stanski.com