[Mono-list] Missing Types from corlib

[Nick Drochak]

> Maybe we can go half-n-half. MonoTODO can be an attribute, because as
Miguel 
> said, it is something you come back to clear it when the task is done,
so 
> probably it wonīt go out on "production" code. And so your NUnit
extension 
> would be very welcome. 

Ah.  This sounds very nice.

> But beware of costs for NUnit performance, because 
> probably a whole tree of dependencies would need to be checked for 
> [MonoTODO].
> 
> Ex:
> 
> class ToBeTested
> {
> 
>   public int TestMe(int someValue)
>   {
>     return PrivTestMe(someValue+1);
>   }
> 
>   <MonoTODO("ndrochak@gol.com")>
>   private int PrivTestMe(int someValue)
>   {
>     return 0; // TODO: make the right calculation
>   }
> 
> }
> 
> NUnit has to check ToBeTested.TestMe(), but that depends on 
> PrivTestMe that isnīt OK, Right? Or the programmer has to keep tabs on
those 
> dependencies and propagate the attribute?

I was thinking that MonoTODO would only be used for public methods as a
marker that the method is incomplete. And so, yes, I guess it would be
up to the developer to put the TODO like this:
   [MonoTODO("finish that inner method first")]
   public int TestMe(int someValue)
   {
     return PrivTestMe(someValue+1);
   }
 
   private int PrivTestMe(int someValue)
   {
     return 0; // TODO: make the right calculation
   }

I don't think it's even practical to get Nunit to walk the entire
dependency tree.  Even if we could get it to work, the benefit to the
developer is pretty small.  And so, probably not worth it.

Nick D.