Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Larry Wall <[EMAIL PROTECTED]> wrote: > $x is visible only in the rest of the lexical scope. In contrast, > $_y would presumably still be visible if the class were reopened. This strikes me as an exceedingly bad idea. Encapsulation is a very good thing, and I'm glad it's being added to Perl 6. But once in a while, you really *do* need to break encapsulation. Maybe a shortsighted module author didn't add an accessor you need, or maybe you're doing something highly magical for (e.g.) debugging. In any case, though, you'll need an escape hatch, and I really think extending a class should be it. By extending a class, you're explicitly saying "I'm going to butt into your affairs"; at this point, if you're not sure what you're doing, you're probably going to mess things up *anyway*. (If not this, I at least would like to see a way to make roles and/or class extensions optionally merge their namespace with the class they're being composed into; a simple 'is merged' on the role/extension's definition might do.) Also note how subtle this point is (it's about the only point I didn't get from the original message); the degree to which it requires the class's programmer to predict how others might want to extend his class; and the syntactic kludge required to specify it (namely, the sometimes-magical underscore). I really think this is a very fine distinction, which programmers will get wrong half the time, and which you don't even have enough syntax to cope with *anyway*. -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Larry,
On Jul 21, 2005, at 8:07 PM, Larry Wall wrote:
On Thu, Jul 21, 2005 at 05:15:34PM -0400, Stevan Little wrote:
: This means that Roles are now first-class-ish things. Meaning they
: cannot just simply be composed into classes since now we have to
keep a
: table of elements which are private to a Role.
Well, we've kinda been squinting at that issue from both ends for a
while now, and there's something in both views.
Yes, we have. One thing to consider is that it is much easier to get
the "Role order doesn't matter" thing when they are composed. Once you
start keeping the roles around, you run into the possiblity for such
things as "next METHOD" being executed in Role context. I wont even
speculate on what that should/could/would do, because I think we just
shouldn't go there.
: On Jul 21, 2005, at 2:48 PM, Larry Wall wrote:
: >* All roles can write their shared attributes as $.x and not
worry
: > about whether the class declares them or not.
:
: I assume they need not worry because we can rely on conflict
resolution
: to deal with most issues? Or are you thinking something different?
No, that's correct. We've just basically said that $.x is now a method
call, and as long as you stick to that invocation syntax it just has
to be declared as a method somewhere in the parentage/role-age of
this object. But collisions in $.x declaration will be treated as
collisions in method declaration.
So we really are looking at closure based access to attributes. This
also means that the idea behind P6Opaque as a storage format is very
different. In theory, we could implement these style classes in a very
"Inside-Out" manner. In a way, we could look at:
has $.x is rw;
as being sugar for this (pseudo) Perl 6:
{
my %x;
$?CLASS.meta.add_method('x' => method ($self: ?$value) {
%x{$self.id} = $value if $value.defined;
%x{$self.id};
});
}
Hmmm, it's a good thing I just got a book on CLOS metaobjects :)
: >* All roles can write completely private $x attributes that are
not
: > visible outside their lexical scope but are nevertheless
: > per-instance.
:
: So the Role's scope is preserved here, as opposed to pushing $x into
: the classes scope. Correct?
My notion is that $x (the name proxy) is stored in the lexical scope
of the closure that just happens to be the closure for the role,
rather than keeping a name proxy in the package. In either case,
$x or $.x is not a real variable, but a placeholder for a particular
slot in the object. The actual proxy could be stored in the role's
package if that makes it easier to keep track of, but I'd like the
scoping of the name to be lexical like an "our" in that case. But if
we can figure out how to store it more like a "my" variable but still
figure out which slot it maps to when instantiated, that might be cool.
Unfortunately, it could map to different slots in different objects,
so the class in question would have to keep track of where
MyRole::('$x')
actually maps to.
It's certainly possible that this notion doesn't really map terribly
well onto roles.
Well, if we ditch the P6Opague type (as we currently know it) and use
the Inside-Out method I show above. Then we just don't actually have
class/instance attributes anymore at all. We really just have methods,
some of which happen to be closures around per-instance values. Of
course this means there is no direct access to attributes at all (which
I think it not a bad thing, but I am into B&D like that).
Hmmm, I kind of like the smell of this.
: This would
: make it difficult to compose role methods into the method table
without
: bringing along a lot of meta-info about from whence they came. It is
: doable I think, but adds some complexity for which I am not sure the
: cost outweighs the benefits.
Ok, I will respond to myself here:
No Stevan, that is silly, if it is closure-based Inside-Out
thinga-mah-bobs, then we don't have to keep meta-context-info around,
the closure does that for us. Duh!
But I like the $x/$.x distinction for classes, since it encourages
people to write completely private attributes to begin with, and
then maybe take the step of adding a dot when the want to provide
an accessor.
I agree, private should be encouraged.
*sniff* *sniff* this is smelling better and better :)
Stevan
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
> I'm not married to the colon. Speaking of traits and adverbs, why not use
> one of those in the "has" declaration instead? That'd certainly be a lot
> more explicit than the magic leading underscore (although I'm at a loss as
> to what the trait would be named...)
I'd like to see an "is private" trait used for this purpose. This
could be used in the "has" declaration alongside the existing "is rw"
and company, possibly in method declarations as well, like so:
method foo() is private {...}
I may have missed a previous debate over this in the past, but this
seems a lot more natural to me than a magical leading underscore.
Collin Winter
Re: Tail method calls, can(), and pre-currying
On 21/07/05, Adriano Ferreira <[EMAIL PROTECTED]> wrote: > But is there any other case where we need an explicit tail call with "goto"? When the callee uses `caller -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Brent, On Jul 22, 2005, at 3:53 AM, Brent 'Dax' Royal-Gordon wrote: (If not this, I at least would like to see a way to make roles and/or class extensions optionally merge their namespace with the class they're being composed into; a simple 'is merged' on the role/extension's definition might do.) Actually Roles actually do merge into the class's namespace. This is the key to the flattening aspect of Roles. Although how much of their namespace they bring along with them is still undetermined (sorta). Stevan
Re: Tail method calls, can(), and pre-currying
On Fri, Jul 22, 2005 at 07:04:24AM -0700, Brent 'Dax' Royal-Gordon wrote: : On 21/07/05, Adriano Ferreira <[EMAIL PROTECTED]> wrote: : > But is there any other case where we need an explicit tail call with "goto"? : : When the callee uses `caller Which we may not know, especially if we're tail-calling into something that hasn't been compiled yet. But I think the default should be to assume that the callee doesn't use caller, and then maybe have some trait or pragma that overrides that default if we want to pessimize. In any event, many uses of caller probably want to skip the middleman anyway, and even more uses of "want". It's the debugger that wishes the tail-call optimization didn't exist... Larry
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On Fri, Jul 22, 2005 at 07:35:30AM -0500, Collin Winter wrote:
: > I'm not married to the colon. Speaking of traits and adverbs, why not use
: > one of those in the "has" declaration instead? That'd certainly be a lot
: > more explicit than the magic leading underscore (although I'm at a loss as
: > to what the trait would be named...)
:
: I'd like to see an "is private" trait used for this purpose. This
: could be used in the "has" declaration alongside the existing "is rw"
: and company, possibly in method declarations as well, like so:
:
: method foo() is private {...}
:
: I may have missed a previous debate over this in the past, but this
: seems a lot more natural to me than a magical leading underscore.
Well, yes, most people missed that debate, because it was mostly done
on whiteboards in secret meetings of the cabal. (There is no cabal.)
The problem I have with "is private" is that, while there may very
well be a trait of that name that you can interrogate, I really
want people to think of the private methods as being in a different
namespace so that there's no confusion about the fact that you can
have a private method and a public method of the same name. And the
reason I want that is because I strongly believe that private methods
must be absolutely invisible to the public interface, and confusing
the namespaces puts you in a situation where adding a private method
can clobber public inheritance of the same name.
Even worse, it clobbers your private interface. As soon as you say
method foo() is private {...}
then you can't call $?SELF.foo() and expect to get the public .foo method.
Putting the difference as part of the name forces people to distinguish
$?SELF.foo()
$?SELF._foo()
on the call end. And the _ has the advantage of being *perceived* as
part of the name. The problem with
$?SELF.:foo()
is that people see that as a .: operator on the foo method.
Larry
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On 7/22/05 11:37 AM, Larry Wall wrote:
> The problem I have with "is private" is that, while there may very
> well be a trait of that name that you can interrogate, I really
> want people to think of the private methods as being in a different
> namespace so that there's no confusion about the fact that you can
> have a private method and a public method of the same name.
Er, but can you ever have a public method that begins with an underscore
under your new system? If not, then there'd never be any of the overlap
that you want people not to be confused about. See, now I'm confused...
I get this part:
> The problem with
>
> $?SELF.:foo()
>
> is that people see that as a .: operator on the foo method.
and like I said, I'm not insistent on using the colon. But I would like to
find a way to remove the proposed contextual magic of the leading underscore
and replace it with something a bit more explicit and obvious--in both the
calling syntax and the declaration syntax.
So, the problem looks like this. We want to find a way to:
* Define a private rw attribute named "foo" with an auto-generated
non-virtual accessor.
* Define a public rw attribute named "foo" with an auto-generated
virtual accessor.
* Call both of the accessors above with no ambiguity between the calls,
even though both attributes have the same name.
The proposed solution:
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor.
has $_foo;
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor.
has $.foo is rw;
# Call both of the accessors above with no ambiguity between the calls,
# even though both attributes have the same name.
$?SELF._foo(); # private accessor
$?SELF.foo(); # public accessor
kind of sidesteps the "same name" issue by, well, not giving both the
attributes the same name. Instead of two attributes both named "foo", the
private one is now named "_foo". This makes the accessor calls unambiguous,
but it doesn't really succeed in emphasizing the separateness of the private
and public namespaces.
Since my goal is to remove the "_" magic, I first have to find a way to
differentiate a "private rw attribute with an auto-generated non-virtual
accessor" from a "private rw attribute with no auto-generated accessor." I
proposed some sort of trait for that earlier:
# private rw, no accessors, not virtual, name lexically scoped
has $foo;
# private rw, rw accessor, not virtual, name class scoped
has $foo is private;
where the "private" name is up for grabs. Or it could be turned around:
has private $foo;
The next problem to solve is how to differentiate the calls. The colon is
out because it looks like an operator. The attribute names are really both
"foo", so we can't use the accessor name itself to differentiate.
But both those two "foo"s are in separate namespaces, right? That's why we
can have both of them in the same class. So how do we indicate the
namespace separation in the call? In the spirit of the (now dead?) SUPER::
from Perl 5, this immediately springs to mind:
$?SELF.foo(); # public
$?SELF.PRIVATE::foo(); # private
That's ugly and long, but at least it's clear. And it doesn't look like an
operator, that's for sure. How about some shorter alternatives:
$?SELF.OWN::foo();
$?SELF.MY::foo();
The bottom line, I think, is that if you really want private and public
accessors to live in totally different namespaces, you need to explicitly
namespace one or both of the calls. Name mangling isn't enough. For
example, imagine this:
# private rw, no accessors, not virtual, name lexically scoped
has $foo;
# private rw, rw _foo accessor, not virtual, name class scoped
has $foo is private;
$?SELF.foo(); # public
$?SELF._foo(); # private
A silly example, perhaps, but it does make two attributes both named "foo",
one public and one private. The calls are disambiguated because the
auto-generated non-virtual accessor for the private attribute has a leading
underscore added to the actual attribute name--IOW, name mangling. But now
look at this:
# private rw, no accessors, not virtual, name lexically scoped
has $foo;
# private rw, rw _foo accessor, not virtual, name class scoped
has $foo is private;
has $._foo; # BOOM - compile-time error: method _foo() already exists
method _foo { ... } # ditto
"Ah ha!" you say. "Isn't that an example of the private interface
interfering with the public interface?" Exactly--but AFAICT, the original
proposal suffers from the same problem!
# private rw, no accessors, not virtual, name lexically scoped
has $foo;
# private rw, rw _foo accessor, not virtual, name class scoped
has $_foo;
has $._foo; # BOOM - compile-time error: method _foo() already exists
method _foo { ... } # ditto
The point is, if you really want to the namespaces of the public and private
attribute acces
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Ack, I screwed up that last email with some bad copy and paste. Ignore it
in favor of this one please :)
---
On 7/22/05 11:37 AM, Larry Wall wrote:
> The problem I have with "is private" is that, while there may very
> well be a trait of that name that you can interrogate, I really
> want people to think of the private methods as being in a different
> namespace so that there's no confusion about the fact that you can
> have a private method and a public method of the same name.
Er, but can you ever have a public method that begins with an underscore
under your new system? If not, then there'd never be any of the overlap
that you want people not to be confused about. See, now I'm confused...
I get this part:
> The problem with
>
> $?SELF.:foo()
>
> is that people see that as a .: operator on the foo method.
and like I said, I'm not insistent on using the colon. But I would like to
find a way to remove the proposed contextual magic of the leading underscore
and replace it with something a bit more explicit and obvious--in both the
calling syntax and the declaration syntax.
So, the problem looks like this. We want to find a way to:
* Define a private rw attribute named "foo" with an auto-generated
non-virtual accessor.
* Define a public rw attribute named "foo" with an auto-generated
virtual accessor.
* Call both of the accessors above with no ambiguity between the calls,
even though both attributes have the same name.
The proposed solution:
# Define a private rw attribute with an auto-generated
# non-virtual accessor.
has $_foo;
# Define a private rw attribute with an auto-generated
# non-virtual accessor.
has $.foo is rw;
# Call both of the accessors above with no ambiguity between the calls,
# even though both attributes have the same name.
$?SELF._foo(); # private accessor
$?SELF.foo(); # public accessor
kind of sidesteps the "same name" issue by, well, not giving both the
attributes the same name. Instead of two attributes both named "foo", the
private one is now named "_foo". This makes the accessor calls unambiguous,
but it doesn't really succeed in emphasizing the separateness of the private
and public namespaces.
Since my goal is to remove the "_" magic, I first have to find a way to
differentiate a "private rw attribute with an auto-generated non-virtual
accessor" from a "private rw attribute with no auto-generated accessor." I
proposed some sort of trait for that earlier:
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor.
has $.foo is rw;
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor.
has $foo is private rw;
where the "private" name is up for grabs. Or it could be turned around:
has private $foo;
The next problem to solve is how to differentiate the calls. The colon is
out because it looks like an operator. The attribute names are really both
"foo", so we can't use the accessor name itself to differentiate.
But both those two "foo"s are in separate namespaces, right? That's why we
can have both of them in the same class. So how do we indicate the
namespace separation in the call? In the spirit of the (now dead?) SUPER::
from Perl 5, this immediately springs to mind:
$?SELF.foo(); # public
$?SELF.PRIVATE::foo(); # private
That's ugly and long, but at least it's clear. And it doesn't look like an
operator, that's for sure. How about some shorter alternatives:
$?SELF.OWN::foo();
$?SELF.MY::foo();
The bottom line, I think, is that if you really want private and public
accessors to live in totally different namespaces, you need to explicitly
namespace one or both of the calls. Name mangling isn't enough. For
example, imagine this:
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor named "_foo"
has $foo is private rw;
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor named "foo"
has $.foo is rw;
$?SELF.foo(); # public
$?SELF._foo(); # private
A silly example, perhaps, but it does make two attributes both named "foo",
one public and one private. The calls are disambiguated because the
auto-generated non-virtual accessor for the private attribute has a leading
underscore added to the actual attribute name--IOW, name mangling. But now
look at this:
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor named "_foo"
has $foo is private rw;
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor named "foo"
has $.foo is rw;
has $._foo; # BOOM - compile-time error: method _foo() already exists
method _foo { ... } # ditto
"Ah ha!" you say. "Isn't that an example of the private interface
interfering with the public interface?" Exactly--but AFAICT, the original
proposal suffers from the same problem!
# Define a private rw
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On Fri, Jul 22, 2005 at 12:53:45AM -0700, Brent 'Dax' Royal-Gordon wrote: : Larry Wall <[EMAIL PROTECTED]> wrote: : > $x is visible only in the rest of the lexical scope. In contrast, : > $_y would presumably still be visible if the class were reopened. : : This strikes me as an exceedingly bad idea. : : Encapsulation is a very good thing, and I'm glad it's being added to : Perl 6. But once in a while, you really *do* need to break : encapsulation. Maybe a shortsighted module author didn't add an : accessor you need, or maybe you're doing something highly magical for : (e.g.) debugging. In any case, though, you'll need an escape hatch, : and I really think extending a class should be it. By extending a : class, you're explicitly saying "I'm going to butt into your affairs"; : at this point, if you're not sure what you're doing, you're probably : going to mess things up *anyway*. With sufficient work it will almost certainly be possible to excavate the lexical scope of the class and get back to the $x proxy somehow. We are under no obligation to make that easy, however. : Also note how subtle this point is (it's about the only point I didn't : get from the original message); the degree to which it requires the : class's programmer to predict how others might want to extend his : class; and the syntactic kludge required to specify it (namely, the : sometimes-magical underscore). I really think this is a very fine : distinction, which programmers will get wrong half the time, and which : you don't even have enough syntax to cope with *anyway*. It's almost certainly the case that ordinary programs will ignore the $_x option in most cases. The default submethods will manage $_x as the "backing store" for $.x transparently. Only if you want to write your own BUILD or want to "trust" other classes will you have to deal much with the $_x form, and neither of those are exactly newbie pursuits. In any event, the fact that reopened class scopes can see $_x is just sort of an accident of being associated with $.x, since the $.x name (or at least the .x name) has to be stored in the class's package. Even reopened classes should probably prefer $.x over $_x except in those cases where explicit de-virtualization is necessary. But as usual, I'm seeing these issues sideways to everyone else, which means I could certainly be blind to something that's obvious to others. Hmm, would it help if the devirtualized form were $._x instead of $_x? Perhaps that shows the relationship better. (It would still imply that _x is the corresponding private method, of course). But it would further discourage people from by default declaring all their private variables as $._foo, which is probably a good thing. It would also make _ no longer a kind of pseudo-twigil, and create a symmetry between $._foo and $obj._foo. Then then . twigil is *the* mark of a self-call. Larry
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Third time's the charm...really. Please ignore the last two messages from
me in favor of this one please. Sigh**2.
---
On 7/22/05 11:37 AM, Larry Wall wrote:
> The problem I have with "is private" is that, while there may very
> well be a trait of that name that you can interrogate, I really
> want people to think of the private methods as being in a different
> namespace so that there's no confusion about the fact that you can
> have a private method and a public method of the same name.
Er, but can you ever have a public method that begins with an underscore
under your new system? If not, then there'd never be any of the overlap
that you want people not to be confused about. See, now I'm confused...
I get this part:
> The problem with
>
> $?SELF.:foo()
>
> is that people see that as a .: operator on the foo method.
and like I said, I'm not insistent on using the colon. But I would like to
find a way to remove the proposed contextual magic of the leading underscore
and replace it with something a bit more explicit and obvious--in both the
calling syntax and the declaration syntax.
So, the problem looks like this. We want to find a way to:
* Define a private rw attribute named "foo" with an auto-generated
non-virtual accessor.
* Define a public rw attribute named "foo" with an auto-generated
virtual accessor.
* Call both of the accessors above with no ambiguity between the calls,
even though both attributes have the same name.
The proposed solution:
# Define a private rw attribute with an auto-generated
# non-virtual accessor.
has $_foo;
# Define a public rw attribute with an auto-generated
# virtual accessor.
has $.foo is rw;
# Call both of the accessors above with no ambiguity between the calls,
# even though both attributes have the same name.
$?SELF._foo(); # private accessor
$?SELF.foo(); # public accessor
kind of sidesteps the "same name" issue by, well, not giving both the
attributes the same name. Instead of two attributes both named "foo", the
private one is now named "_foo". This makes the accessor calls unambiguous,
but it doesn't really succeed in emphasizing the separateness of the private
and public namespaces.
Since my goal is to remove the "_" magic, I first have to find a way to
differentiate a "private rw attribute with an auto-generated non-virtual
accessor" from a "private rw attribute with no auto-generated accessor." I
proposed some sort of trait for that earlier:
# Define a public rw attribute with an auto-generated
# virtual accessor.
has $.foo is rw;
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor.
has $foo is private rw;
where the "private" name is up for grabs. Or it could be turned around:
has private $foo;
The next problem to solve is how to differentiate the calls. The colon is
out because it looks like an operator. The attribute names are really both
"foo", so we can't use the accessor name itself to differentiate.
But both those two "foo"s are in separate namespaces, right? That's why we
can have both of them in the same class. So how do we indicate the
namespace separation in the call? In the spirit of the (now dead?) SUPER::
from Perl 5, this immediately springs to mind:
$?SELF.foo(); # public
$?SELF.PRIVATE::foo(); # private
That's ugly and long, but at least it's clear. And it doesn't look like an
operator, that's for sure. How about some shorter alternatives:
$?SELF.OWN::foo();
$?SELF.MY::foo();
The bottom line, I think, is that if you really want private and public
accessors to live in totally different namespaces, you need to explicitly
namespace one or both of the calls. Name mangling isn't enough. For
example, imagine this:
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor named "_foo"
has $foo is private rw;
# Define a public rw attribute named "foo" with an auto-generated
# virtual accessor also named "foo"
has $.foo is rw;
$?SELF.foo(); # public
$?SELF._foo(); # private
A silly example, perhaps, but it does make two attributes both named "foo",
one public and one private. The calls are disambiguated because the
auto-generated non-virtual accessor for the private attribute has a leading
underscore added to the actual attribute name--IOW, name mangling. But now
look at this:
# Define a private rw attribute named "foo" with an auto-generated
# non-virtual accessor named "_foo"
has $foo is private rw;
# Define a public rw attribute named "foo" with an auto-generated
# virtual accessor also named "foo"
has $.foo is rw;
has $._foo; # BOOM - compile-time error: method _foo() already exists
method _foo { ... } # ditto
"Ah ha!" you say. "Isn't that an example of the private interface
interfering with the public interface?" Exactly--but AFAICT, the original
proposal suffers from the same problem!
# Define a private rw attribute w
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Larry Wall wrote:
The problem I have with "is private" is that, while there may very
well be a trait of that name that you can interrogate, I really
want people to think of the private methods as being in a different
namespace so that there's no confusion about the fact that you can
have a private method and a public method of the same name. And the
reason I want that is because I strongly believe that private methods
must be absolutely invisible to the public interface, and confusing
the namespaces puts you in a situation where adding a private method
can clobber public inheritance of the same name.
Even worse, it clobbers your private interface. As soon as you say
method foo() is private {...}
then you can't call $?SELF.foo() and expect to get the public .foo method.
Putting the difference as part of the name forces people to distinguish
$?SELF.foo()
$?SELF._foo()
on the call end. And the _ has the advantage of being *perceived* as
part of the name.
I start to understand the problem I have with perceiving this.
You think of the name ::foo beeing looked up somehow *in* the object
you want to call on, while I always assumed that the name ::foo is
looked up first. In a method invocation expression this lookup has
to yield a method implementation that has got an invocant type that
is compatible with the one the caller wants to put in.
If ::foo shall not be visible why not arrange for the lookup to fail?
Failing *look*up and invisibility are---linguistically spoken---very
related concepts, or not?
This method-first approach has the added benefit that anyone can place
a compatible method into a lexically closer scope than the one they want
to overwrite. If the closeness still prevents the call because of lacking
specificity a simple
temp $object does MyStuff;
and a method in scope that is specialized on .does(MyStuff) hardly leaves
outsiders a chance to prevent the dispatch! The same thing without temp
might be construed as anti-social by whomever gave you $object ;)
The otherway round should look more like $?SELF<&foo>() or SELF::foo().
Hmm, and nullary .<&foo> performs the lookup on $_ or some such. Honestly
I don't understand why the vtbl implementation detail of e.g. C++ is
taken as template for Perl6 SMD OO.
Private methods of an object come into play because the dispatch of
a publicly visible method is called. The private method must be in
scope there. The only requirement on the name is to not leak out into
public namespace.
The problem with
$?SELF.:foo()
is that people see that as a .: operator on the foo method.
Which is a *BIG* problem in an Operator Oriented Language!
--
TSa (Thomas Sandlaß)
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Larry Wall wrote:
$x is visible only in the rest of the lexical scope. In contrast,
$_y would presumably still be visible if the class were reopened.
Which brings me to the question how the name information is told
to a prospective user if the source code of the the first definition
shall not be disclosed. I mean of course there is the documentation
but I thought more of a machine readable form. Some kind of a interface
definition of a package.
: # or does class scope mean shared by all instances
: # and lexically scopes per instance?
Class scope is basically package scope. For instance attributes and
methods the package contains proxies representing the slots in the
actual instance.
Sorry, this proxy is the invocant, right? And the type system ensures
compatibility to the methods expectations. This is to me the whole point
in the method call procedure: to bind the invocant to the variables of
the method with respect to the invocant. Since variables in Perl6 code
bear one of the four sigils &Code, $Item, @Array and %Hash this binding
to the invocant is simply indicated by the . twigil and supervised by
the type system.
Sure, if you want to declare an attribute containing a code reference.
But & doesn't have much to do with the call syntax in any event,
whether you're calling subs or methods. You can declare an attribute
as &.foo and call it as $.foo without a problem, since it's just
$?SELF.foo() either way, and the accessor methods are not associated
with sigils. I think $.foo and &.foo are synonymous as attributes,
except insofar as we can probably deduce that &.foo is dealing with
a sub ref and not just any old scalar value.
Sorry, I meant the & sigil as generic Code type markup which includes
in particular methods on behalf of the invocant. Actually I see no
point in assuming sub ref for &. but a ref to a method with the
invocant type as specializer. The type information for an object that
is blessed into a type comes of course from just the artifact from
the blessing, however it is retrieved from the invocant.
So with these two things at hand a method invocation can be spawned:
1) the invocant ref
2) a method ref
All referential expressions in the code block of the method are
bound according to the runtime representation of the object in that
moment.
: >* All roles can write completely private $x attributes that are not
: > visible outside their lexical scope but are nevertheless
: > per-instance.
:
: I understand that correctly, that $x in
:
:role Foo { has $x = 7; method foo { $x++ } }
:
: denotes a reference to an Item from the data environment of the object
: that foo is invoked on.
I don't know what you mean by "data environment". The second
occurrence of $x denotes the generic proxy declared by the "has"
that represents an eventual slot in the actual instance. This slot
presumably has no other obvious name to any other role or to the
class that composes this role, though presumably there's an internal
way to get back from a particular slot to the slot's metadata, which
presumably knows which role supplied the definition.
With "data environment" I mean the stuff reachable through the invocant.
The actual type of the invocant and the method's formal invocant type
specify what is available through the link as long as the invocation
persists.
: The type of the $?SELF that Foo is composed into
: obviously is a subtype of Foo. What happens with this hidden payload if
: the object changes its type such that it is no Foo anymore? E.g. by
: undefining the slot &.Foo::foo?
Um, people who undefine functions that are going to be called later get
what they deserve. As for what happens to $x's slot in the absence
of the lexical reference from &Foo::foo, I expect the metadata would
still have pointers to it so it wouldn't necessarily be reclaimed
unless you told the object that is "undoes" Foo. Or to look at it
another way, all the objects that "do" Foo have a closure over that
$x proxy, so it's not going to go away until everyone forgets about
the Foo role itself.
Ups, I hoped that the type system would find out mismatches of the
objects actual structure and the methods expectations of it. Essentially
rendering the method in question not applicable to the object anymore.
BTW, what is the inverse operation of bless? Expel?
--
TSa (Thomas Sandlaß)
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On Fri, 2005-07-22 at 20:35 +0200, "TSa (Thomas Sandlaß)" wrote: > Ups, I hoped that the type system would find out mismatches of the > objects actual structure and the methods expectations of it. Essentially > rendering the method in question not applicable to the object anymore. I'm not sure that scanning every active object at every sequence point is feasable in the face of rand() and AUTOMETH(). At some point I'm willing to say that if you lie about what your classes can do and someone catches you, you'll suffer the consequences. -- c
Re: DBI v2 - Data In and Data Out
John Williams schrieb:
The proposals so far have dealt mostly with the SQL itself, and
supporting database-neutral layers on top of DBI.
Personally, I don't mind writing the SQL myself, I rarely need to make
a particular statement work on two databases in my work, and I can
optimize a lot better than any SQL generator.
I like DBI shortcuts (selectrow_array, etc), and I would like them
to become even more convenient in DBIv2, so I have been thinking
about ways to streamline the movement of data in and out of DBI.
A lot of these ideas are probably obvious, but I haven't seen them
actually stated anywhere yet. A lot may be bad or wrong, which is
where you readers come in...
I like the way Juerd Waalboer simplyfied the DBI API (DBIx::Simple):
for my $row ($db->query('SELECT * FROM ...')->arrays) {
print $row->[0], $row->[1];
}
$db->query('SELECT a, b FROM table WHERE c = ?', $c)->into(my ($a,$b));
($id) = $db->query('SELECT MAX(id) FROM table')->list;
my @all_ids = $db->query('SELECT id FROM table WHERE ...')->flat;
Maybe you can get some inspiration from:
http://search.cpan.org/~juerd/DBIx-Simple-1.25/lib/DBIx/Simple/Examples.pod
--
Raphael
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
> : Damian may not like the colon, but I couldn't help thinking that the "_"
> : could be replaced with ":" and things would be cleaner. Example:
>
> Well, but the _ really is part of the name, insofar as it's trying to
> isolate the namespace. Even with : we had to say that it would probably
> be stored in the symbol table with the leading colon. Plus history is
> on the side of leading _ meaning "private implementation detail", and
> the : is awfully confusing in the neighborhood of adverb pairs. If it
> were just sigiled variables, the : would probably be fine, but
>
> method :foo() {...}
>
> just has a strangeness to it that won't go away. Arguably that's a feature,
> but I'm mostly worried with visual confusion with all the other colons
> in Perl 6.
Just wanted to chip in here and say that I *do* think that its
strangeness is a feature. History may be on the side of _, but
consider that : wasn't valid syntax.
I haven't written enough Perl 6 to say whether or not this is
confusing with adverb pairs, but I love the colon for private
methods/attributes and it's the one thing separating your new thinking
from my ideal Perl 6 OO.
--
matt diephouse
http://matt.diephouse.com
Re: Strange interaction between pairs and named binding
On Tue, Jul 19, 2005 at 12:25:02PM +0800, Autrijus Tang wrote:
: On Mon, Jul 18, 2005 at 03:48:55PM -0700, Brent 'Dax' Royal-Gordon wrote:
: > Autrijus Tang <[EMAIL PROTECTED]> wrote:
: > > This currently works in Pugs:
: > >
: > > for [1..10].pairs -> Pair $x { say $x.value }
: > >
: > > But this does not:
: > >
: > > for [1..10].pairs -> $x { say $x.value }
: > >
: > > Because the ruling that pairs must not be bound to parameters that are
: > > not explicitly declared to handle them. Is this a desirable behaviour?
: >
: > How much violence would be done to the language if we declared that
: > block (i.e. closure with no "sub" keyword) parameters defaulted to
: > Item|Pair, while sub parameters defaulted to plain Item? I can't
: > imagine named arguments are going to be used very often on blocks,
: > which tend to be things like loop bodies...
:
: If the Bare code object (including pointy and non-pointy) default their
: parameter types to "Any" (that is, Item|Pair|Junction), then all of
: these would work:
:
: for [1..10].pairs { say(.value) }
: for [1..10].pairs { say($^x.value) }
: for [1..10].pairs -> $x { say($x.value) }
: for 1|2, 3|4 { say(.values) }
: for 1|2, 3|4 { say($^x.values) }
: for 1|2, 3|4 -> $x { say($x.values) }
I dunno. I'm inclined to say that it should default to Item|Pair, and
let people say Any explicitly if they really want to suppress autothreading.
Otherwise conditionals and switches are going to behave oddly in the
presence of "accidental" junctions.
Alternately we could try to distinguish explicit pairs from generated
pairs, and require explicit pairs (or * marked generated pairs) to
transition to the named zone.
Larry
Re: Strange interaction between pairs and named binding
Larry wrote:
: If the Bare code object (including pointy and non-pointy) default their
: parameter types to "Any" (that is, Item|Pair|Junction), then all of
: these would work:
:
: for [1..10].pairs { say(.value) }
: for [1..10].pairs { say($^x.value) }
: for [1..10].pairs -> $x { say($x.value) }
: for 1|2, 3|4 { say(.values) }
: for 1|2, 3|4 { say($^x.values) }
: for 1|2, 3|4 -> $x { say($x.values) }
I dunno. I'm inclined to say that it should default to Item|Pair, and
let people say Any explicitly if they really want to suppress autothreading.
Not surprisingly, I strongly agree with this sentiment! ;-)
Damian
