Martin Kutter via RT wrote:
Show quoted text> <URL:
http://rt.cpan.org/Ticket/Display.html?id=33678 >
>
> Hi Adam,
>
> actually, Class::Std::Fast is just that: After comparing (and
> benchmarking) the inside-out base classes available, ac0v and I found
> that for our usage pattern, Object::InsideOut has no benefits (and not
> Class::Std's simple API), and Moose is a magnitude slower (or two). So
> Andreas - after talking to Damian on YAPC Europe 2007 - built
> Class::Std::Fast. The only reason that it requires Class::Std is that we
> didn't want to rewrite the working code in Class::Std.
>
Because it is such an important module, I would strongly recommend
reversing that particular design decision and merging in the code.
There's a time and a place for cut-and-paste and escaping a dependency
on a massively buggy stale base that could easily break your code if it
ever changes is exactly the sort of place that makes sense.
Show quoted text> Class::Std::Fast has facilities to circumvent both the constructor and
> the accessor/mutator methods for performance reasons, and it allows to
> gather the informations required to build Class::Std::Fast-based objects
> and fill them with data (bypassing the getter/setter methods again) from
> C. While this allows to circumvent the strong encapsulation inside-out
> objects provide, it's nothing that happens by accident (as with hash
> based objects). You have to expect getting burned when playing with
> fire ;-)
>
I'm not entirely sure what you mean here, but wasn't the entire point of
inside-out objects to prevent circumvention?
Otherwise, why not just use simple and lighter blessed hashes.
Show quoted text> Of course Class::Std::Fast could be integrated into SOAP::WSDL - but I'm
> thinking of the opposite direction, like releasing the XML Schema
> implementation as a separate distribution (once it's complete).
>
If you are in control of Class::Std::Fast, then removing the dependency
on Class::Std would be just fine, instead of merging it in entirely.
Adam K
