Larry Wall | 1 May 03:54 2007
Picon

Re: S12: can(), signatures and casting

On Sun, Apr 29, 2007 at 03:42:31AM -0700, Jonathan Lang wrote:
: Ovid wrote:
: >My apologies if these have been answered.  I've been chatting with
: >Jonathan Worthington about some of this and any misconceptions are
: >mine, not his.
: >
: >In reading through S12, I see that .can() returns an iterator for the
: >methods matched.  What I'm curious about is this:
: >
: >  if $obj.can('fribble') {
: >    my BadPoet $jibbet = $obj.fribble('repeatedly');
: >  }
: >
: >Just because $obj.can('fribble') does not mean that the available
: >fribble(s) will accept a string argument or return BadPoet instances.
: >In chatting with Jonathan about this, he speculated that I would have
: >to manually walk the method objects in the iterator to find out if I
: >really have a suitable method.  This seems like what we really have is
: >$object.might($method).  Is there a simpler way of determining if
: >there's an appropriate method for what I need?  It seems like what we
: >really want is a method object where I can declare a signature and then
: >do this:
: >
: >  if $obj.can($object_with_signature){ ... }
: 
: I suppose.  Still, an easier solution might be to allow an optional
: second parameter for .can that takes a signature object:
: 
:  if $obj.can('fribble', :(string -> BadPoet)) {
:    my BadPoet $jibbet = $obj.fribble('repeatedly');
(Continue reading)

Jonathan Lang | 1 May 05:30 2007
Picon

Re: S12: can(), signatures and casting

Larry Wall wrote:
> The fundamental problem here is that we're forcing a method name to be
> represented as a string.  We're basically missing the &foo equivalent
> for methods.  Maybe we need to allow the & indirection on method names
> too:
>
>     if $obj.&fribble:(Str --> BadPoet) {

Takes a little getting used to (it isn't immediately obvious that
you're testing for the existence of a method - at least, not until
you've spent some time thinking about it); but otherwise, I like.

--

-- 
Jonathan "Dataweaver" Lang

Jonathan Lang | 1 May 06:11 2007
Picon

Re: S12: can(), signatures and casting

Larry Wall wrote:
> Maybe we need to allow the & indirection on method names too:
>
>     if $obj.&fribble:(Str --> BadPoet) {

-snip-

> Note that we already define &foo:(Int, Str) to return a list of candidates
> if there's more than one, so extending this from the multi dispatcher
> to the single dispatcher just seem like a SMOS (small matter of syntax).

One corollary of this is that querying an object for its available
methods should probably give you a list of coderefs instead of method
names.

What threw me initially was that I wasn't used to thinking of a
coderef as a test for existence - in particular, I couldn't see how
the method's name could be specified using such a syntax.

Another question: what about

  $obj.?fribble:(Str --> BadPoet)
  $obj.*fribble:(Str --> BadPoet)
  $obj.+fribble:(Str --> BadPoet)

As I understand it, placing a ? or * between an object and a method
results in the method only being called if it exists (although I'm not
clear on what happens if it doesn't); placing a * or + between the
object and method calls every version of the method that applies.
Couldn't you just cap one of the former two with a '&' to prevent the
(Continue reading)

Smylers | 1 May 11:00 2007

Re: Should a dirhandle be a filehandle-like iterator?

John Macdonald writes:

> open(:file), open(:dir), open(:url), ... could be the non-dwimmy
> versions.  If you don't specify an explicit non-dwimmy base variant,
> the dwim magic makes a (preferrably appropriate) choice.

That'll make it easy for people porting PHP scripts to Perl 6 -- in
particular for those wanting to port the security hole where a CGI
parameter is used to form part of a filename opened by a script but a
malicious user can supply a URL instead and cause the program to do
things very different from what it intended.

What are the situations in which a programmer really needs to open
something but doesn't know wether that thing is a file, a directory, or
a URL?  I'm still unpersuaded this is sensible default behaviour.

Smylers

[Apologies for the delay on this; I first tried to send it on April
15th, and only just spotted it failed to get through.]

brian d foy | 1 May 17:01 2007
Picon

Default filehandles, or topicalizing filehandles, or something

I was thinking about default filehandles yesterday. select() doesn't
seem to be around except as an "Unfiled" function in S16. 

Then, as I was looking at 

   .say( "Hello World" );

and 

   $ERR.say( "Hello standard error" );

I figured this might work, and does. Topicalizing a filehandle kinda
acts almost like a default filehandle:

   $_ = $*ERR;
   .say( "Hello standard error" );

But, of course, that won't work for say() used as a function:

   say "Hello standard error" ;

Then, I thought I might assign to $*OUT, which doesn't work in pugs
(and I might have missed the part of the spec that says these are
read-only):

   my $saved_standard = $*OUT;
   $*OUT = $*ERR;   # this is an error

   say "This goes to stderr";   # not until previous line works   
   say $saved_standard: "This goes to stdout";  # just fine
(Continue reading)

brian d foy | 1 May 17:04 2007
Picon

Current file name used by $*ARGS filehandle


Is there going to be a Perl 6 equivalent to $ARGV (the current filename
for the ARGV filehandle)?

This is something I wanted to use in an example in the Learning Perl 6
filehandles chapter:

http://www.learningperl6.com/Chapters/11.filehandles.html

Luke Palmer | 1 May 18:01 2007
Picon

Re: Should a dirhandle be a filehandle-like iterator?

On 5/1/07, Smylers <Smylers <at> stripey.com> wrote:
> What are the situations in which a programmer really needs to open
> something but doesn't know wether that thing is a file, a directory, or
> a URL?  I'm still unpersuaded this is sensible default behaviour.

Lots of times.  It's an agnosticism, meaning that you can write a
module which opens things and it doesn't have to know what it's
opening; as a matter of fact, it doesn't even have to know what kinds
of things it's *capable* of opening.  That's powerful.

The point is, even though opening a file and opening a URL are
reasonably different things, they are both the same logical operation,
so they can be abstracted.  Not abstracting them will either cause
modules to have to take a "type of file" parameter whenever they take
a file, or will lead to code like this:

    my $fh = do given $file {
        when /<url>/ { openurl($file) }
        default       { open($file) }
    }

And the programmer of this module may not have been aware that he
could operate on directories, even though it's just some sort of line
processing module.

Anyway, my point is that the concept of opening something is
abstractable, and not abstracting it means that everyone has to
abstract it separately.

And please don't argue from the standpoint of security holes. Security
(Continue reading)

Larry Wall | 1 May 18:02 2007
Picon

Re: Should a dirhandle be a filehandle-like iterator?

On Tue, May 01, 2007 at 10:00:00AM +0100, Smylers wrote:
: That'll make it easy for people porting PHP scripts to Perl 6 -- in
: particular for those wanting to port the security hole where a CGI
: parameter is used to form part of a filename opened by a script but a
: malicious user can supply a URL instead and cause the program to do
: things very different from what it intended.

PHP's security hole is that it treats tainting as NIH.  Putting http:
on the front of a filename is only one of several ways to attack open,
and open is far from the only spot vulnerable to injection attacks.

Larry

Jonathan Lang | 1 May 18:26 2007
Picon

Re: Default filehandles, or topicalizing filehandles, or something

On 5/1/07, brian d foy <brian.d.foy <at> gmail.com> wrote:
> I was thinking about default filehandles yesterday. select() doesn't
> seem to be around except as an "Unfiled" function in S16.
>
> Then, as I was looking at
>
>    .say( "Hello World" );

At various times, I have seen something to the effect of each of the
following being bandied about:

  $*OUT.say( "Hello World" );
  "Hello World".say;

That is, both filehandles and strings have 'say' methods that do
essentially the same thing, but using subtly different syntax.  How
would I use &("Hello World".say) to write to filehandle $FH?  My gut
reaction would be to use an adverb for the purpose:

  "Hello World".say :to($FH);

This would also work for the sub version:

  say :to($FH) "Hello World";

With this in mind, you probably could create a localized alias for
'say', if you wanted to:

  {
    my &say := &OUTER::say.assuming(:to($FH));
(Continue reading)

Larry Wall | 1 May 19:18 2007
Picon

Re: Default filehandles, or topicalizing filehandles, or something

On Tue, May 01, 2007 at 09:26:38AM -0700, Jonathan Lang wrote:
: On 5/1/07, brian d foy <brian.d.foy <at> gmail.com> wrote:
: >I was thinking about default filehandles yesterday. select() doesn't
: >seem to be around except as an "Unfiled" function in S16.
: >
: >Then, as I was looking at
: >
: >   .say( "Hello World" );
: 
: At various times, I have seen something to the effect of each of the
: following being bandied about:
: 
:  $*OUT.say( "Hello World" );
:  "Hello World".say;
: 
: That is, both filehandles and strings have 'say' methods that do
: essentially the same thing, but using subtly different syntax.  How
: would I use &("Hello World".say) to write to filehandle $FH?  My gut
: reaction would be to use an adverb for the purpose:
: 
:  "Hello World".say :to($FH);
: 
: This would also work for the sub version:
: 
:  say :to($FH) "Hello World";

Don't need a named arg, since we can simply be polymorphic on strings vs
filehandles, which thankfully do not overlap semantically:

    "Hello World".say($FH)
(Continue reading)


Gmane