RubyGems - javonet-ruby-sdk - Versions diffs - 2.4.10 → 2.4.11 - Mend

javonet-ruby-sdk 2.4.10 → 2.4.11

Files changed (1456) hide show

data/lib/javonet-ruby-sdk/Binaries/Perl/MacOs/X64/deps/lib/perl5/darwin-thread-multi-2level/Moose/Manual/Support.pod DELETED Viewed

@@ -1,204 +0,0 @@
-# PODNAME: Moose::Manual::Support
-# ABSTRACT: Policies regarding support, releases, and compatibility.
-__END__
-=pod
-=encoding UTF-8
-=head1 NAME
-Moose::Manual::Support - Policies regarding support, releases, and compatibility.
-=head1 VERSION
-version 2.2207
-=head1 SUPPORT POLICY
-There are two principles to Moose's policy of supported behavior.
-=over 4
-=item 1.
-Moose favors correctness over everything.
-=item 2.
-Moose supports documented and tested behavior, not accidental behavior or side
-effects.
-=back
-If a behavior has never been documented or tested, the behavior is
-I<officially> undefined. Relying upon undocumented and untested behavior is
-done at your own risk.
-If a behavior is documented or tested but found to be incorrect later, the
-behavior will go through a deprecation period. During the deprecation period,
-use of that feature will cause a warning. Eventually, the deprecated feature
-will be removed.
-In some cases, it is not possible to deprecate a behavior. In this case, the
-behavior will simply be changed in a major release.
-=head1 RELEASE SCHEDULE
-Moose is on a system of quarterly major releases, with minor releases as
-needed between major releases. A minor release is defined as one that makes
-every attempt to preserve backwards compatibility. Currently this means that we
-did not introduce any new dependency conflicts, and that we did not make any
-changes to documented or tested behavior (this typically means that minor
-releases will not change any existing tests in the test suite, although they
-can add new ones). A minor release can include new features and bug fixes.
-Major releases may be backwards incompatible. Moose prioritizes
-correctness over backwards compatibility or performance; see the L<DEPRECATION
-POLICY> to understand how backwards incompatible changes are announced.
-Major releases are scheduled to happen during fixed release windows. If the
-window is missed, then there will not be a major release until the next
-release window. The release windows are one month long, and occur during the
-months of January, April, July, and October.
-Before a major release, a series of development releases will be made so that
-users can test the upcoming major release before it is distributed to CPAN. It
-is in the best interests of everyone involved if these releases are tested as
-widely as possible.
-=head1 DEPRECATION POLICY
-Moose has always prioritized correctness over performance and backwards
-compatibility.
-Major deprecations or API changes are documented in the Changes file as well
-as in L<Moose::Manual::Delta>. The Moose developers will also make an effort
-to warn users of upcoming deprecations and breakage through the Moose blog
-(http://blog.moose.perl.org).
-Deprecated APIs will be preserved for at least one year I<after the major
-release which deprecates that API>. Deprecated APIs will only be removed in a
-major release.
-Moose will also warn during installation if the version of Moose being
-installed will break an installed dependency. Unfortunately, due to the nature
-of the Perl install process these warnings may be easy to miss.
-=head1 BACKWARDS COMPATIBILITY
-We try to ensure compatibility by having a extensive test suite (last count
-over 18000 tests), as well as testing a number of packages (currently just
-under 100 packages) that depend on Moose before any release.
-The current list of downstream dependencies that are tested is in
-C<xt/author/test-my-dependents.t>.
-=head1 VERSION NUMBERS
-Moose version numbers consist of three parts, in the form X.YYZZ. The X is the
-"special magic number" that only gets changed for really big changes. Think of
-this as being like the "5" in Perl 5.12.1.
-The YY portion is the major version number. Moose uses even numbers for stable
-releases, and odd numbers for trial releases. The ZZ is the minor version, and
-it simply increases monotonically. It starts at "00" each time a new major
-version is released.
-Semantically, this means that any two releases which share a major version
-should be API-compatible with each other. In other words, 2.0200, 2.0201, and
-2.0274 are all API-compatible.
-Prior to version 2.0, Moose version numbers were monotonically incrementing
-two decimal values (0.01, 0.02, ... 1.11, 1.12, etc.).
-Moose was declared production ready at version 0.18 (via L<<
-http://www.perlmonks.org/?node_id=608144 >>).
-=head1 PERL VERSION COMPATIBILITY
-As of version 2.16, Moose will officially support being run on perl 5.10.1+. Our
-current policy is to support the earliest version of Perl shipped in the latest
-stable release of any major operating system (this tends to mean CentOS). We
-will provide at least six months notice (two major releases) when we decide to
-increase the officially supported Perl version.
-"Officially supported" does not mean that these are the only versions of Perl
-that Moose will work with. Our declared perl dependency will remain at 5.8.3
-as long as our test suite continues to pass on 5.8.3. What this does mean is
-that the core Moose dev team will not be spending any time fixing bugs on
-versions that aren't officially supported, and new contributions will not be
-rejected due to being incompatible with older versions of perl except in the
-most trivial of cases. We will, however, still welcome patches to make Moose
-compatible with earlier versions, if other people are still interested in
-maintaining compatibility. As such, the current minimum required version of
-5.8.3 will remain for as long as downstream users are happy to assist with
-maintenance.
-Note that although performance regressions are acceptable in order to maintain
-backwards compatibility (as long as they only affect the older versions),
-functionality changes and buggy behavior will not be. If it becomes impossible
-to provide identical functionality between modern Perl versions and
-unsupported Perl versions, we will increase our declared perl dependency
-instead.
-=head1 CONTRIBUTING
-Moose has an open contribution policy. Anybody is welcome to submit a
-patch. Please see L<Moose::Manual::Contributing> for more details.
-=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

data/lib/javonet-ruby-sdk/Binaries/Perl/MacOs/X64/deps/lib/perl5/darwin-thread-multi-2level/Moose/Manual/Types.pod DELETED Viewed

@@ -1,501 +0,0 @@
-# PODNAME: Moose::Manual::Types
-# ABSTRACT: Moose's type system
-__END__
-=pod
-=encoding UTF-8
-=head1 NAME
-Moose::Manual::Types - Moose's type system
-=head1 VERSION
-version 2.2207
-=head1 TYPES IN PERL?
-Moose provides its own type system for attributes. You can also use
-these types to validate method parameters with the help of a MooseX
-module.
-Moose's type system is based on a combination of Perl 5's own
-I<implicit> types and some Perl 6 concepts. You can create your
-own subtypes with custom constraints, making it easy to express any
-sort of validation.
-Types have names, and you can re-use them by name, making it easy to
-share types throughout a large application.
-However, this is not a "real" type system. Moose does not magically make Perl
-start associating types with variables. This is just an advanced parameter
-checking system which allows you to associate a name with a constraint.
-That said, it's still pretty damn useful, and we think it's one of the
-things that makes Moose both fun and powerful. Taking advantage of the
-type system makes it much easier to ensure that you are getting valid
-data, and it also contributes greatly to code maintainability.
-=head1 THE TYPES
-The basic Moose type hierarchy looks like this
-  Any
-      Item
-          Bool
-          Maybe[`a]
-          Undef
-          Defined
-              Value
-                  Str
-                      Num
-                          Int
-                      ClassName
-                      RoleName
-              Ref
-                  ScalarRef[`a]
-                  ArrayRef[`a]
-                  HashRef[`a]
-                  CodeRef
-                  RegexpRef
-                  GlobRef
-                  FileHandle
-                  Object
-In practice, the only difference between C<Any> and C<Item> is
-conceptual. C<Item> is used as the top-level type in the hierarchy.
-The rest of these types correspond to existing Perl concepts.
-In particular:
-=over 4
-=item
-C<Bool> accepts C<1> for true, and undef, 0, or the empty string as false.
-=item
-C<Maybe[`a]> accepts either C<`a> or C<undef>.
-=item
-C<Num> accepts integers, floating point numbers (both in decimal notation &
-exponential notation), 0, .0, 0.0 etc. It doesn't accept numbers with
-whitespace, Inf, Infinity, "0 but true", NaN & other such strings.
-=item
-C<ClassName> and C<RoleName> accept strings that are either the name of a class or the name of a role. The class/role must already be loaded when the constraint is checked.
-=item
-C<FileHandle> accepts either an L<IO::Handle> object or a builtin perl filehandle (see L<Scalar::Util/openhandle>).
-=item
-C<Object> accepts any blessed reference.
-=back
-The types followed by "[`a]" can be parameterized. So instead of just
-plain C<ArrayRef> we can say that we want C<ArrayRef[Int]> instead. We
-can even do something like C<HashRef[ArrayRef[Str]]>.
-The C<Maybe[`a]> type deserves a special mention. Used by itself, it
-doesn't really mean anything (and is equivalent to C<Item>). When it
-is parameterized, it means that the value is either C<undef> or the
-parameterized type. So C<Maybe[Int]> means an integer or C<undef>.
-For more details on the type hierarchy, see
-L<Moose::Util::TypeConstraints>.
-=head1 WHAT IS A TYPE?
-It's important to realize that types are not classes (or
-packages). Types are just objects (L<Moose::Meta::TypeConstraint>
-objects, to be exact) with a name and a constraint. Moose maintains a
-global type registry that lets it convert names like C<Num> into the
-appropriate object.
-However, class names I<can be> type names. When you define a new class
-using Moose, it defines an associated type name behind the scenes:
-  package MyApp::User;
-  use Moose;
-Now you can use C<'MyApp::User'> as a type name:
-  has creator => (
-      is  => 'ro',
-      isa => 'MyApp::User',
-  );
-However, for non-Moose classes there's no magic. You may have to
-explicitly declare the class type. This is a bit muddled because Moose
-assumes that any unknown type name passed as the C<isa> value for an
-attribute is a class. So this works:
-  has 'birth_date' => (
-      is  => 'ro',
-      isa => 'DateTime',
-  );
-In general, when Moose is presented with an unknown name, it assumes
-that the name is a class:
-  subtype 'ModernDateTime'
-      => as 'DateTime'
-      => where { $_->year() >= 1980 }
-      => message { 'The date you provided is not modern enough' };
-  has 'valid_dates' => (
-      is  => 'ro',
-      isa => 'ArrayRef[DateTime]',
-  );
-Moose will assume that C<DateTime> is a class name in both of these
-instances.
-=head1 SUBTYPES
-Moose uses subtypes in its built-in hierarchy. For example, C<Int> is
-a child of C<Num>.
-A subtype is defined in terms of a parent type and a constraint. Any
-constraints defined by the parent(s) will be checked first, followed by
-constraints defined by the subtype. A value must pass I<all> of these
-checks to be valid for the subtype.
-Typically, a subtype takes the parent's constraint and makes it more
-specific.
-A subtype can also define its own constraint failure message. This
-lets you do things like have an error "The value you provided (20),
-was not a valid rating, which must be a number from 1-10." This is
-much friendlier than the default error, which just says that the value
-failed a validation check for the type. The default error can, however,
-be made more friendly by installing L<Devel::PartialDump> (version 0.14 or
-higher), which Moose will use if possible to display the invalid value.
-Here's a simple (and useful) subtype example:
-  subtype 'PositiveInt',
-      as 'Int',
-      where { $_ > 0 },
-      message { "The number you provided, $_, was not a positive number" };
-Note that the sugar functions for working with types are all exported
-by L<Moose::Util::TypeConstraints>.
-=head1 TYPE NAMES
-Type names are global throughout the current Perl
-interpreter. Internally, Moose maps names to type objects via a
-L<registry|Moose::Meta::TypeConstraint::Registry>.
-If you have multiple apps or libraries all using Moose in the same
-process, you could have problems with collisions. We recommend that
-you prefix names with some sort of namespace indicator to prevent
-these sorts of collisions.
-For example, instead of calling a type "PositiveInt", call it
-"MyApp::Type::PositiveInt" or "MyApp::Types::PositiveInt". We
-recommend that you centralize all of these definitions in a single
-package, C<MyApp::Types>, which can be loaded by other classes in your
-application.
-However, before you do this, you should look at the L<MooseX::Types>
-module. This module makes it easy to create a "type library" module, which can
-export your types as perl constants.
-  has 'counter' => (is => 'rw', isa => PositiveInt);
-This lets you use a short name rather than needing to fully qualify the name
-everywhere. It also allows you to easily create parameterized types:
-  has 'counts' => (is => 'ro', isa => HashRef[PositiveInt]);
-This module will check your names at compile time, and is generally more
-robust than the string type parsing for complex cases.
-=head1 COERCION
-A coercion lets you tell Moose to automatically convert one type to another.
-  subtype 'ArrayRefOfInts',
-      as 'ArrayRef[Int]';
-  coerce 'ArrayRefOfInts',
-      from 'Int',
-      via { [ $_ ] };
-You'll note that we created a subtype rather than coercing C<ArrayRef[Int]>
-directly. It's a bad idea to add coercions to the raw built in
-types.
-Coercions are global, just like type names, so a coercion applied to a built
-in type is seen by all modules using Moose types. This is I<another> reason
-why it is good to namespace your types.
-Moose will I<never> try to coerce a value unless you explicitly ask for
-it. This is done by setting the C<coerce> attribute option to a true value:
-  package Foo;
-  has 'sizes' => (
-      is     => 'ro',
-      isa    => 'ArrayRefOfInts',
-      coerce => 1,
-  );
-  Foo->new( sizes => 42 );
-This code example will do the right thing, and the newly created
-object will have C<[ 42 ]> as its C<sizes> attribute.
-=head2 Deep coercion
-Deep coercion is the coercion of type parameters for parameterized
-types. Let's take these types as an example:
-  subtype 'HexNum',
-      as 'Str',
-      where { /[a-f0-9]/i };
-  coerce 'Int',
-      from 'HexNum',
-      via { hex $_ };
-  has 'sizes' => (
-      is     => 'ro',
-      isa    => 'ArrayRef[Int]',
-      coerce => 1,
-  );
-If we try passing an array reference of hex numbers for the C<sizes>
-attribute, Moose will not do any coercion.
-However, you can define a set of subtypes to enable coercion between
-two parameterized types.
-  subtype 'ArrayRefOfHexNums',
-      as 'ArrayRef[HexNum]';
-  subtype 'ArrayRefOfInts',
-      as 'ArrayRef[Int]';
-  coerce 'ArrayRefOfInts',
-      from 'ArrayRefOfHexNums',
-      via { [ map { hex } @{$_} ] };
-  Foo->new( sizes => [ 'a1', 'ff', '22' ] );
-Now Moose will coerce the hex numbers to integers.
-Moose does not attempt to chain coercions, so it will not
-coerce a single hex number. To do that, we need to define a separate
-coercion:
-  coerce 'ArrayRefOfInts',
-      from 'HexNum',
-      via { [ hex $_ ] };
-Yes, this can all get verbose, but coercion is tricky magic, and we
-think it's best to make it explicit.
-=head1 TYPE UNIONS
-Moose allows you to say that an attribute can be of two or more
-disparate types. For example, we might allow an C<Object> or
-C<FileHandle>:
-  has 'output' => (
-      is  => 'rw',
-      isa => 'Object | FileHandle',
-  );
-Moose actually parses that string and recognizes that you are creating
-a type union. The C<output> attribute will accept any sort of object,
-as well as an unblessed file handle. It is up to you to do the right
-thing for each of them in your code.
-Whenever you use a type union, you should consider whether or not
-coercion might be a better answer.
-For our example above, we might want to be more specific, and insist
-that output be an object with a C<print> method:
-  duck_type 'CanPrint', [qw(print)];
-We can coerce file handles to an object that satisfies this condition
-with a simple wrapper class:
-  package FHWrapper;
-  use Moose;
-  has 'handle' => (
-      is  => 'rw',
-      isa => 'FileHandle',
-  );
-  sub print {
-      my $self = shift;
-      my $fh   = $self->handle();
-      print {$fh} @_;
-  }
-Now we can define a coercion from C<FileHandle> to our wrapper class:
-  coerce 'CanPrint'
-      => from 'FileHandle'
-      => via { FHWrapper->new( handle => $_ ) };
-  has 'output' => (
-      is     => 'rw',
-      isa    => 'CanPrint',
-      coerce => 1,
-  );
-This pattern of using a coercion instead of a type union will help
-make your class internals simpler.
-=head1 TYPE CREATION HELPERS
-The L<Moose::Util::TypeConstraints> module exports a number of helper
-functions for creating specific kinds of types. These include
-C<class_type>, C<role_type>, C<maybe_type>, and C<duck_type>. See the
-docs for details.
-One helper worth noting is C<enum>, which allows you to create a
-subtype of C<Str> that only allows the specified values:
-  enum 'RGB', [qw( red green blue )];
-This creates a type named C<RGB>.
-=head1 ANONYMOUS TYPES
-All of the type creation functions return a type object. This type
-object can be used wherever you would use a type name, as a parent
-type, or as the value for an attribute's C<isa> option:
-  has 'size' => (
-      is  => 'ro',
-      isa => subtype( 'Int' => where { $_ > 0 } ),
-  );
-This is handy when you want to create a one-off type and don't want to
-"pollute" the global namespace registry.
-=head1 VALIDATING METHOD PARAMETERS
-Moose does not provide any means of validating method
-parameters. However, there are several MooseX extensions on CPAN which
-let you do this.
-The simplest and least sugary is L<Params::ValidationCompiler>. This
-lets you validate a set of named parameters using Moose types:
-  use Moose::Util::TypeConstraints qw( find_type_constraint );
-  use Params::ValidationCompiler qw( validation_for );
-  {
-      my $validator = validation_for(
-          params => {
-              foo => { type => find_type_constraint('Int') },
-              bar => {
-                  type     => find_type_constraint('Str'),
-                  optional => 1,
-              },
-              baz => {
-                  type    => find_type_constraint('Int'),
-                  default => 42,
-              },
-          },
-      );
-      sub foo {
-          my %args = $validator->(@_);
-      }
-}
-L<Params::ValidationCompiler> also supports coercions.
-There are several more powerful extensions that support method parameter
-validation using Moose types, including L<Moops>, which gives you a full-blown
-C<method> keyword.
-  method morning ( Str $name ) {
-      $self->say("Good morning ${name}!");
-  }
-=head1 LOAD ORDER ISSUES
-Because Moose types are defined at runtime, you may run into load
-order problems. In particular, you may want to use a class's type
-constraint before that type has been defined.
-In order to ameliorate this problem, we recommend defining I<all> of your
-custom types in one module, C<MyApp::Types>, and then loading this module in
-all of your other modules.
-=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