>> AFAIK components don't equal subs directly, so doing @q = $m->comp('foo')
>> isn't the same as @q = foo();
>
>Actually, that should be equivalent.
Absolutely.
In fact calling $m->comp('SELF:want) from within a perl block does
the right thing, that is does not make Perl think that wantarray is
in effect.
It's only <% $m->comp('foo') %> where things go awry.
The bug appears to be in how $m->print works. But I don't really get
the whole stack/buffer thing.
A cheap kludgy fix would be to insert a dummy var into the code on
compile but that would obviously be insane...
>OTOH, returning values from
>components is probably a very bad idea.
>
>If a component is generating output, it should not _also_ return
>something.
Sorry. This was the simplest code I could think to show the problem.
It is not dependent on there being output. I wasn't suggesting that
you would want to do it, rather showing that those snippets were not
equivalent.
>If it's only returning something, it should be a subroutine in
>a module anyway.
I think that that is not your call. I think it is perfectly
legitimate to use Mason components instead of, or alongside modules
to return stuff.
It's precisely for that ability that I still use Mason.
Of course, if you want us to all piss off to Catalyst and
Template::Toolkit, that is your prerogative ;)
Alternatively annotate all references in the manual to say that you
can return values but that you shouldn't ;)
>> I've never had a need to do this, and I'd evaluate your structure if you
>> feel you do.
>
>Indeed.
Is wantarray a legitimate perl function (name aside) or not?
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
