META vs meta
David Brunton
There is currently a mismatch between S12 and Pugs. The former specifies $obj.META, the latter has implemented $obj.meta.
Is there any reason I shouldn't change the tests from meta to META, make the corresponding changes in Pugs.Prim, and then fix any other examples or modules it broke?
Am I missing anything else?
Best,
David.
Larry Wall
: Hi all,
:
: There is currently a mismatch between S12 and Pugs. The former specifies $obj.META, the latter has implemented $obj.meta.
.META is more correct at the moment.
: Is there any reason I shouldn't change the tests from meta to META, make the corresponding changes in Pugs.Prim, and then fix any other examples or modules it broke?
:
: Am I missing anything else?
Only that I'm thinking of renaming all the meta-ish methods to use
interrogative pronouns:
.META -> .HOW
.SKID -> .WHO
.PKG -> .WHAT
.VAR -> .WHERE
or some such. Not sure what .WHEN or .WHY would mean offhand...
Another possible scheme is to keep .META and have .WHO, .WHAT, etc. default
to .META.WHO, .META.WHAT, etc. (Delegated by Object, presumably.) Not sure
if the added flexibility of allowing override of bare .WHO etc. buys us
anything though.
Also, arguably VAR() is in a different category entirely. In which case
.WHERE might be the full package name, and .WHAT the short name.
Larry
David Green
>Only that I'm thinking of renaming all the meta-ish methods to use
>interrogative pronouns:
>
> .META -> .HOW
> .SKID -> .WHO
> .PKG -> .WHAT
> .VAR -> .WHERE
.WHO and .WHAT strike me as better being swapped. Maybe...
>or some such. Not sure what .WHEN or .WHY would mean offhand...
I'd say .WHY should return a chunk of POD representing the associated
documentation.
>Also, arguably VAR() is in a different category entirely. In which case
>.WHERE might be the full package name, and .WHAT the short name.
In that case, .WHO definitely makes more sense for the name.
-David
Larry Wall
: In that case, .WHO definitely makes more sense for the name.
I don't see it. Who I am is my identity. What I am is a Person or some such.
Larry
Larry Wall
: .PKG -> .WHAT
I should have said
.ref -> .WHAT
there, since it was the intention to rename .ref that brought all this
on in the first place. (And what you actually get from .WHAT is the
prototype object that stringifies to the package name.) In any case,
.ref is bogus in a language that "doesn't have references". Its use
as "typeof" in Perl 5 was something of an accident. And its boolean
use is bogus whether you view Perl 6 as mandating all references or
no references. Or however you say that in English...
Larry
Sam Vilain
> : There is currently a mismatch between S12 and Pugs. The former specifies $obj.META, the latter has implemented $obj.meta.
>
> .META is more correct at the moment.
>
Does making it all upper caps really help? It's still a pollution of the
method space, any way that you look at it...
What about this form:
#<meta> $o.?meta
#<ref> $o.?type
#<var> $o.?var
#<id> $o.?id
> Only that I'm thinking of renaming all the meta-ish methods to use
> interrogative pronouns:
>
> .META -> .HOW
> .SKID -> .WHO
> .PKG -> .WHAT
> .VAR -> .WHERE
>
Oo-er. Well, you're the linguist ;)
Sam.
Jonathan Scott Duff
> Larry Wall wrote:
> > : There is currently a mismatch between S12 and Pugs. The former specifies $obj.META, the latter has implemented $obj.meta.
> >
> > .META is more correct at the moment.
> >
>
> Does making it all upper caps really help? It's still a pollution of the
> method space, any way that you look at it...
Yeah but perl has already has a cultural claim on ALLCAPS thingys.
So, yes, it does help.
-Scott
--
Jonathan Scott Duff <du...@pobox.com>
Aaron Sherman
Is the goal to avoid namespace pollution? If so, shouldn't there be a
truly "metaish" way of getting at the internal namespace so that someone
doesn't accidentally render an object unusable by defining the wrong
method name (which you can prevent with an error if the object is
defined in Perl, but not if it's defined in Parrot or another language)?
Imagine this code:
class HTML4::Elements {
method H1 {...}
method P {...}
method META {...}
...
}
Worse, imagine accessing it through a Ruby or Python object. How would
you say, "this object has a real .META, please invoke it"? WHERE is even
stickier, since its use as an SQL keyword (case insensitive) makes
conflicts much more likely, and problematic.
There are dozens of ways that we could be explicit about digging into
internal namespace. Some would be syntactic:
$object\.meta (or \.how)
$object.*meta (or .*how)
Some would involve specifying the starting-point for dispatch:
$object.::meta (or .::how)
$object.Object::meta (or .Object::how)
I can think of more, and, I'm sure I'm incapable of thinking of all of
them. Simply spelling things strangely in order to avoid namespace
collisions ignores the fact that the current need is not unique, and any
solution you present should work well across objects from any language
source.
It should also probably be very clear when you are talking to the object
system vs. when you are talking to an object. $foo.META (or .HOW)
doesn't really make that as clear as I think it should be for code clarity.
Of course, you'll probably want to have a way to re-define the object
system itself, so you need to be able to say something like:
class X { method *meta($self:) { $self.MyOO::meta }
or
class X { method meta() is internal {...} }
IMHO, the golden rule of programming languages should be: if you need a
namespace, create one.
David Brunton
<replies snipped />
>Is the goal to avoid namespace pollution? If so, shouldn't there be a
>truly "metaish" way of getting at the internal namespace so that someone
>doesn't accidentally render an object unusable by defining the wrong
>method name (which you can prevent with an error if the object is
>defined in Perl, but not if it's defined in Parrot or another language)?
>Imagine this code:
<code snipped />
>IMHO, the golden rule of programming languages should be: if you need a
>namespace, create one.
IANAL (Linguist? Language-designer? Larry?), but...
Is there any reason these "meta" methods could not be part of some default function package like Math::Basic and Math::Trig? The package could be called Class::InterrogativePronouns, or Object::MetaModel, or ProgrammingLanguage::Pollution. And it could be loaded by default. Or not. That decision is far above my paygrade.
I know the names I proposed are silly, but the idea is worth thought, and it would obey Aaron's golden rule, above.
It might also make it a little more obvious to new folks like me where other kinds of introspection (I really can imagine WHENCE and WHITHER being useful) would be added in down the road.
Does anyone else have thoughts on this they'd be willing to share?
Best,
-db.
Aaron Sherman
> Aaron Sherman wrote: <replies snipped />
>> IMHO, the golden rule of programming languages should be: if you
>> need a namespace, create one.
> Is there any reason these "meta" methods could not be part of some
> default function package like Math::Basic and Math::Trig? The
> package could be called Class::InterrogativePronouns, or
> Object::MetaModel, or ProgrammingLanguage::Pollution. And it could
> be loaded by default. Or not. That decision is far above my
> paygrade.
[...]
> Does anyone else have thoughts on this they'd be willing to share?
Let me see if I understand. You are essentially asking, "why are these
metaish things special? Why aren't they just coming from a namespace
like everything else?"
The reason is two-fold (and they're good reasons):
1. The object system is built using these tools, so you cannot build
them using the object system without doing some very ugly kludging and
bootstrapping which we already have enough of to do.
2. As Larry points out in his documentation that you may or many not
have noticed he updated yesterday, these will be macros, and thus cannot
be dispatched at runtime.
Thus they MUST bypass the dispatch that the user might be expecting to
happen. The choices are thus:
* Let that override part of the user namespace (with workarounds that
Larry has suggested) or,
* Create some unique way to say "we're doing the metaish thing here, not
dispatch." That was the idea of $obj\.meta or $obj.*meta or whatever.
Larry seems to have made up his mind, and while I don't agree that his
is the best choice, sometimes making a choice is more important than
agreeing that it was the best one. Consensus is screwy that way ;)
Someone who is Larry should probably speak up if that doesn't make any
sense.