in reply to list vs array context: odd error message...

To expand a bit on swiftone's point, the construct you have in the first section asks for and receives a side-effect of the split. split always returns a list (a list of one element is still a list). However, your first construct uses split in scalar context. (I presume internally, split doesn't use any sort of wantarray checking.)

To do what split wants and to do what you want, perl has to assign the list results of the split operation to @_, then evaluate @_ in scalar context, giving you the number of elements. You might as well just use m// with your pattern in scalar context.

Your second one works because you do as swiftone recommends, creating an anonymous array out of the split results. That puts split in list context. Next, you dereference the anonymous array, and evaluate that in scalar context. Same results, except that wrapping the split in the reference/dereference stuff fools perl just enough that it doesn't give you the error message.

As for the error message, it means "Try not to do a potentially expensive operation if you're just going to throw away the results."

  • Comment on Re: list vs array context: odd error message...

Replies are listed 'Best First'.
Re: Re: list vs array context: odd error message...
by jynx (Priest) on Dec 16, 2000 at 04:45 UTC
    thank you much,

    As a question though, would there be a time when it would make sense to use split in scalar context (and thus avoid the @_?). Not as if i'm qualified to ask question's on perl's behavior, but if this is deprecated (as diagnostics says) is it going to be replaced by some other behavior?

    jynx

    UPDATE: please disregard this, i apparently wasn't fully reading the above post (but thanx again swiftone for pointing that out)

      1) I can't think of a time you'd use split in a scalar context. See chromatic's post about m//;

      2) The features of splitting to @_ was there to reduce temporary variables. It's deprecated because it encourages trampling on subroutine arguments.