paths:
M S02-bits.pod
Log Message:
---
[S02] remove section on Properties
it seems that properties refer to either traits or run-time mixins with
infix but.
Both are described much more accurately and less out-of-date in S12 and S14
IMHO some details of Unicode property support seem unspecified:
1) Assumption: *ALL* Unicode properties and all of their aliases should
be supported.
E.g. this will also include the derived properties 'Grapheme_Base' and
'Grapheme_Extent' (missing in Perl 5 - obviously a bug in 'unicore
There is syntax to define trait and properties
but is there an API?
my $b = eval '$a but true'; # setting a true property
# API to do it without an eval?
A trait setter probably does not make sense but for the
implementer because it should not be set at run time.
Incidentally
On Fri, May 13, 2005 at 06:37:50PM +, [EMAIL PROTECTED] wrote:
There is syntax to define trait and properties
but is there an API?
my $b = eval '$a but true'; # setting a true property
# API to do it without an eval?
I don't understand why you think you need the eval here
On 5/13/05, Stéphane Payrard [EMAIL PROTECTED] wrote:
There is syntax to define trait and properties
but is there an API?
my $b = eval '$a but true'; # setting a true property
# API to do it without an eval?
My question is more generic than my example.
I may not know
On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Well, the value's pretty easy--just pass in a variable:
:
: my $b = $a is foo($bar);
As we currently have it, that is not legal syntax. is may only
be applied to declarations. You must use does or but to mixin
On Fri, May 13, 2005 at 12:31:09PM -0700, Larry Wall wrote:
On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Well, the value's pretty easy--just pass in a variable:
:
: my $b = $a is foo($bar);
As we currently have it, that is not legal syntax. is may only
On 5/13/05, Larry Wall [EMAIL PROTECTED] wrote:
On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote:
: my $b = $a is foo($bar);
As we currently have it, that is not legal syntax. is may only
be applied to declarations.
Sorry, think-o. I meant 'but' in my examples
On Fri, May 13, 2005 at 12:56:19PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Should I construe the fact that you didn't comment on the ::() to mean
: that the symref syntax works here?
Offhand I don't see any reason for it not to.
Larry
On Fri, May 13, 2005 at 09:40:51PM +0200, Stéphane Payrard wrote:
: And what about the getter part of my question? :)
A12 discusses the relationship of traits and properties in great
detail. Any trait's metadata can be stored as properties at compile
time, and such metadata can be retrieved
Larry wrote:
: Indeed, if Larry were to give the word, I'd be delighted to add support for
: it to the Perl6::Rules module.
Execute! (I hope that's the right word...)
I believe, Captain, the correct word would be: Engage!
Data^H^Hmian
Larry noted:
There's a lot to be said for being able to write
things like:
[ ident ascii+ ]
Now I'm supposing that binds tighter than | as usual, so the
brackets wouldn't always be necessary:
ident french+
|
ident swahili+
FWIW, I'm strongly in favour of adding to rules.
On Tue, Mar 02, 2004 at 04:58:38PM +1100, Damian Conway wrote:
: FWIW, I'm strongly in favour of adding to rules.
:
: Indeed, if Larry were to give the word, I'd be delighted to add support for
: it to the Perl6::Rules module.
Execute! (I hope that's the right word...)
Larry
: strings+ or objectrefs.
Okay, I supposin'. But I'd rather not call them traits, since that
already means two other things right now. Properties is more like...
: You want to do something like search for all occurrences of the word
: 'From:' in a heading style or Find all letters 'l' in french text
+ | swahili+ ]
or really, just
ident french|swahili+
That last is likely to be the fastest, since a decent implementation
of character properties should cache swatches of the bitmap like Perl 5
does, or at least memoize something somewhere to keep from having
to recalculate what's french
Another hypothetical:
Suppose you have a browser (which understands language traits) or a word processor
(which stores style and/or font information) that is storing some not-text-only
string-like things via scalar strings+ or objectrefs.
You want to do something like search for all
Is there a list of the properties for the builtin types? My searches
through the archives leads me to believe there is no such beast. Is
there any consensus on what some of the properties will be? I am not
looking for a complete or authoritative list. I am just trying to
finish off
On Thu, Dec 04, 2003 at 05:57:52PM -0700, Luke Palmer wrote:
Hodges, Paul writes:
I'd *like* to be able to predeclare a trait or property to be distributed
across any values placed in this array, but only this array. For example, it
would be nice if I could have the default aspects of false
, the universe could have shifted under my feet without my
knowledge.
No, it was just a braino on my part. I forgot that I've already seen
parametric properties in a lot of places... :-/
I discovered after reading this email that I've been assuming that
square-bracket parameterization happened
How about
use Baz; # assume object type
my property foo;
my @bar of Baz is false but foo; # maybe not what you meant?
If you apply a trait like false to an array, I expect it to apply to the
array instance object itself and not the content, so that
push @bar, Baz.new();
if @bar{
Hodges, Paul writes:
How about
use Baz; # assume object type
my property foo;
my @bar of Baz is false but foo; # maybe not what you meant?
Definitely not what you meant. Fortunately, the compiler will teach you
a thing or two about it: Cfalse is not a trait.
But indeed foo would
--- Luke Palmer [EMAIL PROTECTED] wrote:
Hodges, Paul writes:
How about
use Baz; # assume object type
my property foo;
my @bar of Baz is false but foo; # maybe not what you meant?
Definitely not what you meant. Fortunately, the compiler will teach
you a thing or two about
Paul Hodges writes:
Luke Palmer:
Something likely more like:
my role property_wrap[Property [EMAIL PROTECTED] {
method STORE($newval) { SUPER::STORE($newval but [EMAIL PROTECTED]) }
}
@bar but= property_wrap[false, foo];
...square brackets?
...roles can have
[EMAIL PROTECTED] (Paul Hodges) writes:
I am not seeing unicode.
Don't worry because, and I honestly don't mean this disparagingly - by the
time Perl 6 is ready for prime-time, you will. Larry got this one right.
--
Jesus ate my mouse or some similar banality.
-- Megahal (trained on
--- Simon Cozens [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Paul Hodges) writes:
I am not seeing unicode.
Don't worry because, and I honestly don't mean this disparagingly -
by the time Perl 6 is ready for prime-time, you will. Larry got this
one
right.
lol -- I think you're right.
And
. If you're talking about some kind of
initialization, you might use:
my property (foo,bar,baz) is first(1);
Or Cis might be correct if you're -- somehow -- deriving these
properties from the Ctrue property. But I don't think that was the
intent.
Was just initializing. Don't remember is first
On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
Didn't know is would do that. Good to know!
And in my meager defense, I did reference MikeL's operator synopsis as
of
3/25/03, which said ^[op] might be a synonym for or (Sorry,
no
fancy chars here. :)
Hey, that was *March*! ;-)
Michael Lazzaro writes:
On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
Didn't know is would do that. Good to know!
And in my meager defense, I did reference MikeL's operator synopsis as
of
3/25/03, which said ^[op] might be a synonym for or (Sorry,
no
fancy chars here.
Luke Palmer writes:
And as far as I know, and are exactly equivalent to and in all
cases.
By which I mean and , of course. :-/
(mutt is kind of a pain in this area)
Luke
On Tuesday, December 2, 2003, at 12:37 PM, Luke Palmer wrote:
Michael Lazzaro writes:
There were also vaguely threatening proposals to have op and
op
do slightly different things. I assume that is also dead, and that
op is (typically) a syntax error.
Ack. No, slightly different things would be
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
Didn't know is would do that. Good to know!
And in my meager defense, I did reference MikeL's operator
synopsis as of 3/25/03, which said ^[op] might be a synonym
for or (Sorry,
And as far as I know, and are exactly equivalent to æ?? and æ??
in all cases.
lol I get the idea, but I foresee these unicode bits as becoming an
occasional sharp spot in my metaphorical seat of consciousness. :)
I am not seeing unicode.
__
Do you
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
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
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
-- somehow -- deriving these
properties from the Ctrue 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?
Cis is definitely an operator, much in the same way Cmy
--- Larry Wall [EMAIL PROTECTED] wrote:
On Thu, Nov 27, 2003 at 08:08:05PM -0800, Paul Hodges wrote:
: --- Larry Wall [EMAIL PROTECTED] wrote:
: ... in fact, we may be limiting the creation of properties
: to predeclared names, so that even
:
: return 0 but ture;
:
: can
be an unPerlish restriction; people who know
how to read a property would also expect to be able to set it in
the same way.
I'd think that would depend on the current status of strictures.
Assuming no strictures at all, I'd rather expect Perl to autovivify
properties much the way hash elements
no strictures at all, I'd rather expect Perl to autovivify
: properties much the way hash elements are created when you assign a
: value to a previously nonexistant key, but that's exactly the reason I
: *NEVER* leave strictures *or* warnings off, even in short little
: one-shot programs. If it's complex
on the current status of strictures.
: Assuming no strictures at all, I'd rather expect Perl to autovivify
: properties much the way hash elements are created when you assign a
: value to a previously nonexistant key, but that's exactly the
: reason I *NEVER* leave strictures *or* warnings off
--- Larry Wall [EMAIL PROTECTED] wrote:
On Sat, Nov 29, 2003 at 08:50:57AM -0800, Paul Hodges wrote:
: hmm... lexical propertiesI've read the rest of the message,
: and I see how this could be a problem. Just to be clear on it,
: what exactly would it mean for a property or trait
--- Paul Hodges [EMAIL PROTECTED] wrote:
print foo is $x;
With deeply sincere apologies, that should have been
print foo if $x;
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
that mean you're leaning more toward allowing
: undeclared properties, or just that you're still trying to give both
: sides of the argument thorough consideration?
I'm not doing either of those things... :-)
: Just for my vote, I want to be able to declare new properties, but
: would rather
On Sat, Nov 29, 2003 at 12:53:50PM -0800, Paul Hodges wrote:
:
: --- Larry Wall [EMAIL PROTECTED] wrote:
: On Sat, Nov 29, 2003 at 08:50:57AM -0800, Paul Hodges wrote:
: : hmm... lexical propertiesI've read the rest of the message,
: : and I see how this could be a problem. Just
: but it confuses me. Does that mean you're leaning more toward
: allowing undeclared properties, or just that you're still trying
: to give both sides of the argument thorough consideration?
I'm not doing either of those things... :-)
Yayy! :)
: Just for my vote, I want to be able
: And exportation???
Exportation is just aliasing some name inside a scope to somewhere
outside the scope. Importatation is the same operation from the
viewpoint of the importing scope.
I just wasn't thinking clearly when you said it the first time.
Perl 5 didn't allow exportation of
With apologies, I'm already seeing blunders. *sigh*
my Baz @ray = ( Baz.new() );
No reason to type that. Should be
my @ray = ( Baz.new() );
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
that properties work just like other names, so they can be
stuck in package symbol tables, too.
Is that possible? Baz has no zippy, so I'd have to use but, right?
How about
$tst but= Bar.zippy; # is zippy a class property?
$tst but= Bar::zippy; # is zippy a class method? do I need
to
read a property would also expect to be able to set it in the same way.
... as long as we limit the .bar notation to rvalues or to lvalues on
already-created properties. And in fact, we may be limiting the
creation of properties to predeclared names,
That sounds like a much better solution
Here's a series of questions/confirmation requests about how properties
work (but specifically run-time properties, not traits):
Use Cbut to assign a property to a Ivalue:
$a = $b but foo; # $a has property foo, $b does not
Properties are just out-of-band methods:
if $x.foo
On Thu, Nov 27, 2003 at 12:02:30AM -0700, Luke Palmer wrote:
: Here's a series of questions/confirmation requests about how properties
: work (but specifically run-time properties, not traits):
:
: Use Cbut to assign a property to a Ivalue:
:
: $a = $b but foo; # $a has property foo
[EMAIL PROTECTED] (Larry Wall) writes:
P.S. I think we deserve a $rubyometer-- for bypassing mixins.
I think you deserve loud and wild applause for an object model I want
to use Right Now Dammit.
--
Overall there is a smell of fried onions. (fnord)
--- Larry Wall [EMAIL PROTECTED] wrote:
... in fact, we may be limiting the creation of properties
to predeclared names, so that even
return 0 but ture;
can be caught at compile time.
Excellent, so long as we can define new properties explicitly.
At the moment, I draw a complete
On Thu, Nov 27, 2003 at 08:08:05PM -0800, Paul Hodges wrote:
:
: --- Larry Wall [EMAIL PROTECTED] wrote:
: ... in fact, we may be limiting the creation of properties
: to predeclared names, so that even
:
: return 0 but ture;
:
: can be caught at compile time.
:
: Excellent, so long
Another one of my little annonyances in the current state of P6 is how
run-time properties are accessed. Accessing properties as methods is
pretty, but I see it as potentially dangerous.
Adding a new method to a class that happens to be the same as
somebody's property would be lucky to get some
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may be completely off, as I'm still digging my way
through A6):
class Foo {
method bar
On Thu, Mar 13, 2003 at 01:47:19PM -0500, Chris Dutton wrote:
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may be completely off, as I'm
On Thu, Mar 13, 2003 at 01:13:27PM -0600, Jonathan Scott Duff wrote:
: I don't think that junctions make sense here. Besides, the is is
: optional:
:
: class Foo {
: method bar is public rw const frob knob { ... }
: }
That feature is still in Schroedinger's little
Jonathan Scott Duff wrote:
On Thu, Mar 13, 2003 at 01:47:19PM -0500, Chris Dutton wrote:
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may
On Thursday, March 13, 2003, at 12:04 PM, Mark Biggar wrote:
What we do need is some way of bundling a bunch of traits together
under a simple name.
Yes, yes, yes.
Defining a Class for this is also overkill.
Ye.. well, no. Why?
So instead of saying:
my %pet is Hash of Array of Array
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
On Thursday, March 13, 2003, at 12:04 PM, Mark Biggar wrote:
What we do need is some way of bundling a bunch of traits together
under a simple name.
Yes, yes, yes.
Defining a Class for this is also overkill.
Ye.. well, no. Why?
Michael Lazzaro wrote:
Defining a Class for this is also overkill.
Ye.. well, no. Why?
class Foo is Bar; # normal inheritance
class Baz is Bar; # the thing that we are over-killing
Foo.isa(Baz) == FALSE;
A lightweight, typedef-like mechanism behaves differently:
class Foo is Bar;
wonder a bit about
the idea of mutually exclusive properties, where one can take effect if
the other(s) doesn't make sense in the current context.
Getting mired in life can really detract from following the developments
in this community.
it like this, I wonder?
Since Csub is itself a class, you can subclass it. And since A6
indicates that the signature, traits, and even implementing body are
just properties of a given Csub object, you should be able to
override them individually if you want, for example, an alternate
On Thursday, March 13, 2003, at 01:23 PM, Dave Whipp wrote:
Michael Lazzaro wrote:
Defining a Class for this is also overkill.
Ye.. well, no. Why?
class Foo is Bar; # normal inheritance
class Baz is Bar; # the thing that we are over-killing
Foo.isa(Baz) == FALSE;
A lightweight,
between subs/blocks and streaming video compression, but it is too
large to fit in the margin :-)
And since A6 indicates that the signature, traits, and even
implementing body are just properties of a given Csub object,
you should be able to override them individually if you want, for
example
On Thu, Mar 13, 2003 at 01:47:19PM -0500, Chris Dutton wrote:
: This may have been asked before, and I apologize if I somehow missed it,
: but can junctions be used for multiple properties?
:
: I can see it possibly being useful in a situation like the
: following(which may be completely off
Ah, I get it. But why would you want that -- treating Foo and Baz as
synonymous? Shouldn't you always be using Baz instead of Foo, if you
really mean Baz and not Foo, and vice versa? Because later on, if you
changed it such that:
class Foo is Bar;
typedef Baz is Bar is
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
A lightweight, typedef-like mechanism behaves differently:
class Foo is Bar;
typedef Baz is Bar;
Foo.isa(Baz) == TRUE;
Ah, I get it. But why would you want that -- treating Foo and Baz as
synonymous?
Treating BAR and BAZ as
Having just read through the declaration bits (not the calling bits,
yet):
It is explicitly stated that is rw on a slurpy parameter distributes
across all the components.
Is there some way of differentiating array of const vs. array of rw?
That is, creating a hash or array that can be extended
Austin Hastings wrote:
It is explicitly stated that is rw on a slurpy parameter distributes
across all the components.
Is there some way of differentiating array of const vs. array of rw?
That is, creating a hash or array that can be extended without
overwriting?
I'm not sure I follow what
On 2003-03-11 at 10:12:17, Damian Conway wrote:
Austin Hastings wrote:
It is explicitly stated that is rw on a slurpy parameter distributes
across all the components.
Is there some way of differentiating array of const vs. array of rw?
That is, creating a hash or array that can be
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
It is explicitly stated that is rw on a slurpy parameter
distributes
across all the components.
Is there some way of differentiating array of const vs. array of
rw?
That is, creating a hash or array that can be
Austin Hastings asked:
How do I specify an array which may be appended/pushed, but whose
values cannot change?
I believe you'd have to create a class for such things, derived from Array:
class AppOnlyArray is Array {
method STORE(int $index, $value) {
I believe you'd have to create a class for such things, derived from Array:
class AppOnlyArray is Array {
method STORE(int $index, $value) {
fail Can't modify existing element
if 0 = $index .length;
[EMAIL PROTECTED] (Simon Cozens) writes:
Can someone please compile a list of all the is foo properties that
have been suggested/accepted as being pre-defined by the language?
I can't keep track of them all.
Well, here's a start. Here are the ones I've found in the Exegeses and
Apocalypses
anyway.
A note: It is *impossible* to tell whether these are properties or
methods, built-ins or user-defined. This has never been stated
anywhere, with the exception of constant and dim, which Damian
says (in E2) are built-in properties. Maybe those which are
capitalized are user-defined. Maybe
On Sat, Mar 01, 2003 at 02:58:04PM -0600, Allison Randal wrote:
[0] STL = St. Louis - June 2002, ETH = ETH campus in Munich - Sept.
ETH is in Zurich. The Mini::Conference there was immediately followed
by YAPC::Europe in Munich. All these old European cities speaking funny
German just merge
On Sun, Mar 02, 2003 at 12:02:42AM +0100, Paul Johnson wrote:
On Sat, Mar 01, 2003 at 02:58:04PM -0600, Allison Randal wrote:
[0] STL = St. Louis - June 2002, ETH = ETH campus in Munich - Sept.
ETH is in Zurich. The Mini::Conference there was immediately followed
by YAPC::Europe in
[EMAIL PROTECTED] (Allison Randal) writes:
Oh well, it was only two letters. There wasn't anything about
approximate matching in A5, was there?
I'm not sure what you mean, could you give an example?
This was a [MZ]u[nr]ich joke, I think.
--
Term, holidays, term, holidays, till we leave
Simon wrote:
Oh well, it was only two letters. There wasn't anything about
approximate matching in A5, was there?
This was a [MZ]u[nr]ich joke, I think.
* Allison trundles off to caffeinate her brain.
On Sat, Mar 01, 2003 at 11:58:39PM +, Simon Cozens wrote:
[EMAIL PROTECTED] (Allison Randal) writes:
Oh well, it was only two letters. There wasn't anything about
approximate matching in A5, was there?
I'm not sure what you mean, could you give an example?
This was a
useful into Perl 6 from the start.
So I would like to see able to tag arbitrary information onto just about
everything, including files, packages, classes, subroutines, blocks,
control structures, statements, lines, expressions, variables and
whatever else I've forgotten about. Properties can
about. Properties can be attached to some of these. Can we
generalise this at all?
Of course, the applicability of this is not limited to code coverage, so it
would be nice to have something as general and multi purpose as possible.
But I don't want language support for saying
--
On Mon, 21 Oct 2002 16:49:57
Dan Sugalski wrote:
Almost. At least perl 5's macros look like C. Emacs' macro horrors
make C look like Lisp...
This is because C is _clearly_ a dialect of Lisp . . .
-Erik
--
Dan
On Tue, 22 Oct 2002, Erik Steven Harrison wrote:
: On Mon, 21 Oct 2002 16:49:57
: Dan Sugalski wrote:
:
: Almost. At least perl 5's macros look like C. Emacs' macro horrors
: make C look like Lisp...
:
: This is because C is _clearly_ a dialect of Lisp . . .
Yeah, look at all the extra
Jonathan Scott Duff wrote:
Ok, how about this: Is there a reason Inot to? Or
should I not go there?
Off hand, it sounds expensive. I don't see a way to only let
the people who use it incur the penalty, but my vision isn't
the best in the world.
It should be possible to define the
PROTECTED] wrote:
At 11:09 PM -0600 10/20/02, Luke Palmer wrote:
What's the plan on having properties, or attributes (depending on
how
far we're taking it), on individual characters in a string? I think
it's an essential feature, as Lisp has shown us. If there's an
argument otherwise, I'm all
[EMAIL PROTECTED] (David Whipp) writes:
It should be possible to define the bookmark methods on the basic string
class to rebless the object onto a more powerful subclass.
That makes it a doubly good candidate for modulehood.
--
It's 106 miles from Birmingham, we've got an eighth of a tank
At 7:22 PM + 10/21/02, Rafael Garcia-Suarez wrote:
Dan Sugalski wrote :
And, FWIW, emacs is written in C. Granted a much macro-mutated
version of C, but C nonetheless.
Just like Perl 5 ;-)
Almost. At least perl 5's macros look like C. Emacs' macro horrors
make C look like Lisp...
--
I didn't call the problem unreasonable, I was objecting to its
characterization as an essential feature. It isn't. A useful thing,
definitely, but there are a lot of those. It's hardly essential any
more than, say, a hash that automagically maps to the current
directory's files
Dan Sugalski wrote :
And, FWIW, emacs is written in C. Granted a much macro-mutated
version of C, but C nonetheless.
Just like Perl 5 ;-)
On Sat, 2002-05-11 at 13:58, Chris Dutton wrote:
method world is public_to(Bar) {
Might as well make that:
method world is private(Bar)
I tend to take any opportunity to recycle syntax, plus keywords with
underscores give me gas. ;)
On Wednesday, May 15, 2002, at 10:17 AM, Aaron Sherman wrote:
On Sat, 2002-05-11 at 13:58, Chris Dutton wrote:
method world is public_to(Bar) {
Might as well make that:
method world is private(Bar)
I tend to take any opportunity to recycle syntax, plus keywords with
]- I can't remember but i think I read somewhere or it was discussed here (can't
]remember), but I think it was mentioned that Perl6 will have PRE and POST method/sub
]handlers probably specified as attribute, so that (syntax may be wrong):
class XXX {
method blah is PRE {}
method blah
[EMAIL PROTECTED] writes:
: ]- I can't remember but i think I read somewhere or it was discussed here (can't
:remember), but I think it was mentioned that Perl6 will have PRE and POST method/sub
:handlers probably specified as attribute, so that (syntax may be wrong):
:
: class XXX {
:
Miko O'Sullivan writes:
What I've often wanted would be standard method that is called before every
subroutine call. If that method returns false then the method that was
called is not called.
What you're describing is Aspect-Oriented Programming (I think). Take a
look around CPAN for Aspect.pm
While thinking Eiffel-ish thoughts the other day, I began to wonder if
Perl6's classes could go beyond the simple private/public/protected
scheme by optionally allowing for a property or method to only be
accessed by a certain set of classes.
Many times when I've used OO languages I've
On Sunday, May 12, 2002, at 02:18 PM, Miko O'Sullivan wrote:
While thinking Eiffel-ish thoughts the other day, I began to wonder if
Perl6's classes could go beyond the simple private/public/protected
scheme by optionally allowing for a property or method to only be
accessed by a certain set
While thinking Eiffel-ish thoughts the other day, I began to wonder if
Perl6's classes could go beyond the simple private/public/protected
scheme by optionally allowing for a property or method to only be
accessed by a certain set of classes. For instance(as I understand
Perl6 syntax):
1 - 100 of 239 matches
Mail list logo
