Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
> Date: Thu, 12 Dec 2002 16:26:28 -0500 > From: John Siracusa <[EMAIL PROTECTED]> > > On 12/12/02 4:01 PM, Larry Wall wrote: > > On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote: > > : So we'll _have_ to write $obj.*id when we mean $obj->UNIVERSAL::id; > > > > If you wish to be precise, yes. But $a.id eq $b.id should work for most any > > class that uses the the term "id" in the typical fashion. > > I still feel like we're talking past each other here. What I was saying is > that, regardless of any admonitions to the contrary, I think people will > still write this: > > $a.id == $b.id > > and expect it to compare memory addresses. And presumably, anyone who overrides .id in their own class knows what they're doing. They, in fact, I statements like that to behave that way. Junction, by delegation, will override that method to return a junction of the .ids of its states. Speaking of which, how do you code delegation? class Disjunction is Junction { has @.states is public; # ... # Use the class's AUTOLOAD? method AUTOLOAD($name, *@args) { any(map { $_.$name.(*@args) } @.states); } # Or use some kind of DELEGATE method, taking a curried # function with only the invocant left blank. method DELEGATE(&func) { any(map { $_.&func } @.states); } } I rather like the latter. Luke
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
> Date: Thu, 12 Dec 2002 17:07:21 -0800 > From: Larry Wall <[EMAIL PROTECTED]> > > It's not clear what .can should return for a multimethod, either. > You'd have be able to return results like: "yes int can mult, but > only if the second argument is an int or num". Basically, .can > has a bad syntax. We need a modifier on an ordinary multimethod > or subroutine call that says, "Go through all the motions of calling > this, but don't really." To do that kind of almost-dispatch you often > need the actual arguments, or something resembling them. One is tempted > to say that taking a reference to a function call with arguments > does something like this: > > \&Main::foo(1,3) > > The reference could be bound to the dispatch list, or be false if nothing > matched. Perhaps currying could be our aide: can(&foo.assuming(1, 3)); The only question is, what happens when not all the arguments are curried? Perhaps it could return true if the rest of the arguments matched any multimethod. So: can(&bar); Without any currying would be true if bar is a sub, and false if it isn't. I think that generalizes nicely. Luke
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On 12/12/2002 4:01 PM, Larry Wall wrote: On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote: : And what will: : : main.*can('foo') : : result in? These days it's "Main", not "main". And it's a module, not a class, so probably it fails, unless someone can think of something useful for it to mean. It would, logicaly, mean that the class Module has a method "foo" if true -- applying can on an object tells you if the class of that object can do somthing, and Main is an object of class Module... right? (%Main:: is a hash, but Main (bareword) is an object, no?) -=- James Mastros
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On Thu, Dec 12, 2002 at 01:50:37PM -0800, Brent Dax wrote: : Larry Wall: : # Hmm. Those don't really stand out enough. Maybe we should go with : # OBJECT:: and GLOBAL:: just for a little more visual punch. : : How about CORE:: instead of GLOBAL::? This helps stick with tradition : and minimize the number of reserved packages. I don't like the Perl 5 tradition on top-level namespaces. First of all, nobody really knows what core means anymore. Is it just the built-in opcodes? Is it the functions that come with the distribution? Neither of those map onto Perl 5 concept of CORE:: anymore. So Perl 6 doesn't have a CORE:: anymore. What used to be in CORE goes into "*", whever that means. Second, in Perl 5 there are two global namespaces apart from CORE::. If you say $::foo, you get $main::foo. If you say $STDIN, you get some other namespace that has no name in Perl 5. In Perl 6, the latter truly global namespace is combined with CORE to get what "main" was trying to be in Perl 5. The former "main" namespace is no longer intended to be used for globals, and the $::foo syntax is no longer supported for that purpose. The translator will translate $::foo to $Main::foo. So $*IN really is considered to be in the global namespace, not in the core namespace. You might argue that "stdin" is "core" in some sense, but all global names go into "*", not just built-ins. This includes all user-defined package names. So the real name of package Foo is GLOBAL::Foo. It's not Main::Foo, nor is it CORE::Foo. It's short name isn't ::Foo, but *Foo. And you can just call it Foo because the search for identifiers ends in GLOBAL (except for methods, for which the search ends in OBJECT). : # : And what will: : # : : # : main.*can('foo') : # : : # : result in? : # : # These days it's "Main", not "main". And it's a module, not a : # class, so probably it fails, unless someone can think of : # something useful for it to mean. : : I'd hope that Perl would allow me to do something like that to see if : Main::foo exists... Ordinarily you'd test for subs with one of exists &Main::foo &Main::foo.exists As to whether .can should work for that, it should depend on whether it's possible to invoke "foo" as a method in Main. This may or may not be the same thing as having a "sub" declaration named "foo". Certainly classes will distinguish subs from methods. It may be that modules will too, and you'd have to write "package Main" to get Perl to confuse them like Perl 5 does. But that's not decided yet. It's not clear what .can should return for a multimethod, either. You'd have be able to return results like: "yes int can mult, but only if the second argument is an int or num". Basically, .can has a bad syntax. We need a modifier on an ordinary multimethod or subroutine call that says, "Go through all the motions of calling this, but don't really." To do that kind of almost-dispatch you often need the actual arguments, or something resembling them. One is tempted to say that taking a reference to a function call with arguments does something like this: \&Main::foo(1,3) The reference could be bound to the dispatch list, or be false if nothing matched. Except that syntax currently means something else, and doesn't work for method calls. Maybe it's a good place for a question mark: &Main::foo?(1,3) $foo.bar?(3) and maybe even $x +? $y It's vaguely possible this should be unified with currying if the construct actually returns a reference with prebound arguments. It's also possible that it's not visible enough, and we should say splashy like: can { &Main::foo(1,3) } can { $foo.bar(3) } can { $a + $y } Exactly how much can-{} should do without doing anything is left as an exercise for the reader. What would it do with this: can { $a + $y + snort() } I suppose one could set up a transactional structure in which "can" actually does the side effects hypothetically, with the option of committing later. Sort of what a "try" block would like to be when it grows up... Larry
RE: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
Larry Wall: # Hmm. Those don't really stand out enough. Maybe we should go with # OBJECT:: and GLOBAL:: just for a little more visual punch. How about CORE:: instead of GLOBAL::? This helps stick with tradition and minimize the number of reserved packages. # : And what will: # : # : main.*can('foo') # : # : result in? # # These days it's "Main", not "main". And it's a module, not a # class, so probably it fails, unless someone can think of # something useful for it to mean. I'd hope that Perl would allow me to do something like that to see if Main::foo exists... --Brent Dax <[EMAIL PROTECTED]> @roles=map {"Parrot $_"} qw(embedding regexen Configure) "If you want to propagate an outrageously evil idea, your conclusion must be brazenly clear, but your proof unintelligible." --Ayn Rand, explaining how today's philosophies came to be
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On 12/12/02 4:01 PM, Larry Wall wrote: > On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote: > : So we'll _have_ to write $obj.*id when we mean $obj->UNIVERSAL::id; > > If you wish to be precise, yes. But $a.id eq $b.id should work for most any > class that uses the the term "id" in the typical fashion. I still feel like we're talking past each other here. What I was saying is that, regardless of any admonitions to the contrary, I think people will still write this: $a.id == $b.id and expect it to compare memory addresses. That is not the "typical fashion" for an object method named "id" to work, IMO. The need to compare memory addresses is so infrequent that warrants a much less common and/or longer method name than "id". -John
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote: : John Siracusa wrote: : > On 12/12/02 12:55 PM, Larry Wall wrote: : > > As for namespace pollution and classes that use .id in Perl 5, I : > > don't think it's going to be a big problem. Built-in identifiers : > > do not have a required prefix, but they have an optional prefix, : > > which is C<*>. I think we can probably parse : > > : > > $a.*id == $b.*id : > > : > > if you really need to get to Object.id(). : > : > That'll only work out if everyone always writes it as "*id". : > If not, my Perl 6 objects that override "id()" won't work correctly : > with any other classes or functions that simply call "id" and : > expect it to really be "*id" : : yes... : : So we'll _have_ to write $obj.*id when we mean $obj->UNIVERSAL::id; If you wish to be precise, yes. But $a.id eq $b.id should work for most any class that uses the the term "id" in the typical fashion. : I'm not sure I understand what Larry means by "most-global"... Do you mean : outer-most scope, root-of-method-inheritence, or both? It's context dependent, just as the meaning of an identifier is context dependent. In this case, it means root-of-method-inheritance, that is, Object. (That is tne new name of UNIVERSAL.) So $a.*id is short for $a.Object::id. But $*foo is short for $Global::foo or some such. : And what of the case we someone does want to explicitly override a "builtin" : method like UNIVERSAL::can? What is the Perl6 equivalent to: : : *UNIVERSAL::can = sub { print qq{hello\n} }; : sub foo {}; : print main->can('foo')"; Any of: method Object::can ($meth) { print qq[hello\n] } or &*can := method ($meth) { print qq[hello\n] }; or &Object::can ::= sub ($object, $method) { print qq[hello\n] }; Hmm. Those don't really stand out enough. Maybe we should go with OBJECT:: and GLOBAL:: just for a little more visual punch. : And what will: : : main.*can('foo') : : result in? These days it's "Main", not "main". And it's a module, not a class, so probably it fails, unless someone can think of something useful for it to mean. : Larry Wall wrote: : > : > I'd almost be tempted to argue that if push comes to shove, it's : > the list splat star that gets shoved. : : Don't you suspect the list splat will be more common than most-global? That's why I said "almost". Larry
RE: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
John Siracusa wrote: > On 12/12/02 12:55 PM, Larry Wall wrote: > > As for namespace pollution and classes that use .id in Perl 5, I > > don't think it's going to be a big problem. Built-in identifiers > > do not have a required prefix, but they have an optional prefix, > > which is C<*>. I think we can probably parse > > > > $a.*id == $b.*id > > > > if you really need to get to Object.id(). > > That'll only work out if everyone always writes it as "*id". > If not, my Perl 6 objects that override "id()" won't work correctly > with any other classes or functions that simply call "id" and > expect it to really be "*id" yes... So we'll _have_ to write $obj.*id when we mean $obj->UNIVERSAL::id; I'm not sure I understand what Larry means by "most-global"... Do you mean outer-most scope, root-of-method-inheritence, or both? And what of the case we someone does want to explicitly override a "builtin" method like UNIVERSAL::can? What is the Perl6 equivalent to: *UNIVERSAL::can = sub { print qq{hello\n} }; sub foo {}; print main->can('foo')"; And what will: main.*can('foo') result in? Larry Wall wrote: > > I'd almost be tempted to argue that if push comes to shove, it's > the list splat star that gets shoved. Don't you suspect the list splat will be more common than most-global?