In reply to your message from the not too distant future: next Thursday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Fri, 18 Aug 2000 10:07:04 EDT
From: Jerrad Pierce <belg4mit>
> Perl6 does not *have* to break anything, and certainly not everything.
> The prime directive should be not to break things unless necessary.
> Translation should not be a fall-back panacea. And it surely isn't perfect...
>Actually, this is false. If Perl 6 worked just like Perl 5 it would be
>Perl 5.7 or something. The new major version indicates major changes.
>You can't change things for the better if you just plain can't change
>them in the first place. But I *do* agree that things shouldn't be
>broken just for the heck of it.
Major changes does not mean breaking everything under the sun, or at
least breaking something so basic...
Perl 4 to Perl 5 didn't wreak havoc upon the planet, razing barns,
maming mimes, and incurring various traffic violations. The only
spectacular thing I noticed was a subtle lack of backwards compatbility
when I used uc/lc. Now my style has of course changed since then,
and some of stuff would not likely run on Perl4 *now*. But that's as
it should be, a natural mostly eventless progression from one to the next.
> Okay so what about doing this then:
>
> [$return = ] open(bareword, string)
> acts as it currently does
> $handleobj = open(string)
> which is one arg in scalar context acts as you propose.
>
> Internally bareword filehandles and $handleobj could even be of the same type.
>I think supporting two syntaxes that do the same thing is dangerous and
>misleading. In this case, breaking the bareword syntax indicates that
>Perl 6 open() is NOT Perl 5 open(), which is actually a good thing.
There is precedent for multiple syntaxes... e.g.; select
>Also, your examples don't cover this:
> $web = open "http://www.yahoo.com", GET;
>Remember, additional args for the proposed open handler can follow the
>filename.
Never saw it. How many additional arg's?
Maybe you should go with named parameters for object mode then.
For those into OO, this makes more sense than positional parameters
anyways, no?
Or of if you don't like having things act in subtely-different-but-
not-terribly-so ways, how about it be named oopen?
This gives us:
sysopen low-level control
open basic operations
oopen extended wacked out functionality
Aside> So now this is REBOL, eh? ( http://rebol.com ;-)
Also, if you're going to support URL's
(I guess RFC 100 would go in as well then)
Umm what read methods are you going to do on a URL other than GET?
PROPFIND would be an opendir
PUT would be open >http:// or >>http://
POST would be problematic perhaps >-http:// ?
How are you going to set the UA, and other headers?
LWP must die?!
We'd need/want Perl with builtin SSL then which would be non-exportable!
What about ftp:// (whole suite of commands there)? gopher://?
This is really a very big ball of wax that is probably best not
to play with. (Do NOT taunt the happy fun ball) We have LWP,
and it's good. Perhaps some nice means (a module?) to nicely
integrate with REBOL...
>> print_out(\HANDLE, @data);
>>
>> sub print_out {
>> my $handleref = shift;
>> #my $handle = _{$handleref};
>Again, this is really unneeded complexity just for the sake of "saving"
>bareword filehandles from an almost-certain demise. :-) Truly, prefixing
>$ to your filehandles isn't really that radical, and once you get used
>to it it looks very Perlish.
This isn't really complex. It's merely extending an existing metaphor
(references) to cover other datatypes.
And really what's wrong with:
open(HI, ">t");
my $a = \HI;
&foo($a, "123");
sub foo {
my $a = shift();
print {$$a} @_; }
even (I never really tried throwing handles around,
but this seems to work fine)
Then the internals simply need to be tweaked a bit to again
extend current metaphors to allow:
my HI;
open(HI, ">t");
my $a = \HI;
&foo($a, "123");
sub foo {
package bar;
my $a = shift();
print {$$a} @_; }
>> # $F = [1,2,3]; @F = deref($F);
>This can already be expressed simply as @$F.
I am aware of that, it was simply giving an example of how deref could be
used, besides derferencing magical FH references. It also stomps
on nobody's toes and could be more intuitive for the beginner.
Addtionally one might want an enref (same thing as \VAR ) for symmetry.
--
* __ * .
\ | / . . . . . ((_
_____ . . .
-- / \ -- . . . + . . _/\
oooooooooo. | * . . . * / ;M\_ .
.oooooooooooo.oo. . . . . /\ . / :IMM\
..oooooooooooo..oo. Jerrad Pierce /\ / \ / ;IIWMM
..oooooooooo....... 209 North Street + / \ / \ . / ;IIIIWM
...ooooooooo....... Randolph, MA 02368 / \ \ ___/ :;IIIIIWM
....ooo....o....... / \ \ / :: ;;IIIMI
.....ooo......... http://www.pthbb.org / \ \ : :::;IIIM
..ooooooo.... __________________________ || || ::.....::::::
MOTD on Setting Orange, the 11st of Bureaucracy, in the YOLD 3166:
This statement is false.
