Why private and not on perl6?
Posted this to both, hope you don't care.
On Fri, 1 Sep 2000 13:11:53 +0200 (CEST), [EMAIL PROTECTED] (Johan Vromans)
wrote:
> [Quoting H.Merijn Brand, on September 1 2000, 11:02, in "Re: RFC 181 (v1) For"]
> > > Is there any reason left to maintain formats as something internally
> > > special? We could use ordinary strings:
> > >
> > > my $file_format = q(
> > > @<<<<<<<<<<<<<: @<<<<<<<<
> > > $name, $ssn
> > > );
> >
> > Probably because of the deferred interpretation of the contained variabled.
>
> Notice the q(), not qq()! No interpretation at all.
Yep. I did. Just wanted to stress this important bahaviour of format.
> > > write $fh, $format_string;
> >
> > Reverse: write $format_string, $fh;
>
> Maybe. Compatibility w/ p5?
Don't care, different syntax will evolve anyway.
> Compatiblilty w/ print:
Good point, thouhg 'bout that, but again, format will change more often than
the file handle.
> write $fh $format_string [ , ...actual values... ]
> ^ no comma
If qf() would be implemented, write can detect itself, so
write $fh $format;
write $fh, $format;
write $format, $fh;
would *ALL* be valid.
I like the optional [, actual values], permits nice lexical/localized scope.
> > > Now, $file_format would be a Format object (compare this with qr//,
> > > that produces a Regex object).
> >
> > Yes! good! Now write can be called either way, cause the variables are known
> > by type, so
> >
> > write $fh, $format_ref; #is equal to
> > write $format_ref, $fh;
What else would qf() give? A fixed string? I think both of you meant a special
magic attached, otherwise q() would do quite nicely.
> Huh?
--
H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl5.005.03, 5.6.0 & 516 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3,
DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
