Front page | perl.perl5.porters |
Postings from February 2012
>On Wed Feb 01 12:30:58 2012, sprout wrote:
> On the other hand, I’ve just thought of a few things, the first one
> being a real problem that I’ve seen in Perl code.
>
> I don’t know whether Tom would want to include this.
Is this a Javascript section? Really? Cool!
I probably won't be able to squeeze it in. We're at page-break time.
> =item *
>
> C<? :> has higher precedence than assignment. In JavaScript, one can
> write:
>
> condition ? do_something() : variable = 3
>
> and the variable is only assigned if the condition is false. In Perl, you
> need parentheses:
>
> $condition ? do_something() : ($variable = 3);
>
> Or just use C<if>.
The ?: precedence thing is an oddity. I feel like I remember
this changing between C and C++, but no longer recall the details.
> =item *
>
> Perl requires semicolons to separate statements.
> =item *
>
> Unlike C<for...in>, Perl's C<for> does not allow the left-hand side to
> be an arbitrary expression. It must be a variable:
>
> for my $variable (keys %hash) {
> ...
> }
> =item *
>
> The C<+> unary operator doesn't do anything in Perl. It exists to avoid
> syntactical ambiguities.
s/syntactic\Kal//;
> =item *
>
> One cannot easily add arbitrary properties to an existing object. For a
> publicly-accessible property, make a subclass, and maybe consider
> C<AUTOLOAD>. To associate data with arbitrary objects, see
> L<Hash::Util::FieldHash>.
You mean data members? I don't believe in letting your member
s hang out in public. :) I consider the class a members-only area.
> =item *
>
> An object's members cannot be made accessible as variables.
> The closest Perl equivalent to C<with(object) { method() }> is
> C<for>, which can alias C<$_> to the object:
>
> for ($object) { $_->method; }
A feature, perhaps somewhat disguised, but a feature nonetheless.
Then again, lvaluable methods are kinda variabili(t)ous.
> =item *
>
> Variable declarations only affect code I<after> the
> declaration. You cannot write C<$x = 1; my $x;> and expect the
> first assignment to affect the same variable. It will instead
> assign to an C<$x> declared previously in an outer scope, or to
> a global variable.
Good thing we don't want confuse them with
my $x = 1 + $x;
do we now? :)
> =item *
>
> C<my> variables are scoped to the current block, not to the
> current function. If you write C<{my $x;} $x;>, the second
> C<$x> does not refer to the one declared inside the block.
In general, Perl has *lexical* scope, and indeed, the
scope is the ‘font of all privacy’(⋆) in Perl. Think of
(most) pragmas, for example.
> =item *
>
> The object on which a method is called is passed as one of the
> method's arguments, not as a separate C<this> value.
Not just the object, but any invocant, so classes, too.
The invocant is always unshift()ed onto the arglist.
--tom
PS: Yeah ok, if you can't bring yourself to posh up “the /fɔːnt/ of all
/ˈprɪvəsi/”, you can just say “the source of all /ˈpraɪvəsi/”. :)
Thread Previous
|
Thread Next