javonet-nodejs-sdk 2.5.14 → 2.5.16

package/Binaries/Perl/Linux/X64/deps/lib/perl5/x86_64-linux-gnu-thread-multi/Moose/Manual/Concepts.pod

@@ -1,439 +0,0 @@
-# PODNAME: Moose::Manual::Concepts
-# ABSTRACT: Moose OO concepts
-
-__END__
-
-=pod
-
-=encoding UTF-8
-
-=head1 NAME
-
-Moose::Manual::Concepts - Moose OO concepts
-
-=head1 VERSION
-
-version 2.2207
-
-=head1 MOOSE CONCEPTS (VS "OLD SCHOOL" Perl)
-
-In the past, you may not have thought too much about the difference
-between packages and classes, attributes and methods, constructors and
-methods, etc. With Moose, these are all conceptually separate,
-though under the hood they're implemented with plain old Perl.
-
-Our meta-object protocol (aka MOP) provides well-defined introspection
-features for each of those concepts, and Moose in turn provides
-distinct sugar for each of them. Moose also introduces additional
-concepts such as roles, method modifiers, and declarative delegation.
-
-Knowing what these concepts mean in Moose-speak, and how they used to
-be done in old school Perl 5 OO is a good way to start learning to use
-Moose.
-
-=head2 Class
-
-When you say "use Moose" in a package, you are making your package a
-class. At its simplest, a class will consist simply of attributes
-and/or methods. It can also include roles, method modifiers, and more.
-
-A class I<has> zero or more B<attributes>.
-
-A class I<has> zero or more B<methods>.
-
-A class I<has> zero or more superclasses (aka parent classes). A
-class inherits from its superclass(es).
-
-A class I<has> zero or more B<method modifiers>. These modifiers can
-apply to its own methods or methods that are inherited from its
-ancestors.
-
-A class I<does> (and I<consumes>) zero or more B<roles>.
-
-A class I<has> a B<constructor> and a B<destructor>. These are
-provided for you "for free" by Moose.
-
-The B<constructor> accepts named parameters corresponding to the
-class's attributes and uses them to initialize an B<object instance>.
-
-A class I<has> a B<metaclass>, which in turn has B<meta-attributes>,
-B<meta-methods>, and B<meta-roles>. This metaclass I<describes> the
-class.
-
-A class is usually analogous to a category of nouns, like "People" or
-"Users".
-
-  package Person;
-
-  use Moose;
-  # now it's a Moose class!
-
-=head2 Attribute
-
-An attribute is a property of the class that defines it. It I<always>
-has a name, and it I<may have> a number of other properties.
-
-These properties can include a read/write flag, a B<type>, accessor
-method names, B<delegations>, a default value, and more.
-
-Attributes I<are not> methods, but defining them causes various
-accessor methods to be created. At a minimum, a normal attribute will
-have a reader accessor method. Many attributes have other
-methods, such as a writer method, a clearer method, or a predicate method
-("has it been set?").
-
-An attribute may also define B<delegations>, which will create
-additional methods based on the delegation mapping.
-
-By default, Moose stores attributes in the object instance, which is a
-hashref, I<but this is invisible to the author of a Moose-based
-class>!  It is best to think of Moose attributes as "properties" of
-the I<opaque> B<object instance>. These properties are accessed
-through well-defined accessor methods.
-
-An attribute is something that the class's members have. For example,
-People have first and last names. Users have passwords and last login
-datetimes.
-
-  has 'first_name' => (
-      is  => 'rw',
-      isa => 'Str',
-  );
-
-=head2 Method
-
-A B<method> is very straightforward. Any subroutine you define in your
-class is a method.
-
-B<Methods> correspond to verbs, and are what your objects can do. For
-example, a User can login.
-
-  sub login { ... }
-
-=head2 Role
-
-A role is something that a class I<does>. We also say that classes
-I<consume> roles. For example, a Machine class might do the Breakable
-role, and so could a Bone class. A role is used to define some concept
-that cuts across multiple unrelated classes, like "breakability", or
-"has a color".
-
-A role I<has> zero or more B<attributes>.
-
-A role I<has> zero or more B<methods>.
-
-A role I<has> zero or more B<method modifiers>.
-
-A role I<has> zero or more B<required methods>.
-
-A required method is not implemented by the role. Required methods are a way
-for the role to declare "to use this role you must implement this method".
-
-A role I<has> zero or more B<excluded roles>.
-
-An excluded role is a role that the role doing the excluding says it
-cannot be combined with.
-
-Roles are I<composed> into classes (or other roles). When a role is
-composed into a class, its attributes and methods are "flattened" into
-the class. Roles I<do not> show up in the inheritance hierarchy. When
-a role is composed, its attributes and methods appear as if they were
-defined I<in the consuming class>.
-
-Role are somewhat like mixins or interfaces in other OO languages.
-
-  package Breakable;
-
-  use Moose::Role;
-
-  requires 'break';
-
-  has 'is_broken' => (
-      is  => 'rw',
-      isa => 'Bool',
-  );
-
-  after 'break' => sub {
-      my $self = shift;
-
-      $self->is_broken(1);
-  };
-
-=head2 Method modifiers
-
-A B<method modifier> is a hook that is called when a named method is
-called. For example, you could say "before calling C<login()>, call
-this modifier first". Modifiers come in different flavors like
-"before", "after", "around", and "augment", and you can apply more
-than one modifier to a single method.
-
-Method modifiers are often used as an alternative to overriding a
-method in a parent class. They are also used in roles as a way of
-modifying methods in the consuming class.
-
-Under the hood, a method modifier is just a plain old Perl subroutine
-that gets called before or after (or around, etc.) some named method.
-
-  before 'login' => sub {
-      my $self = shift;
-      my $pw   = shift;
-
-      warn "Called login() with $pw\n";
-  };
-
-=head2 Type
-
-Moose also comes with a (miniature) type system. This allows you to define
-types for attributes. Moose has a set of built-in types based on the types
-Perl provides in its core, such as C<Str>, C<Num>, C<Bool>, C<HashRef>, etc.
-
-In addition, every class name in your application can also be used as
-a type name.
-
-Finally, you can define your own types with their own constraints. For
-example, you could define a C<PosInt> type, a subtype of C<Int> which only
-allows positive numbers.
-
-=head2 Delegation
-
-Moose attributes provide declarative syntax for defining delegations. A
-delegation is a method which in turn calls some method on an attribute to do
-its real work.
-
-=head2 Constructor
-
-A constructor creates an B<object instance> for the class. In old
-school Perl, this was usually done by defining a method called
-C<new()> which in turn called C<bless> on a reference.
-
-With Moose, this C<new()> method is created for you, and it simply
-does the right thing. You should never need to define your own
-constructor!
-
-Sometimes you want to do something whenever an object is created. In
-those cases, you can provide a C<BUILD()> method in your class. Moose
-will call this for you after creating a new object.
-
-=head2 Destructor
-
-This is a special method called when an object instance goes out of
-scope. You can specialize what your class does in this method if you
-need to, but you usually don't.
-
-With old school Perl 5, this is the C<DESTROY()> method, but with
-Moose it is the C<DEMOLISH()> method.
-
-=head2 Object instance
-
-An object instance is a specific noun in the class's "category". For
-example, one specific Person or User. An instance is created by the
-class's B<constructor>.
-
-An instance has values for its attributes. For example, a specific
-person has a first and last name.
-
-In old school Perl 5, this is often a blessed hash reference. With
-Moose, you should never need to know what your object instance
-actually is. (Okay, it's usually a blessed hashref with Moose, too.)
-
-=head2 Moose vs old school summary
-
-=over 4
-
-=item * Class
-
-A package with no introspection other than mucking about in the symbol
-table.
-
-With Moose, you get well-defined declaration and introspection.
-
-=item * Attributes
-
-Hand-written accessor methods, symbol table hackery, or a helper
-module like C<Class::Accessor>.
-
-With Moose, these are declaratively defined, and distinct from
-methods.
-
-=item * Method
-
-These are pretty much the same in Moose as in old school Perl.
-
-=item * Roles
-
-C<Class::Trait> or C<Class::Role>, or maybe C<mixin.pm>.
-
-With Moose, they're part of the core feature set, and are
-introspectable like everything else.
-
-=item * Method Modifiers
-
-Could only be done through serious symbol table wizardry, and you
-probably never saw this before (at least in Perl 5).
-
-=item * Type
-
-Hand-written parameter checking in your C<new()> method and accessors.
-
-With Moose, you define types declaratively, and then use them by name
-with your attributes.
-
-=item * Delegation
-
-C<Class::Delegation> or C<Class::Delegator>, but probably even more
-hand-written code.
-
-With Moose, this is also declarative.
-
-=item * Constructor
-
-A C<new()> method which calls C<bless> on a reference.
-
-Comes for free when you define a class with Moose.
-
-=item * Destructor
-
-A C<DESTROY()> method.
-
-With Moose, this is called C<DEMOLISH()>.
-
-=item * Object Instance
-
-A blessed reference, usually a hash reference.
-
-With Moose, this is an opaque thing which has a bunch of attributes
-and methods, as defined by its class.
-
-=item * Immutabilization
-
-Moose comes with a feature called "immutabilization". When you make
-your class immutable, it means you're done adding methods, attributes,
-roles, etc. This lets Moose optimize your class with a bunch of
-extremely dirty in-place code generation tricks that speed up things
-like object construction and so on.
-
-=back
-
-=head1 META WHAT?
-
-A metaclass is a class that describes classes. With Moose, every class you
-define gets a C<meta()> method. The C<meta()> method returns a
-L<Moose::Meta::Class> object, which has an introspection API that can tell you
-about the class it represents.
-
-  my $meta = User->meta();
-
-  for my $attribute ( $meta->get_all_attributes ) {
-      print $attribute->name(), "\n";
-
-      if ( $attribute->has_type_constraint ) {
-          print "  type: ", $attribute->type_constraint->name, "\n";
-      }
-  }
-
-  for my $method ( $meta->get_all_methods ) {
-      print $method->name, "\n";
-  }
-
-Almost every concept we defined earlier has a meta class, so we have
-L<Moose::Meta::Class>, L<Moose::Meta::Attribute>,
-L<Moose::Meta::Method>, L<Moose::Meta::Role>,
-L<Moose::Meta::TypeConstraint>, L<Moose::Meta::Instance>, and so on.
-
-=head1 BUT I NEED TO DO IT MY WAY!
-
-One of the great things about Moose is that if you dig down and find
-that it does something the "wrong way", you can change it by extending
-a metaclass. For example, you can have arrayref based objects, you can
-make your constructors strict (no unknown parameters allowed!), you can
-define a naming scheme for attribute accessors, you can make a class a
-Singleton, and much, much more.
-
-Many of these extensions require surprisingly small amounts of code,
-and once you've done it once, you'll never have to hand-code "your way
-of doing things" again. Instead you'll just load your favorite
-extensions.
-
-  package MyWay::User;
-
-  use Moose;
-  use MooseX::StrictConstructor;
-  use MooseX::MyWay;
-
-  has ...;
-
-=head1 WHAT NEXT?
-
-So you're sold on Moose. Time to learn how to really use it.
-
-If you want to see how Moose would translate directly into old school
-Perl 5 OO code, check out L<Moose::Manual::Unsweetened>. This might be
-helpful for quickly wrapping your brain around some aspects of "the
-Moose way".
-
-Or you can skip that and jump straight to L<Moose::Manual::Classes>
-and the rest of the L<Moose::Manual>.
-
-After that we recommend that you start with the L<Moose::Cookbook>. If
-you work your way through all the recipes under the basics section,
-you should have a pretty good sense of how Moose works, and all of its
-basic OO features.
-
-After that, check out the Role recipes. If you're really curious, go
-on and read the Meta and Extending recipes, but those are mostly there
-for people who want to be Moose wizards and extend Moose itself.
-
-=head1 AUTHORS
-
-=over 4
-
-=item *
-
-Stevan Little <stevan@cpan.org>
-
-=item *
-
-Dave Rolsky <autarch@urth.org>
-
-=item *
-
-Jesse Luehrs <doy@cpan.org>
-
-=item *
-
-Shawn M Moore <sartak@cpan.org>
-
-=item *
-
-יובל קוג'מן (Yuval Kogman) <nothingmuch@woobling.org>
-
-=item *
-
-Karen Etheridge <ether@cpan.org>
-
-=item *
-
-Florian Ragwitz <rafl@debian.org>
-
-=item *
-
-Hans Dieter Pearcey <hdp@cpan.org>
-
-=item *
-
-Chris Prather <chris@prather.org>
-
-=item *
-
-Matt S Trout <mstrout@cpan.org>
-
-=back
-
-=head1 COPYRIGHT AND LICENSE
-
-This software is copyright (c) 2006 by Infinity Interactive, Inc.
-
-This is free software; you can redistribute it and/or modify it under
-the same terms as the Perl 5 programming language system itself.
-
-=cut

package/Binaries/Perl/Linux/X64/deps/lib/perl5/x86_64-linux-gnu-thread-multi/Moose/Manual/Construction.pod

@@ -1,228 +0,0 @@
-# PODNAME: Moose::Manual::Construction
-# ABSTRACT: Object construction (and destruction) with Moose
-
-__END__
-
-=pod
-
-=encoding UTF-8
-
-=head1 NAME
-
-Moose::Manual::Construction - Object construction (and destruction) with Moose
-
-=head1 VERSION
-
-version 2.2207
-
-=head1 WHERE'S THE CONSTRUCTOR?
-
-B<Do not define a C<new()> method for your classes!>
-
-When you C<use Moose> in your class, your class becomes a subclass of
-L<Moose::Object>. The L<Moose::Object> provides a C<new()> method for your
-class. If you follow our recommendations in L<Moose::Manual::BestPractices>
-and make your class immutable, then you actually get a class-specific C<new()>
-method "inlined" in your class.
-
-=head1 OBJECT CONSTRUCTION AND ATTRIBUTES
-
-The Moose-provided constructor accepts a hash or hash reference of
-named parameters matching your attributes (actually, matching their
-C<init_arg>s). This is just another way in which Moose keeps you from
-worrying I<how> classes are implemented. Simply define a class and
-you're ready to start creating objects!
-
-=head1 OBJECT CONSTRUCTION HOOKS
-
-Moose lets you hook into object construction. You can validate an
-object's state, do logging, customize construction from parameters which
-do not match your attributes, or maybe allow non-hash(ref) constructor
-arguments. You can do this by creating C<BUILD> and/or C<BUILDARGS>
-methods.
-
-If these methods exist in your class, Moose will arrange for them to
-be called as part of the object construction process.
-
-=head2 BUILDARGS
-
-The C<BUILDARGS> method is called as a class method I<before> an
-object is created. It will receive all of the arguments that were
-passed to C<new()> I<as-is>, and is expected to return a hash
-reference. This hash reference will be used to construct the object,
-so it should contain keys matching your attributes' names (well,
-C<init_arg>s).
-
-One common use for C<BUILDARGS> is to accommodate a non-hash(ref)
-calling style. For example, we might want to allow our Person class to
-be called with a single argument of a social security number, C<<
-Person->new($ssn) >>.
-
-Without a C<BUILDARGS> method, Moose will complain, because it expects
-a hash or hash reference. We can use the C<BUILDARGS> method to
-accommodate this calling style:
-
-  around BUILDARGS => sub {
-      my $orig  = shift;
-      my $class = shift;
-
-      if ( @_ == 1 && !ref $_[0] ) {
-          return $class->$orig( ssn => $_[0] );
-      }
-      else {
-          return $class->$orig(@_);
-      }
-  };
-
-Note the call to C<< $class->$orig >>. This will call the default C<BUILDARGS>
-in L<Moose::Object>. This method takes care of distinguishing between a hash
-reference and a plain hash for you.
-
-=head2 BUILD
-
-The C<BUILD> method is called I<after> an object is created. There are
-several reasons to use a C<BUILD> method. One of the most common is to
-check that the object state is valid. While we can validate individual
-attributes through the use of types, we can't validate the state of a
-whole object that way.
-
-  sub BUILD {
-      my $self = shift;
-
-      if ( $self->country_of_residence eq 'USA' ) {
-          die 'All US residents must have an SSN'
-              unless $self->has_ssn;
-      }
-  }
-
-Another use of a C<BUILD> method could be for logging or tracking
-object creation.
-
-  sub BUILD {
-      my $self = shift;
-
-      debug( 'Made a new person - SSN = ', $self->ssn, );
-  }
-
-The C<BUILD> method is called with the hash reference of the parameters passed
-to the constructor (after munging by C<BUILDARGS>). This gives you a chance to
-do something with parameters that do not represent object attributes.
-
-  sub BUILD {
-      my $self = shift;
-      my $args = shift;
-
-      $self->add_friend(
-          My::User->new(
-              user_id => $args->{user_id},
-          )
-      );
-  }
-
-=head3 BUILD and parent classes
-
-The interaction between multiple C<BUILD> methods in an inheritance hierarchy
-is different from normal Perl methods. B<You should never call C<<
-$self->SUPER::BUILD >>>, nor should you ever apply a method modifier to
-C<BUILD>. Roles are an exception to this rule, though: it's completely
-acceptable to apply a method modifier to C<BUILD> in a role; you can
-even provide an empty C<BUILD> subroutine in a role so the role is applicable
-even to classes without their own C<BUILD>.
-
-Moose arranges to have all of the C<BUILD> methods in a hierarchy
-called when an object is constructed, I<from parents to
-children>. This might be surprising at first, because it reverses the
-normal order of method inheritance.
-
-The theory behind this is that C<BUILD> methods can only be used for
-increasing specialization of a class's constraints, so it makes sense
-to call the least specific C<BUILD> method first. Also, this is how
-Perl 6 does it.
-
-=head1 OBJECT DESTRUCTION
-
-Moose provides a hook for object destruction with the C<DEMOLISH>
-method. As with C<BUILD>, you should never explicitly call C<<
-$self->SUPER::DEMOLISH >>. Moose will arrange for all of the
-C<DEMOLISH> methods in your hierarchy to be called, from most to least
-specific.
-
-Each C<DEMOLISH> method is called with a single argument. This is a boolean
-value indicating whether or not this method was called as part of the global
-destruction process (when the Perl interpreter exits).
-
-In most cases, Perl's built-in garbage collection is sufficient, and
-you won't need to provide a C<DEMOLISH> method.
-
-=head2 Error Handling During Destruction
-
-The interaction of object destruction and Perl's global C<$@> and C<$?>
-variables can be very confusing.
-
-Moose always localizes C<$?> when an object is being destroyed. This means
-that if you explicitly call C<exit>, that exit code will be preserved even if
-an object's destructor makes a system call.
-
-Moose also preserves C<$@> against any C<eval> calls that may happen during
-object destruction. However, if an object's C<DEMOLISH> method actually dies,
-Moose explicitly rethrows that error.
-
-If you do not like this behavior, you will have to provide your own C<DESTROY>
-method and use that instead of the one provided by L<Moose::Object>. You can
-do this to preserve C<$@> I<and> capture any errors from object destruction by
-creating an error stack.
-
-=head1 AUTHORS
-
-=over 4
-
-=item *
-
-Stevan Little <stevan@cpan.org>
-
-=item *
-
-Dave Rolsky <autarch@urth.org>
-
-=item *
-
-Jesse Luehrs <doy@cpan.org>
-
-=item *
-
-Shawn M Moore <sartak@cpan.org>
-
-=item *
-
-יובל קוג'מן (Yuval Kogman) <nothingmuch@woobling.org>
-
-=item *
-
-Karen Etheridge <ether@cpan.org>
-
-=item *
-
-Florian Ragwitz <rafl@debian.org>
-
-=item *
-
-Hans Dieter Pearcey <hdp@cpan.org>
-
-=item *
-
-Chris Prather <chris@prather.org>
-
-=item *
-
-Matt S Trout <mstrout@cpan.org>
-
-=back
-
-=head1 COPYRIGHT AND LICENSE
-
-This software is copyright (c) 2006 by Infinity Interactive, Inc.
-
-This is free software; you can redistribute it and/or modify it under
-the same terms as the Perl 5 programming language system itself.
-
-=cut