On Tue, 22 May 2001, Craig Barratt wrote: > > The problem is with TT automatically deciding what's an array and what's a > > scalar. CGI.pm returns a single array element when you have a single > > checkbox in a group checked, and two array elements when there are two > > boxes checked. TT will try to do the right thing and create a scalar in > > the first case, but a list in the second. I've no way to force a list > > context in TT for lvalue. The code will talk better than I. This code > > tries to show that Perl does the right thing, whereas TT doesn't: > > Yes, this is a problem. There are two seperate issues: > > 1) TT2 always calls plugin functions in array context. > 2) Single element arrays get demoted to scalars. > > Your specific problem relates to (2) more than (1). To solve (1) it > might be nice if there was some syntax that allowed you to specify > whether plugins are called in scalar or array context. > > The scalar demotion would be less of a problem if most of the scalar > and array ops correctly worked with both scalar and array arguments. > For example, I should be able to push a scalar to get a two element > array, and I should be able to join a scalar as if it was a one element > array. (I think this would be a pretty easy addition to Stash.pm. > Also, it would be nice if the array ops worked on Iterators, but > that's another topic.) > > Here is a workaround. You can add two new ops "scalar" and "array" > that convert between scalar and array types. "array" promotes a > scalar to a one element array, and is a no-op on an array. Conversely, > "scalar" takes the first element of an array and is a no-op on a > scalar. > > Here's your example again. [ a fixed code example was snipped ]
That's exactly what I've asked for, Craig. Thanks a lot! Now what are the chances that this kind of functionality gets folded into the TT core? The thing is, we are producing open source Application Development Toolkit (ADT) and while having this kind of patches in closed source products is fine, I really don't want to introduce this kind of patches in the open source product. It'll be much easier to tell people to read TT documentation to learn how templates work, than saying that and supplying extra documentation for the patches we apply. Believe me, it's not the lazy in me that wants that, but I'm trying to think forward and keep components we rely on independent from the glue code that we write. In addition I think that it's very essential for TT to be able to explicitly define contexts, since it works with Perl which is heavily depending on that feature. Not having this context makes all the functions that use wantarray() half usable and unintuitive. Of course your patch provides this feature, but are there any reasons for not having these in core? Thanks! _____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
