Re: Properties
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> Well, it's not nearly as general as we're making it, but the
> inspiration for it comes in part from the "Traits" paper:
>
> http://www.cse.ogi.edu/~black/publications/TR_CSE_02-012.pdf
>
> Basically, I'm attempting to take their concept and unify it with
> properties, interfaces, generics, aspects, and mixins. Among other
> things...
Ok, having read this now (at least corsorily) and compared it with what I
believe I understand about the way P6 is implementing
traits/properties/roles, I begin to get it, and I am, as usual, suitably
impressed and excited.
So is this a good time to divert this topic into an elaboration of roles?
> : Somebody drop me an example?
>
> Well, it hasn't been defined yet. Likely there will be some syntax
>
> my property foo;
>
> that is shorthand for something vaguely resembling
>
> my role foo is property {
> has $.foo is rw;
> }
So if I want to implement a package of related roles that I commonly use in
our In-House code, such as to specify how verbose an object should be on log
output, and how touchy it should be over whether a problem is screamingly
fatal or just warningly annoying, and maybe toss in a shorthand method that
lets me pass the names of some specific traits I want to be able to use (
like "allow(qw/winkin blinkin nod/)" or some such), it should be pretty
simplebut I'm having a hard time coming up with the syntax that declares
the package and exports the roles.
module IHL::Roles;
@ISA = 'Exporter';
@EXPORT_OK = qw/ fatal verbose allow setvals /;
our role fatal is property {
has $.fatal is rw;
}
our role verbose is property {
has $.verbose is rw;
}
sub allow {
# I'd want to make this one too complex to actually do it here
}
sub import {
allow @_[1...];
}
sub setvals ($o, [EMAIL PROTECTED]) {
"\$o.$_ = true".eval for @t; # surely there's a better way to do this?
}
then write allow() to build roles for each value passed in, maybe taking an
arg to say whether they should be truly global, or built in the caller's
namespace
Then I could say
use IHL::Roles qw/ allow setvals fatal verbose /;
use Foo;
my $o = Foo.new();
allow qw/ foo bar baz /;
setvals($o,qw/ verbose baz /);
I'm trying to make sure I don't tumble back into pure P5 here, but I don't
think I'm really awake yet. :)
*
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers.60"
Re: Properties
On Mon, Dec 01, 2003 at 10:42:09AM -0500, Hodges, Paul wrote:
> So is this a good time to divert this topic into an elaboration of roles?
I can wait for A12, but in the mean time ... :-)
> So if I want to implement a package of related roles that I commonly use in
> our In-House code, such as to specify how verbose an object should be on log
> output, and how touchy it should be over whether a problem is screamingly
> fatal or just warningly annoying, and maybe toss in a shorthand method that
> lets me pass the names of some specific traits I want to be able to use (
> like "allow(qw/winkin blinkin nod/)" or some such), it should be pretty
> simplebut I'm having a hard time coming up with the syntax that declares
> the package and exports the roles.
>
> module IHL::Roles;
> @ISA = 'Exporter';
> @EXPORT_OK = qw/ fatal verbose allow setvals /;
>
> our role fatal is property {
> has $.fatal is rw;
> }
>
> our role verbose is property {
> has $.verbose is rw;
> }
>
> sub allow {
> # I'd want to make this one too complex to actually do it here
> }
>
> sub import {
> allow @_[1...];
> }
>
> sub setvals ($o, [EMAIL PROTECTED]) {
> "\$o.$_ = true".eval for @t; # surely there's a better way to do this?
> }
Trying to keep up here ... but couldn't you do something like this?
sub setvals ($o, [EMAIL PROTECTED]) {
$o but= $_(true);
}
er, wouldn't you *have* to do something like that. If the object in
$o hasn't the property "foo", then C<$o.foo = true;> would be an
error, so you're trying to do 2 things: 1) give the object a property
and 2) assign a value to that property.
I think you're trying to do too much in the above code. If you just
have a common set of roles that you want to use across objects, you
could do this:
module MyRoles;
use Exporter;
@EXPORT_OK = <>;
our property verbose is true;
our property fatal is true;
our property notexported;
our property *trulyglobal;
then in other code:
use MyRoles;
use SomeFancyStuff;
my $o = SomeFancyStuff.new() but verbose;
$o but= MyRoles.notexported;
$o but= trulyglobal;
Or am I missing something?
> then write allow() to build roles for each value passed in, maybe taking an
> arg to say whether they should be truly global, or built in the caller's
> namespace
Isn't that what my, our, Exporter, and the globalifying * are all about?
I look forward with much anticipation to A12.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
RE: Properties
> From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
> On Mon, Dec 01, 2003 at 10:42:09AM -0500, Hodges, Paul wrote:
> >
> > module IHL::Roles;
> > @ISA = 'Exporter';
> > @EXPORT_OK = qw/ fatal verbose allow setvals /;
> >
> > our role fatal is property {
> > has $.fatal is rw;
> > }
> >
> > our role verbose is property {
> > has $.verbose is rw;
> > }
> >
> > sub allow {
> > # I'd want to make this one too complex to actually do it here
> > }
> >
> > sub import {
> > allow @_[1...];
> > }
> >
>
> > sub setvals ($o, [EMAIL PROTECTED]) {
> > "\$o.$_ = true".eval for @t; # surely there's a better way to do this?
> > }
>
> Trying to keep up here ... but couldn't you do something like this?
>
> sub setvals ($o, [EMAIL PROTECTED]) {
> $o but= $_(true);
> }
>
> er, wouldn't you *have* to do something like that. If the object in
> $o hasn't the property "foo", then C<$o.foo = true;> would be an
> error, so you're trying to do 2 things: 1) give the object a property
> and 2) assign a value to that property.
A) You're absolutely right. I goofed. :)
B) What exactly does $_(true) mean in "$o but= $_(true);"?
I assume you're setting the the value, so I think I understand it, but how about
sub setvals ($o, [EMAIL PROTECTED]) {
$o but= $_;
$o.$_ = true;
}
Though I'm still "iffy" about that $o.$_ business.
I think $_(true) is better. I'm just fumbling for perspective.
> I think you're trying to do too much in the above code.
lol -- always. :)
> If you just have a common set of roles that you want to use across objects,
> you could do this:
>
> module MyRoles;
> use Exporter;
> @EXPORT_OK = <>;
>
> our property verbose is true;
> our property fatal is true;
> our property notexported;
> our property *trulyglobal;
>
> then in other code:
>
> use MyRoles;
> use SomeFancyStuff;
> my $o = SomeFancyStuff.new() but verbose;
> $o but= MyRoles.notexported;
> $o but= trulyglobal;
>
> Or am I missing something?
Should have been
use MyRoles <>;
for one, shouldn't it? :)
Nice concise definitions.
But I still would like to be able to write a role generator in the module, so that I
can pass it a list of roles I want valid and have it set them all up, so that my
program only has to say
use MyRoles <>;
use Thingy;
my $o = Thingy.new();
allow <>;
setvals $o, <>;
instead of
use Thingy;
my $o = Thingy.new();
our property foo is true;
our property bar is true;
our property baz is true;
$o but= foo;
$o but= baz;
Don't get me wrong; there's nothing wrong with this code.
I just foresee certain things that I do commonly enough that I want to factor them out
into something tested and consistent.
Likewise, working on the details of such an implementation is always what makes the
underlying "stuff" start to make sense to me. :)
One thing, though could I do this? >=o}
my property (foo,bar,baz) ^is true;
$thingy ^but= (foo,baz);
I'm pretty sure that syntax is way wonky -- would "is" be a vectorizable operator?
Does it even qualify as an operator at all?
> > then write allow() to build roles for each value passed in,
> > maybe taking an arg to say whether they should be truly global,
> > or built in the caller's namespace
>
> Isn't that what my, our, Exporter, and the globalifying * are
> all about?
Probably, though I haven't seen anything yet about how the P6 version of the Exporter
is going to handle things like specifying exportation of my() vars &co.
*
"The information transmitted is intended only for the person or entity to which it is
addressed and may contain confidential, proprietary, and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other than the intended
recipient is prohibited. If you received this in error, please contact the sender and
delete the material from all computers." 113
Re: Properties
Hodges, Paul writes:
> I assume you're setting the the value, so I think I understand it, but
> how about
>
> sub setvals ($o, [EMAIL PROTECTED]) {
> $o but= $_;
> $o.$_ = true;
> }
>
> Though I'm still "iffy" about that $o.$_ business. I think
> $_(true) is better. I'm just fumbling for perspective.
Y'all seem to be missing a C somewhere :-)
sub setvals ($o, [EMAIL PROTECTED]) {
$o but= $_ for @t;
}
I think that should work, as the right side of C should always be a
property, so a property reference ought be interpreted correctly.
> One thing, though could I do this? >=o}
>
> my property (foo,bar,baz) ^is true;
> $thingy ^but= (foo,baz);
No, but you might be able to if you used proper vectorizing syntax ;-)
my property (foo,bar,baz) is sometrait; # is automatically distributes
$thingy Âbut=Â (foo,baz);
C doesn't seem like a trait you would put on a property. C
is a run-time property, and I think it would be awfully confusing to
make it a trait as well. If you're talking about some kind of
initialization, you might use:
my property (foo,bar,baz) is first(1);
Or C might be correct if you're -- somehow -- deriving these
properties from the C property. But I don't think that was the
intent.
> I'm pretty sure that syntax is way wonky -- would "is" be a
> vectorizable operator? Does it even qualify as an operator at all?
C is definitely an operator, much in the same way C is an
operator. Whether it's vectorizable is questionable, because in all
cases I've seen the vectorization is implicit. That is, if it has a
non-vector meaning, the meaning of:
my ($a,$b,$c) is foo;
is a little fuzzy. What's C applying to if it's not applying to all
of $a, $b, and $c?
> > > then write allow() to build roles for each value passed in,
> > > maybe taking an arg to say whether they should be truly global,
> > > or built in the caller's namespace
> >
> > Isn't that what my, our, Exporter, and the globalifying * are
> > all about?
>
> Probably, though I haven't seen anything yet about how the P6 version
> of the Exporter is going to handle things like specifying exportation
> of my() vars &co.
I'm pretty sure that the interface to Exporter can be cleaned up quite a
bit in Perl 6. For now, though, I think it's fine to assume it works
exactly like Perl 5's.
Luke
Ã
