This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Formats out of core / New format syntax =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 30 Aug 2000 Last Modified: 16 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 181 Version: 2 Status: Retracted =head1 ABSTRACT There has been much hinting at moving formats out of core. This RFC proposes one way to do this, at the same time standardizing the syntax. =head1 NOTES ON RETRACTION B<RFC 230: Replace format built-in with pragmatically-induced format function> is a much more complete and comprehensive proposal which I personally like better too. ;-) =head1 DESCRIPTION =head2 Overview Currently, the general consensus is that formats aren't widely used enough to justify their living in the core binary. [1] However, they are incredibly useful, and need to remain in the core distribution no matter what. Under this RFC, formats will be available through a simple: use Format; The rest of the RFC will address specific changes in syntax to make this possible (and more consistent too). =head2 Current Syntax Currently, formats must be named for the bareword filehandle that they're going to be used on, for example: format FILE = @<<<<<<<<<<<<<: @<<<<<<<< $name, $ssn . open FILE, ">>$file"; write FILE; Some behind the scenes magic is done to bind these two together. In order to change the format name, you have to use the following statements: $old = select FILE; $~ = MYCUSTOMFORMAT; select $old; Getting this syntax to work as a module would be a collosal headache. In addition, it's pretty peculiar to begin with. As such, a new but very similar syntax is proposed. =head2 New Syntax Under the new syntax, a format will be held in a variable of the C<format> type: my format $FILE_FORMAT = q( @<<<<<<<<<<<<<: @<<<<<<<< $name, $ssn ); Note that declaring the format is remarkably similar to the current form. However, it now can be handled with the existing variable syntax, simplifying implementation. [2] Using formats, however, requires one extra step, since there is no longer any intrinsic property tying formats and filehandles together: open $FILE, ">>$file"; format $FILE ($FILE_FORMAT); # $FILE->format($FILE_FORMAT) write $FILE; # $FILE->write Note, however, that this does get rid of the need to do all the special C<select> statements. The C<format> and C<write> methods could simply be member functions of the C<$FILE> object. However, I don't particularly like extra steps, personally. One way around this would be to assume the default format is C<[handle]_FORMAT>, meaning C<$FILE>'s default format would be C<$FILE_FORMAT>. This would make behavior very similar to current, and would make the above extra step unnecessary. More clever ways of doing this probably exist as well. Finally, note that if L<RFC 174> is adopted, this can be made to look even more simple and consistent: open $FILE, ">>$file"; format $FILE, $FILE_FORMAT; # $FILE->format($FILE_FORMAT) write $FILE; # $FILE->write Since the indirect object and function syntaxes could be used interchangeably. =head1 IMPLEMENTATION Hold on. =head1 MIGRATION There is a need for migration, but I'd rather save this until later since this idea may get massively revised. =head1 NOTES [1] I personally disagree, but this RFC is close enough to make me happy. :-) [2] We might consider making a special case in the Perl parser so that if a variable is declared of type C<format> then the Perl 5 syntax can be used: my format $FILE_FORMAT = @<<<<<<<<<<<<<: @<<<<<<<< $name, $ssn . Then this is even less different and scary. Get rid of that C<my> and it's Perl 5. =head1 REFERENCES RFC 174 (v1): Parse C<func($obj, @args)> as C<func $obj (@args)>
