Bugzilla Talk:Languages: Difference between revisions

some Perl clarifications
(→‎On Perl5 cons: removed troll)
(some Perl clarifications)
Line 22: Line 22:
*** Well, it'd be nice to be able to enforce that the argument was a particular class, or be able to enforce that a reference is an arrayref or hashref without having to do that manually. -mkanat
*** Well, it'd be nice to be able to enforce that the argument was a particular class, or be able to enforce that a reference is an arrayref or hashref without having to do that manually. -mkanat
**** There are signatures for limited checking, but it's best to validate parameters properly (plenty of ways to do this from very simple to very powerful on CPAN or manually) instead of just assuming that because something is 'a string' that it's ok. -ajt
**** There are signatures for limited checking, but it's best to validate parameters properly (plenty of ways to do this from very simple to very powerful on CPAN or manually) instead of just assuming that because something is 'a string' that it's ok. -ajt
**** See for example the 'autobox' module on CPAN (http://search.cpan.org/dist/autobox) that allows you to call $foo->isa('Class') on any scalar. -phaylon
** Some parameter check is available. Or use Moose, it can check even better that many languages can.
** Some parameter check is available. Or use Moose, it can check even better that many languages can.
* <tt>$$foo[1]</tt> and <tt>$foo->[1]</tt> mean the same thing.
* <tt>$$foo[1]</tt> and <tt>$foo->[1]</tt> mean the same thing.
Line 46: Line 47:
**** There is no reason for it not to work under mod_perl, that question makes me think you don't understand how mod_perl works - ajt
**** There is no reason for it not to work under mod_perl, that question makes me think you don't understand how mod_perl works - ajt
**** Private methods aren't really required in Perl very often at all.
**** Private methods aren't really required in Perl very often at all.
**** It is more intuitive when you call the method as a method, and not as a code reference: sub foo { my ($self) = @_; $self->$private_method(@args) }


** qq[] is a string (as is qq{}, etc.), q[] is a string, though qw() is an array.
** qq[] is a string (as is qq{}, etc.), q[] is a string, though qw() is an array.
Line 53: Line 55:
** The conversions from one type to another can sometimes be horrendous to read. Eg: [keys %{ @{ $var } }].
** The conversions from one type to another can sometimes be horrendous to read. Eg: [keys %{ @{ $var } }].
***  ITYM [ keys %{@$var} ], compare that to dereferencing in C or C++.
***  ITYM [ keys %{@$var} ], compare that to dereferencing in C or C++.
*** What should this do? If $var contains an array reference containing only a single hash reference, that would store you the keys of that in an anonymous array reference. That's not a type conversion, and I surely hope you don't teach that, since I've never had to use such a construct in Perl. That type conversion above is really two "type conversions" (dereferencing), a function call, and a creation of a new anonymous reference.
** $$foo[1] and $foo->[1] mean the same thing.
** $$foo[1] and $foo->[1] mean the same thing.
*** so only use the latter, it's clearer
*** so only use the latter, it's clearer
Line 65: Line 68:
** That Perl doesn't really have a class system, it just has a package system with @ISA or "use base," "bless," and SUPER::.
** That Perl doesn't really have a class system, it just has a package system with @ISA or "use base," "bless," and SUPER::.
*** FUD. It does have a class system, it's not pure, you don't like it, I do, I also like C++ class system, they are different, and that is good.
*** FUD. It does have a class system, it's not pure, you don't like it, I do, I also like C++ class system, they are different, and that is good.
*** This also gives possibility to use Moose to get some higher level OO, but still fall back to lower level when it's needed, cleaner, or more maintainable. That's a pro in my opinion. -phaylon
** That "my ($var) = @_" will get you the first item of the array, but "my $var = @_" will get you a number.
** That "my ($var) = @_" will get you the first item of the array, but "my $var = @_" will get you a number.
*** yes. learn about context. it's not rocket science - anybody finding this hard would have a terrible time with a strictly typed language.
*** yes. learn about context. it's not rocket science - anybody finding this hard would have a terrible time with a strictly typed language.
Line 70: Line 74:
*** Sorry, poor programming in your code not perl.
*** Sorry, poor programming in your code not perl.
*** Any Perl framework will have other methods
*** Any Perl framework will have other methods
** Multiple Inheritance can be problematic in extreme edge cases.
*** Easy then: Don't use MI if you're not suited to it or it doesn't fit the project. Use single inheritance, or roles, or mixins, or traits. It's all available.
** The fact that %var is a () (which is also the array notation) but {} is $var.
*** () isn't the array notation. It's a list. my @array = (1, 2, 3); stores a list into an array. The only array notation is [], for array references. So my $foo = [1, 2, 3] is just a short version of my @foo = (1, 2, 3); my $foo = \@foo; perlfaq4 elaborates on this in "What is the difference between a list and an array." -phaylon
** That is, you can't really do %hash = (key1 => $cgi->param('unset_param'), key2 => 'something'), because then you'll actually just have an invalid hash.
*** No problem there. You just need to know what contexts are and read the documentation for the module you're using. Or simply enforce scalar context.


== On Python cons ==
== On Python cons ==
2

edits