Re: match and grab



Rob Dixon wrote:
>
> John W. Krahn wrote:
>>
>> Rob Dixon wrote:
>>>
>>> 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 secondly 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.

Sorry about the amount of quoting, but this goes back a few weeks and I thought
people may need a reminder.

I've just found a reference in the Perl documentation which says that things are
just as I thought they were, thank goodness!

perldoc perlobj

Indirect Object Syntax

The other way to invoke a method is by using the so-called "indirect
object" notation. This syntax was available in Perl 4 long before
objects were introduced, and is still used with filehandles like this:

print STDERR "help!!!\n";


But presumably it wasn't called 'indirect object notation' back then?

Rob
.



Relevant Pages

  • Re: Logging with Log::StdLog from within a package
    ... But what is that {*FILEHANDLE} syntax mean to the perl interpreter? ... Which, if any, perldoc? ...
    (comp.lang.perl.misc)
  • Re: match and grab
    ... print FILEHANDLE LIST ... print Prints a string or a list of strings. ... /behaves/ like indirect-object method call syntax, ... syntax works and does the same thing. ...
    (perl.beginners)
  • Re: Newbie question - create a file
    ... and in what way did it fail? ... I had the syntax all messed up. ... I was using a number for a filehandle (like ... The script would execute without error messages, ...
    (comp.lang.perl.misc)