John W. Krahn wrote: >>> >>>perldoc -f print >>> print FILEHANDLE LIST >>> print LIST >>> print Prints a string or a list of strings. Returns true if >>> successful. FILEHANDLE may be a scalar variable name, >>>in which >>> case the variable contains the name of or a reference >>>to the >>> filehandle, thus introducing one level of indirection. >>> >>>If the comma is missing then the first scalar or bareword argument is >>>treated >>>as a filehandle. >> >>Hmm. Well if I was wrong I'd like to be corrected, but it certainly >>/looks/ and >>/behaves/ like indirect-object method call syntax, and the equivalent arrow >>syntax works and does the same thing. But whether it's really a method call >>under the hood I'm not absolutely certain, especially when there are >>oddities like >> >> print(STDOUT "text\n"); >> >>working fine. Whatever it is, it certainly stops being either a list >>operator or a function call, so what else can it be? > > So you are saying that everytime print() is used IO::Handle gets sucked in > somehow?
Well it's not so far-fetched. After all a lot of magical things happen in Perl, and PerlIO does an on-demand load thing behind the scenes in 5.8. But no, I know that print() is a built-in but thought that it was hooked in on the back of a indirect object method call syntax. A couple of things support this: first that STDOUT->print() works fine, and seondly that it's impossible to write a simple subroutine prototype that does what print() and printf() do whereas that can be done for all (?) other Perl functions. On the other hand you /can/ write an object method that behaves the same syntactically. > And how would this have worked in Perl1 through Perl4 before OO was added? Now that is a puzzle and I hadn't thought of it. But it strikes me as an astonishing choice to provide a unique syntax which is invalid for any other built-in or user-written subroutine for just two built-in functions, and solely to allow an optional first parameter. It is also a huge coincidence that that same syntax pops up later on as a valid construct for object method calls and so makes everything OK. I am quite happy to believe you are right John, and if that is so then I apologise to the list for my mistake, but am also left puzzling over what seems to be a number of enigmas within a language I thought I knew well. Cheers, Rob -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
