Re: META vs meta
David Brunton wrote: 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.
Re: META vs meta
Jonathan Scott Duff wrote:
On Wed, Sep 13, 2006 at 10:20:31AM +1200, Sam Vilain wrote:
Larry Wall wrote:
.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.
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.
Re: META vs meta
Aaron Sherman wrote: 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.
Re: META vs meta
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... 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.
Re: META vs meta
On Wed, Sep 13, 2006 at 10:20:31AM +1200, Sam Vilain wrote: 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 [EMAIL PROTECTED]
META vs meta
Hi all, 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.
Re: META vs meta
On Mon, Sep 11, 2006 at 08:59:51AM -0700, David Brunton wrote: : 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
Re: META vs meta
On 9/11/06, Larry Wall wrote: 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
Re: META vs meta
On Mon, Sep 11, 2006 at 10:59:20AM -0600, David Green wrote: : 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
Re: META vs meta
On Mon, Sep 11, 2006 at 09:18:19AM -0700, Larry Wall wrote: : .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
