R7482 - in rt/branches/3.7-EXPERIMENTAL:

RT Developers
1

Author: ruz
Date: Mon Apr 9 17:48:37 2007
New Revision: 7482

Modified:
rt/branches/3.7-EXPERIMENTAL/ (props changed)
rt/branches/3.7-EXPERIMENTAL/lib/RT/Interface/Email.pm

Log:
r4913@cubic-pc: cubic | 2007-04-06 16:37:26 +0400

  • force scalar context

why is scalar context important there? (It looks redundant and
iwthout a comment, someone is likely to ‘fix’ it later)

PGP.sig (186 Bytes)

2

RT->Config->Get returns different things in scalar and array contexts,
for scalar options it’s not that important, however for arrays and
hash it’s. Especially when you use (… xxx => RT->Config->Get, …)
as perl’s ‘=>’ op doesn’t change context of the right hand argument to
scalar.
It’s also important for options that have no default value(no default
in etc/RT_Config.pm). If you don’t force scalar context then you’ll
get empty list as result and all your named args will be messed up.
For example (arg1 => 1, arg2 => RT->Config->Get(‘OptionDoesNotExist’),
arg3 => 3) will result in (arg1, 1, arg2, arg3, 3). Or (arg1 => 1,
arg2 => RT->Config->Get(‘ArrayOption’), arg3 => 3) will result in
(arg1, 1, arg2, ‘element of option’, ‘another_one’…, arg3, 3).

In the case of the rtname option it’s not important as it’s mandatory
and has default value in the config, so I can revert this change, it’s
sort of random change during debugging of a bug.

Also, I can add extended description of Get with examples to the pod.On 4/10/07, Jesse Vincent jesse@bestpractical.com wrote:

On Apr 9, 2007, at 5:48 PM, ruz@bestpractical.com wrote:

Author: ruz
Date: Mon Apr 9 17:48:37 2007
New Revision: 7482

Modified:
rt/branches/3.7-EXPERIMENTAL/ (props changed)
rt/branches/3.7-EXPERIMENTAL/lib/RT/Interface/Email.pm

Log:
r4913@cubic-pc: cubic | 2007-04-06 16:37:26 +0400

  • force scalar context

why is scalar context important there? (It looks redundant and
iwthout a comment, someone is likely to ‘fix’ it later)

Modified: rt/branches/3.7-EXPERIMENTAL/lib/RT/Interface/Email.pm

========
— rt/branches/3.7-EXPERIMENTAL/lib/RT/Interface/Email.pm (original)
+++ rt/branches/3.7-EXPERIMENTAL/lib/RT/Interface/Email.pm Mon Apr
9 17:48:37 2007
@@ -270,6 +270,7 @@
level => $args{‘LogLevel’},
message => $args{‘Explanation’}
) if $args{‘LogLevel’};
+
my $entity = MIME::Entity->build(
Type => “multipart/mixed”,
From => $args{‘From’},
@@ -277,7 +278,7 @@
To => $args{‘To’},
Subject => $args{‘Subject’},
Precedence => ‘bulk’,

  •    'X-RT-Loop-Prevention' => RT->Config->Get('rtname'),

  •    'X-RT-Loop-Prevention' => scalar RT->Config->Get('rtname'),
   'In-Reply-To:'         => $args{'MIMEObj'} ? $args

{‘MIMEObj’}->head->get(‘Message-Id’) : undef,
);

Rt-commit mailing list
Rt-commit@lists.bestpractical.com
rt-commit Info Page

List info: The rt-devel Archives

Best regards, Ruslan.

3

Ruslan Zakirov wrote:

RT->Config->Get returns different things in scalar and array contexts,
for scalar options it’s not that important, however for arrays and
hash it’s. Especially when you use (… xxx => RT->Config->Get, …)
as perl’s ‘=>’ op doesn’t change context of the right hand argument to
scalar.
It’s also important for options that have no default value(no default
in etc/RT_Config.pm). If you don’t force scalar context then you’ll
get empty list as result and all your named args will be messed up.
For example (arg1 => 1, arg2 => RT->Config->Get(‘OptionDoesNotExist’),
arg3 => 3) will result in (arg1, 1, arg2, arg3, 3). Or (arg1 => 1,
arg2 => RT->Config->Get(‘ArrayOption’), arg3 => 3) will result in
(arg1, 1, arg2, ‘element of option’, ‘another_one’…, arg3, 3).

In the case of the rtname option it’s not important as it’s mandatory
and has default value in the config, so I can revert this change, it’s
sort of random change during debugging of a bug.

Also, I can add extended description of Get with examples to the pod.

Both of those sound like good plans.

4

DoneOn 4/18/07, Jesse Vincent jesse@bestpractical.com wrote:

Ruslan Zakirov wrote:

RT->Config->Get returns different things in scalar and array contexts,
for scalar options it’s not that important, however for arrays and
hash it’s. Especially when you use (… xxx => RT->Config->Get, …)
as perl’s ‘=>’ op doesn’t change context of the right hand argument to
scalar.
It’s also important for options that have no default value(no default
in etc/RT_Config.pm). If you don’t force scalar context then you’ll
get empty list as result and all your named args will be messed up.
For example (arg1 => 1, arg2 => RT->Config->Get(‘OptionDoesNotExist’),
arg3 => 3) will result in (arg1, 1, arg2, arg3, 3). Or (arg1 => 1,
arg2 => RT->Config->Get(‘ArrayOption’), arg3 => 3) will result in
(arg1, 1, arg2, ‘element of option’, ‘another_one’…, arg3, 3).

In the case of the rtname option it’s not important as it’s mandatory
and has default value in the config, so I can revert this change, it’s
sort of random change during debugging of a bug.

Also, I can add extended description of Get with examples to the pod.

Both of those sound like good plans.

Best regards, Ruslan.