view release on metacpan or  search on metacpan

lib/Alt/IO/All/new.pod  view on Meta::CPAN

=item * The C<io> function is custom to its scope

=over

=item * The behavior it provides depends on the state of the scope

=item * The behavior it provides also depends on the arguments passed to C<use IO::All>

=back

=item * C<io> returns an IO::All object

=over

=item * The IO::All object has no I/O capabilities

=item * Further method calls invoke a context, causing the IO::All object to rebless itself it something useful like IO::All::File.

=back

=item * Certain methods force a rebless

=over

=item * `file(...), dir(...), socket(...), etc

=item * These methods are more or less hard-coded currently

=back

=item * Options to C<use IO::All> that begin with a C<->, cause a method to be called on each new IO::All object.

=over

=item * use IO::All -strict, -encoding => 'big5';   # causes:

=item * io('foo')->print('hi');                     # to mean:

=item * io('foo')->strict->encoding('big5')->print('hi');

=back

=item * IO::All operations generally return other IO::All objects

=over

=item * Often they return themselves ($self) for chaining

=back

=item * IO::All needs to be completely and consistently extensible

=over

=item * The extensions that ship with IO-All should be the same as third party extensions

=item * Plugins register capabilities with IO::All (tied to a scope)

=back

=item * IO::All operations can be strict or loose. Strict always throws errors on any possible error condition. Strict or loose should be determined by the presence of C<use strict> in the scope (possibly).

=item * IO::All currently uses a big set of overloaded operations by default. This is loved by some and hated by others. It should probably be off by default for 2.0.

=back

=head1 C<IO::ALL> PLUGINS

Currently the extension API is fairly muddy. I would like the new API to
require something like this:

    {
        use strict;
        use IO::All -overload;
        use IO::All::PrintingPress;

        my $io = io('path:to:printing:press#1');
        # is ref($io), 'IO::All';
        $io->print('IO::All');        # calls IO::All::PrintingPress::print
        # is ref($io), 'IO::All::PrintingPress';
    }

So you need to load any extensions that you want to use, within the scope that
you want them in. Exceptions are IO::All::File and IO::All::Dir, which are
automatically loaded, unless you say:

    use IO::All -none;

Plugins can register 3 things:

=over

=item * Register a method (or methods) that will force a rebless in that class.

=item * Register a regexp (or function) that will cause a rebless when the input to io(...) matches.

=item * Register overloads that the plugin responds to.

=back

These things are register according to the scope of the IO::All, so that the
C<io> function will do the right things.

=head1 Transition to the new API

It needs to be determined if the changes that need to be made are too
destructive to coexist with the current IO::All. That determination obviously
cannot be made until the new design is complete.

If it is not too destructive, IO::All and its extensions can be brought
forward.

If it is too destructive, here is one proposed solution:

Support IO::All 2 <options>;

The version '2' will load IO::All2 (or something) and no version will load
the old code.

It is important to assure that the old and new interfaces can coexist in the
same process space.