Jenda Krynicky wrote:
> From: Rob Dixon <[EMAIL PROTECTED]>
>> Jenda Krynicky wrote:
>>> From: "Dr.Ruud" <[EMAIL PROTECTED]>
>>>> "Jenda Krynicky" schreef:
>>>>> Rob Dixon:
>>>>>>
>>>>>> local $" = ',';
>>>>>> print "@array\n";
>>>>>
>>>>> print join(',', @array), "\n";
>>>>>
>>>> is much cleaner and safer. Leave $" alone.
>>>> I don't agree. It is totally fine to use a local-ed $", if it is inside
>>>> a minimal block.
>>>
>>> Is it? What if the array you're gonna print is tie()d? Maybe it is
>>> not now, but what if it becomes later? To share the array between
>>> threads/processes, to store it on disk, to ...
>>>
>>> If there was no simple and clear way to print the array with a
>>> specific delimiter, I'd say go ahead. But there is. A way that's much
>>> easier to understand. Without having to know about an obscure builtin
>>> variable that affects the way arrays are interpolated into strings.
>> A program with arrays that are tied in one place and not in another has
>> bigger
>> problems than this anyway.
>
> I'm not talking about the program having one array tied and not tied
> in various places. I'm talking about a program that evolves so that
> an array that wasn't tied in the first version, is tied in a later
> one. Because it grew too big to fit in memory, because you started
> using several threads/processes, because ....
>
>> But I don't see a problem with using $" with tied
>> arrays, unless the tied class happens to overload stringification.
>
> Nope. Unless the tied class interpolates an array into a string
> expecting to get the elements separated by spaces somewhere in the
> methods invoked by reading the whole array. Or any of the functions
> used in the methods does.
Ah I see. Because the tied class's FETCH method inherits the state of $"
It's something I hadn't thought of. But I don't buy it, because in this instance
I reckon it's for the module to protect against mishaps rather than being the
calling code's responsibility, becuase:
- $" applies specifically to arrays
- It's not unlikely to have been set in exactly the context that I wrote about
- It's very unlikely to be of any use in a tied class FETCH method
>> print join(',', @array), "\n";
>>
>> is a lot noisier and IMO clumsier than
>>
>> {
>> local $" = ',';
>> print "@array\n";
>> }
>>
>> and after all, even if you don't know what $" does it's very simple to look
>> it
>> up and also easy to remember.
>
> 31 characters with no special variables vs. at least 42 chars with
> one special variable affecting another statement?
Character count has less bearing on noise than pattern and uniformity.
PLEEEEEEEEEEEEEEASE
is easier to read than
VBGQ
> "Print the @array joined by commas and a newline." vs "Start a block.
> In this block the items of any array interpolated into a string are
> to be separated by commas. Now print the @array interpolated into a
> string (viz above) followed by a newline. And now please forget we
> changed the way arrays are interpolated in string."
That is just silly. You know very well that I could provide an even
longer-winded description of your code.
> Sure you can look up $", but why? The join() is clear without looking
> anything up.
So I presume you also advocate keeping an independent input line count instead
of using $.? It would certainly be clearer in the same sense.
> And assuming Perl 5.10 we might even be comparing
>
> say join(',', @array);
>
> vs
>
> {
> local $" = ',';
> say "@array";
> }
>
> I wonder how long would it take before someone decides that the
> quotes are not needed and changes that to
>
> {
> local $" = ',';
> say @array;
> }
Again, that is just silly. "@array" is different from @array regardless of the
use of $".
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
