Sorry, I sent this just to Mark. Wasn't my intention.
---------- Forwarded message ----------
From: Aaron Sherman <a...@ajs.com>
Date: Fri, Jul 10, 2009 at 6:58 PM
Subject: Re: Re-thinking file test operations
To: "Mark J. Reed" <markjr...@gmail.com>
On Fri, Jul 10, 2009 at 5:31 PM, Mark J. Reed <markjr...@gmail.com> wrote:
> I'd rather see all those key types be separate classes, maybe
> subclasses of a generic KeyStr class.
In re-thinking it, we don't need to do either. It's already built in:
$str does Path;
if $str.e {
say("$str exists");
}
Nice and simple. All someone has to do is write the appropriate Path that
knows what to do when it's added to a Str.
I wonder if this works:
if ($str but Path).e { ... }
> The question is how to specify them.
> I think stringish classes are common and useful enough to have
> special literal support available without having to customize the
> grammar. Maybe there's a registry of prefixes that can be put in
> front of the opening quote, like p'....' for a pathname, or maybe you
> have to use a q operator with a modifier.
You've made contradictory statements, there. Either you want to change the
grammar to add new quoting styles (then the argument ensues: is YOUR key
type common enough to deserve a quoting semantic?) or you think that you
shouldn't have to customize the grammar.
I'm in favor of NOT customizing the grammar, but at the same time, I readily
admit that strings aren't always strings, and might have much more semantic
baggage that it would be good to be able to associate with them easily.
>
> On 7/10/09, Aaron Sherman <a...@ajs.com> wrote:
> > On Thu, Jul 9, 2009 at 6:22 PM, Moritz Lenz <mor...@faui2k3.org> wrote:
> >
> >>
> >> $str.File.e # same, different names
> >
> >
> > Brainstorming a bit here....
> >
> > Str is a class that describes collections of characters (among some other
> > typographical constructs, yadda, yadda, Unicode, yadda).
> >
> > There is a commonly used special case, however, where my Str is not just
> a
> > Str. It is, instead, a key for an external datasource. Such cases
> include:
> >
> > * URIs.
> > * Pathnames
> > * Usernames
> > * Variable names
> > * etc.
> >
> > It makes sense to handle these cases in some regular way, and to provide
> > those hooks via Str because it is relatively uniquely Str's job to hold
> > these things (counter-examples include UIDs).
> >
> > OK, so we have a need for some hookable interface on Str for accessing
> > external datasources by key. Let's call it "key".
> >
> > $str = "/etc/aliases"
> > $str.e; # error, no such method
> > $str.key(::File);
> > $str.e; # works fine
> >
> > There should probably be a few standard methods that are imported in this
> > way such as e, s, z and any other test operators that are universal, so
> that
> > this makes sense:
> >
> > $user = get_user_name();
> > $user.key(::Getpw)
> > $user.e; # user exists?
> >
> > $url = "http://www.example.com/";;
> > $url.key(::URI);
> > $url.s > 0; # might do a HEAD request and return the size
> >
> > The rest might be more domain specific:
> >
> > $mailbox = "Trash";
> > $mailbox.key(::Mail::IMAP, $account_info);
> > $mailbox.msgs > 1000;
> >
> > In this way you have not enforced the assumption that all strings are
> > pathnames, but rather that all strings might be used as keys.
> >
> > I suppose this even makes sense, though it's convoluted:
> >
> > $hashkey = "Aaron";
> > $hashkey.key(::Hash, %names);
> > $hashkey.e
> >
> > The real beauty of this is that it can all be implemented without any
> > language syntax/grammar changes.
> >
>
> --
> Sent from my mobile device
>
> Mark J. Reed <markjr...@gmail.com>
>
