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: leo-ctx5 (r8656): test results
Jerry Gay wrote: win32--msvc-7.1--perl-5.8.6 reports some unexpected errors. dynclass and spawnw are expected on windows, the rest are not. if requested, i can provide more details on the failing tests. ~jerry Failed Test Stat Wstat Total Fail Failed List of Failed --- imcc\t\syn\clash.t 3 768153 20.00% 1-2 8 imcc\t\syn\labels.t 1 256 71 14.29% 3 t\dynclass\foo.t 8 2048 98 88.89% 1-5 7-9 t\dynclass\gdbmhash.t 13 332813 13 100.00% 1-13 t\op\gc.t1 256191 5.26% 12 t\op\jit.t 12 307260 12 20.00% 5 8 13 16 21 24 28 33 36 52-53 59 Can I just check, are the python dynclasses being executed and passing, or not being run in these tests? I'm planning (time permitting) to write up some notes about building on Windows (initially from a cygwin perspective) in the coming days. I got confirmation back from Greg, which I don't think made it onto the list, saying that the recipe in http://www.nntp.perl.org/group/perl.perl6.internals/30359 had worked for him. Thanks, Nick
Re: leo-ctx5 (r8656): test results
Nick Glencross [EMAIL PROTECTED] wrote: Failed Test Stat Wstat Total Fail Failed List of Failed --- imcc\t\syn\clash.t 3 768153 20.00% 1-2 8 imcc\t\syn\labels.t 1 256 71 14.29% 3 t\dynclass\foo.t 8 2048 98 88.89% 1-5 7-9 t\dynclass\gdbmhash.t 13 332813 13 100.00% 1-13 t\op\gc.t1 256191 5.26% 12 t\op\jit.t 12 307260 12 20.00% 5 8 13 16 21 24 28 33 36 52-53 59 Can I just check, are the python dynclasses being executed and passing, or not being run in these tests? A whle back leo wrote:- * python PMCs that mess with interpreter context or duplicate Parrot's function call API need rework - compiling dynclasses/py* is disabled. So they're not being built, and thus not being tested. Jonathan
RE: [perl #36620] Bug in editor/ops2vim.pl
Oops, you'r right. perldoc perlop says ARGV is a nickname for , but it's
not as magical.
-Original Message-
From: jerry gay via RT [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 21, 2005 2:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [perl #36620] Bug in editor/ops2vim.pl
actually, it should be
while() {
applied, thanks.
On 7/21/05, via RT Amir Karger
[EMAIL PROTECTED] wrote:
# New Ticket Created by Amir Karger
# Please include the string: [perl #36620]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36620
editor/ops2vim.pl says:
while (@ARGV) {
AFAIK, that should be
while (ARGV) {
I'm running perl 5.8.6. Using ops2vim.pl that came with
parrot-0.2.2, I got
just one (broken) line out of the script. Removing the @
makes it work fine.
-Amir Karger
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 BD 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
[PATCH] Win32 executable generation
Hi, The attached patch does some changes to make it possible to generate an EXE file on Win32. Firstly, main.c looked for the extension .o to know to make an object file; on Win32 it's .obj. The fix will work for other platforms where it isn't .o too. Secondly, the make exec target in the makefile didn't append the .exe to the generated file. Unfortunately, the built exe file does...nothing. Well, maybe not quite nothing, but I don't get any output. So that's what's next to look at. (I was originally looking at the [TODO] exec core testing task, then discovered this breakage on Win32). Jonathan execfix.diff Description: Binary data
Re: [PATCH] Win32 executable generation
Jonathan Worthington wrote:
Hi,
Unfortunately, the built exe file does...nothing.
Well, I don't know, how exe files on win32 look like, but Parrot
supports these: EXEC_{A_OUT,ELF,MACH_O,COFF} (see src/exec_save.c).
Is any one of these EXEC symbols defined?
(This doesn't imply that the patch shouldn't be applied, though)
Jonathan
leo
Re: [PATCH] Win32 executable generation
Leopold Toetsch [EMAIL PROTECTED] wrote:
Jonathan Worthington wrote:
Hi,
Unfortunately, the built exe file does...nothing.
Well, I don't know, how exe files on win32 look like, but Parrot supports
these: EXEC_{A_OUT,ELF,MACH_O,COFF} (see src/exec_save.c).
Is any one of these EXEC symbols defined?
Yup. In config.h
#define PARROT_EXEC_OS_MSWIN32 1
In exec.h
# if PARROT_EXEC_OS_MSWIN32
# define EXEC_COFF
# endif
And COFF is correct. If it were not, I'd have expected a linker error
anyway... I'll see if I have time to dig a bit deeper later on this
afternoon.
Thanks for the suggestion,
Jonathan
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: leo-ctx5 (r8656): test results
On 7/22/05, Nick Glencross [EMAIL PROTECTED] wrote: Can I just check, are the python dynclasses being executed and passing, or not being run in these tests? tests are not run currently in leo's branch only (see jonathan's message.) but The Great Merge to trunk will carry this change with it. and, as i understand it, leo's waiting for chip to finish up the parrot design doc (ppd03) so he can implement the object/method semantics. so it'll be a little bit until the merge. I'm planning (time permitting) to write up some notes about building on Windows (initially from a cygwin perspective) in the coming days. I got confirmation back from Greg, which I don't think made it onto the list, saying that the recipe in http://www.nntp.perl.org/group/perl.perl6.internals/30359 had worked for him. i've not tried this recipe. due to the cygwin patches i've seen on the list lately, i'm trying to get that environment set up here so i can review and apply those. i'm *almost* there, so hopefully these patches won't get lost in the ether. ~jerry
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
dynclasses on Windows
Guys, I've been giving some thought to what needs doing to get dynclasses working on Windows. I'm not particularly intimate with Windows, but use cygwin quite a bit. One area that I'm still not 100% clear about is the visibility of symbols within DLLs and executables, so please be kind! From previous posts, you may have seen a kludgey solution to getting dynclasses working on cygwin. The basic scheme is: * Build a libparrot.dll, which includes an appropriate *_config.o * Build dynclasses which link against libparrot.dll * Build parrot.exe against libparrot.dll [My understanding is that] DLLs cannot have unresolved symbols, or at least they must be linked against another DLL which can provide them. Hence, dynclasses need to be linked against libparrot.dll at compile time, and *_config.o files need to reside in the DLL. What we do currently linking with the parrot executable against *_config.o files isn't satisfactory on Windows. Does that seem reasonable so far? Now to the bit which causes problems. Because libparrot.dll is tightly bound to the configuration (e.g. parrot_config.o) you might potentially need three DLLs (for miniparrot, parrot and installed parrot), which is horrible. What I'd like like to propose is that the information in parrot_config.o and install_config.o be selected by the caller, either through a (DLL) global or an argument to parrot_get_config_string. That way, libparrot.dll can be built against it, and its personally determined by the harness (which is compiled with -DINSTALL or such-like). To summarise, one recipe might be: * Build libminiparrot.dll, which includes null_config.o * Build miniparrot, linking against libminiparrot.dll * Create parrot_config.o and install_config.o using miniparrot * Build libparrot.dll with parrot_config.o and install_config.o * Build parrot, linking against libparrot.dll * Build dynclasses, linking against libparrot.dll * Subsequently build installed_parrot, but get it to select the install config There are obviously variants upon this theme, particularly where naming is concerned, but what I wanted to get across is what links against what, and what to do about the *_config.o files. Obviously miniparrot could be build using an archive library etc. Be kind on me if I've misunderstood Windows-land! Cheers, Nick
[PATCH] Library Loading On Win32
Hi, Under Win32 it's common to install stuff...well...anywhere the person installing it wants. With this patch, we can create binary distributions for Win32 that don't need Parrot to be installed in the place that make install decides to put it. Normally libraries are loaded by appending a prefix, stashed in the executable at compile time, to some common library search paths. With this patch, if that doesn't work out for us then and we're on Win32 then we get the path of the Parrot executable and use that as a basis for trying to find libraries. Thanks to Amir Karger for reporting this problem in my regular Parrot Win32 snapshots[1]. Also, note to leo (and anyone else who was on IRC while I was having a dumb moment) - this patch doesn't depend on that memory freeing one I submitted a day or so back being applied first. I thought it touched library.c. It didn't. So this can be applied whenever, provided there's no complaints about it. Thanks, Jonathan [1] http://www.jwcs.net/~jonathan/perl6/ win32libload.diff Description: Binary data
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 foos 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 accessors to be entirely isolated from each
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 foos 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 attribute with an auto-generated
# non-virtual accessor.
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 foos 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 with an auto-generated
# non-virtual accessor.
has
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 $?SELFfoo() 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
[perl #36636] Using addparent with PMCs
# New Ticket Created by Matt Diephouse # Please include the string: [perl #36636] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36636 The addparent opcode doesn't work currently with PMCs (on either end): harmony:~/Projects/parrot mdiep$ cat test.pir .sub main @MAIN $P0 = newclass Foo $P1 = getclass String addparent $P0, $P1 end .end harmony:~/Projects/parrot mdiep$ parrot test.pir Parent isn't a ParrotClass harmony:~/Projects/parrot mdiep$ You can, however, use the subclass opcode to subclass a PMC in PIR. This should either be implemented or the documentation should make note of the behavior. Note also that it wasn't particularly clear (to me as a Parrot user) that a ParrotClass is a PIR-defined class. -- matt diephouse http://matt.diephouse.com
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
[PATCH] Win32 exec cmd buffer realloc
The attached patch goes over Jonathan Worthington's earlier patch
and corrects an omission in resizing the cmdline buffer for large
commands.
Greg
diff -ru parrot/config/gen/platform/win32/exec.c
parrot-mod/config/gen/platform/win32/exec.c
--- parrot/config/gen/platform/win32/exec.c 2005-07-22 09:23:49.418830400
-0500
+++ parrot-mod/config/gen/platform/win32/exec.c 2005-07-22 12:35:17.030444800
-0500
@@ -63,22 +63,21 @@
if (pmclen == 0) {
internal_exception(NOSPAWN, Empty argument array for spawnw);
}
-
+
/* Now build command line. */
for (i = 0; i pmclen; i++) {
- STRING *s = VTABLE_get_string_keyed_int(interpreter, cmdargs, i);
- char *cs = string_to_cstring(interpreter, s);
- if (cmdlinepos + s-strlen + 3 cmdlinelen)
- {
- cmdlinelen += s-strlen + 4;
- mem_sys_realloc(cmdline, cmdlinelen);
+STRING *s = VTABLE_get_string_keyed_int(interpreter, cmdargs, i);
+char *cs = string_to_cstring(interpreter, s);
+if (cmdlinepos + s-strlen + 3 cmdlinelen) {
+cmdlinelen += s-strlen + 4;
+cmdline = mem_sys_realloc(cmdline, cmdlinelen);
}
strcpy(cmdline + cmdlinepos, \);
strcpy(cmdline + cmdlinepos + 1, cs);
strcpy(cmdline + cmdlinepos + 1 + s-strlen, \ );
cmdlinepos += s-strlen + 3;
}
-
+
/* Start the child process. */
memset(si, 0, sizeof(si));
si.cb = sizeof(si);
diff -ru parrot/t/op/spawnw.t parrot-mod/t/op/spawnw.t
--- parrot/t/op/spawnw.t2005-07-19 08:34:56.005030400 -0500
+++ parrot-mod/t/op/spawnw.t2005-07-22 12:53:26.052388600 -0500
@@ -34,7 +34,7 @@
=cut
-use Parrot::Test tests = 6;
+use Parrot::Test tests = 7;
# perl command coded this way to avoid platform
# quoting issue.
@@ -132,3 +132,31 @@
CODE
return code: 3
OUTPUT
+
+pir_output_is('CODE', 'OUTPUT', grow argv buffer);
+.sub test @MAIN
+.local pmc args
+
+$S0 = exit length(qq{
+$I0 = 0
+loop:
+if $I0 = 1000 goto end
+$S0 = concat $S0, A
+inc $I0
+branch loop
+end:
+$S0 = concat $S0, }) / 100
+new args, .PerlArray
+push args, perl
+push args, -e
+push args, $S0
+$I0 = spawnw args
+shr $I1, $I0, 8
+print return code:
+print $I1
+print \n
+end
+.end
+CODE
+return code: 10
+OUTPUT
Calling Super Methods
There's currently no way to call a superclass' method. I've just run into this and leo suggested I sent a note to the list. Here's what I want to do: I have a ParrotClass (a class defined in PIR) that is derived from the String class. I want to override it's set_string_native method to do some processing before I store the value. My first attempt was this: .sub __set_string_native method .param string value self = value print assign\n .end Of course, that doesn't work: `self = value` just calls the method again and you quickly hit the recursion limit. While I probably won't be able to use the = syntax, I should be able to call the parent's method (since I can't actually set the string value myself like I can in PMC-land). Something like this ought to work: .sub __set_string_native method .param string value self.SUPER::__set_string_native(value) print assign\n .end I don't really care how it looks really, as long as it's possible. Any thoughts? It'd be nice to get this specced so that it can be implemented. Thanks. -- matt diephouse http://matt.diephouse.com
patches accumulating
There is a long list of folks with commit rights for parrot svn. I don't have always the time to ci @all_patches (and will not have the next days to do so), therefore I'd really appreciate, if patches could be reviewed, commented if needed, and *applied* w/o me too, if these patches are sane of course And, if someone w/o ci privs likes to have some, *and* wants to take the responsibility for helping the project, please mail me or chip with your auth.perl account data. Thanks, leo
Perl6 rules grammar
A couple of people have been making contributions to the rx_grammar.pl file in pugs (modules/Grammars/rx_grammar.pl), so I thought I'd start maintaining an official Perl 6 grammar in the parrot repository, that can be maintained/monitored closely with PGE. The latest version of the grammar file is kept at http://svn.perl.org/parrot/trunk/compilers/pge/P6Rule.grammar, and is currently a first draft. It differs somewhat from rx_grammar.pl, in that it incorporates some of the rule syntax changes that don't yet appear in S05/A05. (I hope to be bringing S05/A05 more up to date soon, patches are welcome!) Some constructs needed to fully describe the rules syntax aren't available in PGE yet; in these cases I've provided a rule as it should probably look, followed by whatever version of the rule PGE can currently support. Also, I know there are some rule syntaxes that are missing in this first draft, but following release early/often I thought I'd go ahead and publish a somewhat incomplete version for now. All patches and feedback are greatly appreciated. Pm
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
