Nathan Wiger wrote:
(in response to an assertion of preference for undecorated filehandles)
> Well, I think you might be overlooking a couple of important things
> about filehandles. First, having them NOT be scalars caused many
> problems:
>
> 1. You must use globs to pass them in and out of functions
This could be resolved by allowing undecorated types to be passed
> 2. You cannot assign to them easily, even when it makes sense
This could be resolved by allowing undecorated types to have assignment
operators associated with their type
> 3. There's no way to have them interpolated in strings into
> something potentially useful.
The string value of a file handle. Hmm. Is it's internal file descriptor number?
Is it the name of the file? What if it's an anonymous stream? Is it the contents
of the file? How far? If interpolation implies reading, how much is read, and can
it be shoved back in to be read again?
I like file handles that belong to an uninterpolable, undecorated type. I don't
want anything interpolating in my doublequotes except specifically designated
expressions starting with $ or @.
> 4. There's no easy way to maintain them as objects without
> problematic contortions.
Not if we expand "object" to something that can handle them. Can the problematic
contortions be hidden?
> The only downside is:
>
> 1. They don't standout as well anymore
>
> But you can make up for this by just keeping them in ALLCAPS:
>
> $FILE = open "/etc/motd";
> print $FILE @stuff;
>
> Plus you get all the other benefits, which really are big huge benefits,
> especially when you do lots of work with filehandles.
>
> This is not mere decoration, it is fundamentally upgrading filehandles
> to first-class types - finally! While it does take a little getting used
> to, type it a few times and I think you'll find it looks just as natural
> - in fact more natural when you consider $STDOUT is now a true object
> containing true properties.
I do not know what your vehemence refers to. STDOUT didn't truly refer
to file descriptor #1 before?
> Historically, it has been implicitly learned that filehandles are
> "different thingies", but they're not, no different than a handle to a
> web doc or ftp server - which are scalars currently.
Mine aren't
open WEBPAGE, "hose $server 80 -slave < tmpdata/getexp$$ |";
And a hidden ftp session is something a lot more complex than a file handle.
> This change is not
> about just making handles look more scalar-ish, it's about letting
> handles act and exist as first-class types.
>
> -Nate
So why not allow undecorated variables a larger existence? This way allows
more flexibility, allowing definition of an infinite variety of holes and pegs
instead of sticking with our familiar round hole and peg.
With lvalue subroutines we have the ability, in perl 5.6 and up, to have
an accessor function that returns a reference to something. Which,
means we can now have myriad types.
Why not keep the file handle as a canonical example of an undecorated type,
that we can do new things with in perl 6
pass as an argument
Assign to using some means other than the special accessor
function for the filehandle type, C<open>
--
Al Bundy 816.235.1187 [EMAIL PROTECTED]
http://www.weihenstephan.org/~joaraue/img/snf.gif
