Re: Moosifying Test-Run Part 2: Probably Not

Jonathan,

On Jun 2, 2008, at 10:01 AM, Jonathan Swartz wrote:
> On Jun 2, 2008, at 12:24 AM, Shlomi Fish wrote:
>> Yes, but to me it seems that it beats the point of using Moose. If  
>> I'm
>> using Moose, I'd rather have type-checking, so people will know what
>> every class member is.
>
> Is it possible to tell Moose to skip type-checking for particular  
> classes? That way, one could insert the types solely for  
> declarative purposes, or could turn on type-checking only in the  
> development version of an application, or turn off checking for  
> performance critical classes.
>
> The FAQ mentions this will likely be "in the next release", not  
> sure when that was written. :)

No, it has not been written, and I should probably remove that  
comment since it really is not a good idea.

Part of the reason is that it will break all use of coercions, which  
I tend to use heavily myself. Also having a global on/off switch like  
that might be fine for your code, but may cause issues with a 3rd  
party Moose module your using.

Personally I would never use it nor recommend the use of it because  
really I put those type checks in for a reason, and nothing would be  
more frustrating to me then having to debug issues that crop up in  
prod that could have been caught by the type checker. Not to mention  
the fact that then prod and dev would behave differently which is  
also a nightmare for debugging.

There is prior art in removing type information at runtime in  
languages like OCaml, etc. but this is only after the type usage has  
already been verified by the inferencer. Since we don't have type  
inference in Perl/Moose, then this prior art does not apply.

We have attempted to convert the type checks to XS, but there was  
little or no difference in the speed/cost so it got shelved. There  
was also some improvement done on the inlined methods and  
constructors to avoid excess method calls, etc. We have not tried to  
specifically benchmark/profile the type usage and accessors, that may  
prove to be an interesting exercise though, and I would be happy to  
act on any of the issues that might reveal.

Really, I think the best approach is to profile your code and see  
*if* type checking is a hotspot, if it is, then comment out *that*  
type definition only. Your intentions will still be clear to the  
human readers of the code, but your won't have to incur the  
computational cost.

- Stevan