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
