develooper Front page | perl.perl5.porters | Postings from February 2012

Re: [perl #109408] Documentation that refers to Perl 5 as new

Thread Previous | Thread Next
Tom Christiansen
February 1, 2012 16:49
Re: [perl #109408] Documentation that refers to Perl 5 as new
Message ID:
>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<>, 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.


> =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.


  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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About