… | |
… | |
9 | =head1 DESCRIPTION |
9 | =head1 DESCRIPTION |
10 | |
10 | |
11 | This module documents the new simpler AnyEvent API. |
11 | This module documents the new simpler AnyEvent API. |
12 | |
12 | |
13 | The rationale for the new API is that experience with L<EV> shows that |
13 | The rationale for the new API is that experience with L<EV> shows that |
14 | this API actually "works", despite it's lack of extensibility. |
14 | this API actually "works", despite it's lack of extensibility, leading to |
|
|
15 | a shorter, easier and faster API. |
15 | |
16 | |
16 | The main difference to AnyEvent is that instead of method calls, function |
17 | The main difference to AnyEvent is that instead of method calls, function |
17 | calls are used, and that no named arguments are used. |
18 | calls are used, and that no named arguments are used. |
18 | |
19 | |
19 | This makes calls to watcher creation functions really short, which can |
20 | This makes calls to watcher creation functions really short, which can |
20 | make a program more readable, despite the lack of named parameters. |
21 | make a program more readable, despite the lack of named parameters. |
21 | Function calls also allow more static type checking than method calls, so |
22 | Function calls also allow more static type checking than method calls, so |
22 | many mistakes are caught at compiletime with this API. |
23 | many mistakes are caught at compiletime with this API. |
23 | |
24 | |
24 | Also, some backends (Perl and EV) are so fast that the method call |
25 | Also, some backends (Perl and EV) are so fast that the method call |
25 | overhead is very noticable (with EV it increases the time five- to |
26 | overhead is very noticeable (with EV it increases the time five- to |
26 | six-fold, with Perl the method call overhead is about a factor of two). |
27 | six-fold, with Perl the method call overhead is about a factor of two). |
27 | |
28 | |
28 | At the moment, there will be no checking (L<AnyEvent::Strict> does not |
29 | At the moment, there will be no checking (L<AnyEvent::Strict> does not |
29 | affect his API), so the L<AnyEvent> API has a definite advantage here |
30 | affect his API), so the L<AnyEvent> API has a definite advantage here |
30 | still. |
31 | still. |
31 | |
32 | |
32 | Note that the C<AE> API is an alternative to, not the future version of, |
33 | Note that the C<AE> API is an alternative to, not the future version of, |
33 | the AnyEvent API. Both APIs can be used interchangably and and there are |
34 | the AnyEvent API. Both APIs can be used interchangably and and there are |
34 | no plans to "switch", so if in doubt, use L<AnyEvent>'s API. |
35 | no plans to "switch", so if in doubt, use the L<AnyEvent> API. |
35 | |
36 | |
36 | As the AE API is complementary, not everything in the AnyEvent API is |
37 | As the AE API is complementary, not everything in the AnyEvent API is |
37 | available, so you still need to use AnyEvent for the finer stuff. Also, |
38 | available, so you still need to use AnyEvent for the finer stuff. Also, |
38 | you should not C<use AE> directly, C<use AnyEvent> will provide the AE |
39 | you should not C<use AE> directly, C<use AnyEvent> will provide the AE |
39 | namespace. |
40 | namespace. |
… | |
… | |
49 | =cut |
50 | =cut |
50 | |
51 | |
51 | package AE; |
52 | package AE; |
52 | |
53 | |
53 | use AnyEvent (); # BEGIN { AnyEvent::common_sense } |
54 | use AnyEvent (); # BEGIN { AnyEvent::common_sense } |
|
|
55 | |
|
|
56 | our $VERSION = $AnyEvent::VERSION; |
54 | |
57 | |
55 | =item $w = AE::io $fh_or_fd, $watch_write, $cb |
58 | =item $w = AE::io $fh_or_fd, $watch_write, $cb |
56 | |
59 | |
57 | Creates an I/O watcher that listens for read events (C<$watch_write> |
60 | Creates an I/O watcher that listens for read events (C<$watch_write> |
58 | false) or write events (C<$watch_write> is true) on the file handle or |
61 | false) or write events (C<$watch_write> is true) on the file handle or |