Re: why moose

[Илья Рассадин]

Quote from amazing ModernPerl book http://modernperlbooks.com/

"Perl's default object system is minimal but flexible. Its syntax is a 
little clunky, and it exposes /how/ an object system works. You can 
build great things on top of it, but it doesn't give you what many other 
languages do by default.


/Moose/ is a complete object system for Perl. It's a complete 
distribution available from the CPAN—not a part of the core language, 
but worth installing and using regardless. Moose offers both a simpler 
way to use an object system as well as advanced features of languages 
such as Smalltalk and Common Lisp."



If you find Moose to heavy for start, you can use Moo + Types::Standard 
libraries. It combination provides almost same syntaxis, but has much  
less dependecies and a bit easy to install.



25.04.17 5:57, Chas. Owens пишет:

The main benefits I see are

1. You have to write less code
2. Roles provide the benefits of multiple inheritance without the insanity
3. Introspection of Moose classes is easier
4. Type safety (which is really just points 1 and 3 again)

The biggest one is 1. Moose is basically a declarative language for 
creating classes. It creates a lot of the code for you based on what 
you say you want. Sure you could write that code, but it is all 
boilerplate stuff and I would rather spend my time working logic than 
boilerplate. It also provides nice abstract concepts like before, 
after, and around methods. Sure, you could just use 
$self-SUPER::method(@_) at the right, but the new keywords provide a 
more self documenting way of expressing the relationship.


Sure, Moose can't do anything that Perl 5's OO can't do because Moose 
it's written using Perl 5's OO, but, in the end, Moose is already 
written and provides a lot of shortcuts (once you learn how to use it)



On Mon, Apr 24, 2017, 20:40 Peng Yonghua > wrote:


Hi,

I saw many modules begin to write with Moose.

For me I wrote my perl modules most time with OO style, I think perl's
native OO works just fine.

So why needs moose? thanks.

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org

For additional commands, e-mail: beginners-h...@perl.org

http://learn.perl.org/

Re: are state objects ok?

[Chas. Owens]

State variables are just like my variables but with a different lifetime,
so it is safe (assuming it would be safe to use my variables that life for
the lifetime of the program). In this case, what happens if you lose
database access and then reconnect? What happens if you have two database
handles? Your statement handles are going to be bad or refer to the wrong
DB. What you really want here is the $dbh->prepare_cached method call. It
will correctly handle both scenarios and avoid reparsing the SQL.

On Mon, Apr 24, 2017, 20:02 lee  wrote:

> Hi,
>
> is it ok to assign an object to a state variable?  Or does doing so
> involve a chance of causing problems because objects are not supposed or
> designed to be used with the state-feature?
>
> Example:
>
>
> use feature qw(state);
> use DBI;
>
>
> sub foo {
>   my ($dbh, $q, $finish) = @_;
>
>   state $sth = $dbh->prepare("SELECT foo FROM bar WHERE baz = ? LIMIT 1");
>   if($finish) {
> $sth->finish();
> return 0;
>   }
>
>   $sth->execute($q);
>   my ($ret) = $dbh->selectrow_array($sth);
>
>   return $ret;
> }
>
>
> #
> # do some stuff like connecting to database etc.
> #
>
> foreach (1..10) {
>   my $z = foo($dbh, $_, 0);
>   #
>   # do more stuff with $z
>   #
>   my $x = foo($dbh, $z, 0);
>   #
>   # ...
>   #
> }
>
> foo($dbh, 1);
> exit 0;
>
>
> I think it would be nicer to keep statement handles ($sth) contained within
> the functions that use them instead of defining them in the main part and
> handing them over to the functions.  Their very purpose is that you define
> a handle once and use it multiple times, thus saving the overhead of
> interpreting the statement every time it is used.
>
> But can I safely use a state-variable like this?  If not, then what?
>
>
> --
> "Didn't work" is an error.
>
> --
> To unsubscribe, e-mail: beginners-unsubscr...@perl.org
> For additional commands, e-mail: beginners-h...@perl.org
> http://learn.perl.org/
>
>
>

Re: why moose

[Chas. Owens]

The main benefits I see are

1. You have to write less code
2. Roles provide the benefits of multiple inheritance without the insanity
3. Introspection of Moose classes is easier
4. Type safety (which is really just points 1 and 3 again)

The biggest one is 1. Moose is basically a declarative language for
creating classes. It creates a lot of the code for you based on what you
say you want. Sure you could write that code, but it is all boilerplate
stuff and I would rather spend my time working logic than boilerplate. It
also provides nice abstract concepts like before, after, and around
methods. Sure, you could just use $self-SUPER::method(@_) at the right, but
the new keywords provide a more self documenting way of expressing the
relationship.

Sure, Moose can't do anything that Perl 5's OO can't do because Moose it's
written using Perl 5's OO, but, in the end, Moose is already written and
provides a lot of shortcuts (once you learn how to use it)

On Mon, Apr 24, 2017, 20:40 Peng Yonghua  wrote:

> Hi,
>
> I saw many modules begin to write with Moose.
>
> For me I wrote my perl modules most time with OO style, I think perl's
> native OO works just fine.
>
> So why needs moose? thanks.
>
> --
> To unsubscribe, e-mail: beginners-unsubscr...@perl.org
> For additional commands, e-mail: beginners-h...@perl.org
> http://learn.perl.org/
>
>
>

why moose

[Peng Yonghua]

Hi,

I saw many modules begin to write with Moose.

For me I wrote my perl modules most time with OO style, I think perl's 
native OO works just fine.


So why needs moose? thanks.

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

are state objects ok?

[lee]

Hi,

is it ok to assign an object to a state variable?  Or does doing so
involve a chance of causing problems because objects are not supposed or
designed to be used with the state-feature?

Example:


use feature qw(state);
use DBI;


sub foo {
  my ($dbh, $q, $finish) = @_;

  state $sth = $dbh->prepare("SELECT foo FROM bar WHERE baz = ? LIMIT 1");
  if($finish) {
$sth->finish();
return 0;
  }

  $sth->execute($q);
  my ($ret) = $dbh->selectrow_array($sth);

  return $ret;
}


#
# do some stuff like connecting to database etc.
#

foreach (1..10) {
  my $z = foo($dbh, $_, 0);
  #
  # do more stuff with $z
  #
  my $x = foo($dbh, $z, 0);
  #
  # ...
  #
}

foo($dbh, 1);
exit 0;


I think it would be nicer to keep statement handles ($sth) contained within
the functions that use them instead of defining them in the main part and
handing them over to the functions.  Their very purpose is that you define
a handle once and use it multiple times, thus saving the overhead of
interpreting the statement every time it is used.

But can I safely use a state-variable like this?  If not, then what?


-- 
"Didn't work" is an error.

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Perl reserved words

[SSC_perl]

> On Apr 23, 2017, at 11:51 AM, Shlomi Fish  wrote:
> 
> It is not a reserved word of Perl. No idea about MySQL.

Must be something in the code then.  I’ll try it again and see if it 
still happens.  If so, I’ll make sure to mention the error instead of just 
saying “it doesn’t work”. ;)  That’s what I get for letting too much time pass 
before asking a question.

Thanks,
Frank
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/