Re: [Perl-workflow-devel] Moose?

[Alejandro I. <ai...@p2...>]

On Sun, Jan 30, 2011 at 6:52 PM, Andrew O'Brien <an...@or...> wrote:
> Hi Alejandro,
>
>>
>> I do vote +1 however to port to Moose, though OT to this thread ;-)
>
> Why on earth would you slow down all applications that rely on Workflow, not to mention adding the dependencies, like this?
>

Hi Andrew,

I could agree on the dependencies but I don't think there would be a
performance penalty at all, or only marginal at best, and it's mostly
a compile-time issue. Workflow engines should be long running
instances anyway with a per-request light-weight object factory, much
like the current code, so I don't think this would really be an issue,
IMHO.

Workflow's code is meant to be extended and there are many things that
would benefit from a more formal object protocol. For example the WF
fields could greatly benefit from a type system (Int, Num, Str, etc.),
roles, etc. It would also point the code towards Perl 6.

> If there is a refactoring in the works

No, there is no refactoring in the works AFAIK. It was just a thought,
to make the WF code easier to extend and maintain.

>then perhaps look at whatever compatible module du jour (Mouse? Or was there another newer one?) that provides the most >common features without 90% of the bloat.
>

Don't get biased by sparse comments here and there around Moose. It's
true that Moose is a heavy-weight complete object system but people
that are creating this FUD around Moose fail to mention namespace
autocleaning, non-mutability and other best practicesto keep the final
code running lean. There is a factual penalty on compile time,
however, and even so, in complex code it's really not that noticeable.

A perfect example is Catalyst which was ported to Moose a while back
and I have not personally seen any performance penalty, and we do heck
of a lot of development in Catalyst. Even for development, the compile
time for re-starting a Catalyst app before or after Moose didn't
really change that much, and definitively we haven't seen _any_
performance penalties in run-time.

On the contrary, the Cat Moose code allows for more easy creation and
maintenance of the Model layer, so you can more easily design the
model classes as long-running "instances" that create light-weight
per-request objects. And supposing there is in fact a marginal
run-time performance penalty, I think the extensibility and
maintainability would greatly out-weight it, again IMHO.

In any case, it wouldn't affect current users of WF except for the
fact that they could more easily extend and maintain their adaptations
of, and help in the publications of extensions like Context
persistence onto the CPAN more easily. And finally, the WF code in
general is aging and perhaps a good time to re-evaluate some code
design and architectural choices as well. Maybe an HTTP/Resource based
approach with JSON data ala CouchDB ? Could be a branch/fork as well.

--
Alejandro

> Just a thought.
>
> Cheers,
>
> Andrew
>
>
>