[Os-project-managers] ticket 14 - question about programming style

[Jun Ma]

>1. I can declare the instance as a global variable. I don`t like to do that.
This is actually quite popular in many of our software projects, as it's clean and simple. It should be simple for logging. Logging should be as simple as cout (C++) or System.out.println (Java), no need to instantiate anything or at most instantiate the logger (osoutput)  once.In as sense, the basic print statement like cout or in java System.out.println *is* a global singleton. No need to worry about thread safety as its just outputting.
>2. I can set up a namespace, so that the variable is visible from 
everywhere within the namespace. This is what Andreas does in Ipopt, 
but I read that it is frowned upon, essentially for the same reason 
that global variables are deprecated.

This is actually the default behavior of log4j in java. Basically in the beginning of each class you instantiate a logger. And log4j will make sure that there will be one and only only logger instance for each class. That is no matter how many instances of a particular class, there one be one logger (osoutput) instance. The reason: no need for more than one each class. In fact you can (as in 1 above) just have 1 global logger.The pro: you naturally log4j can use the package (or namespace) as a category and you can configure output behavior or each category; no extra effort. The con: you always will have one logger instantiate line in the beginning of each class.

>3. I can pass the instance as an extra argument to all methods that 
use output (which is basically every routine we have ever written). As 
far as I can see, this is clean, but it is cumbersome, and it blows 
the API sky-high.This is cumbersome for sure, but might worth it. The reason is because there is a fundamental difference between our osoutput and general logger use. General logger will almost always have a static (i.e. pre-compile) property file which sets the behavior of logging or outputting. Users don't change the logging/outputting behavior at run time. In fact logging methods are usually private or in the code, rather than exposed as a public api methods for user to invoke. 
In our case, user can during run time feed the logging behavior input like logging level etc., so 3 actually in my opinion fits our intended design the best. 
Again, we can talk tomorrow.
Jun
> Date: Mon, 26 Nov 2012 11:26:16 -0400
> From: Horand.Gassmann at dal.ca
> To: os-project-managers at list.coin-or.org
> Subject: Re: [Os-project-managers] ticket 14 - question about programming style
> 
> Horand Gassmann <Horand.Gassmann at DAL.CA> wrote:
> 
> > Kipp Martin <kmartin at chicagobooth.edu> wrote:
> >
> >> Hi Gus:
> >>
> >> I don't see a good solution right now.  I think the problem with  
> >> solution 1 is that it makes the code no longer thread safe (I don't  
> >> really understand thread safe, but I do know it important).  I  
> >> don't much about the namespace idea. I did not know this was  
> >> frowned on.
> >
> > It's the same issue about thread-safety. <parrot> To implement  
> > singletons in a thread-safe way, you need double-checking locks, and  
> > from what I can tell, those are platform-dependent. </parrot>
> 
> This paper talks about the issues quite clearly:
> 
> http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
> 
> _______________________________________________
> Os-project-managers mailing list
> Os-project-managers at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/os-project-managers
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/os-project-managers/attachments/20121127/4cb4797a/attachment.html>