These tests have been adjusted with
https://github.com/perl6/roast/commit/551a7ffd7b
I'm closing this ticket as 'resolved'.
On Wed, 04 Jan 2017 21:27:05 -0800, samant...@posteo.net wrote:
> Also see this bisectable results:
> https://gist.github.com/Whateverable/50acf5fe072680085746459f144a106f
>
> You can see how with the new commit, 'space' and 'White_Space' now
> resolve to the same property. Before 'space' resolved
# New Ticket Created by Samantha McVey
# Please include the string: [perl #130483]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130483 >
See test in properties-general.t
The test used to pass before, but only beca
These todo tests are fudged for the JVM only and are now passing.
Removed the fudge, closing ticket.
--
Will "Coke" Coleda
These tests are actually passing. I unfudged the tests with commit
https://github.com/perl6/roast/commit/c9e7946599
These tests are actually passing. I unfudged the tests with commit
https://github.com/perl6/roast/commit/c9e7946599
These tests are actually passing. I unfudged the tests with commit
https://github.com/perl6/roast/commit/c9e7946599
This tests are actually passing. I unfudged the tests with commit
https://github.com/perl6/roast/commit/a5397a6a09
-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 - obvious
> This check can be removed from default.pmc. Property values should not
> be returned by get_attr_str.
Done in r31509
On Mon Oct 22 09:34:51 2007, ptc wrote:
> In src/pmc/default.pmc:get_attr_str() there is the todo item:
>
> /* let's look for props first
> * XXX do we need that in the default object system?
>
> We require an answer to this question, and quite possibly further
> development depending upon the
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46667]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46667 >
In src/pmc/default.pmc:get_attr_str() there is the todo item:
/* let's look for props
Made a few more text edits in r17591. Paul Cochrane's changes approved,
ticket resolved.
e.
On Wed Feb 14 06:44:16 2007, ptc wrote:
> Documentation related to svn properties on files within Parrot needs
> to be cleaned up and reorganised. Namely put into the one place, and
> expanded upon. The current candidate for such a location is the
> coding standards pdd. Initial
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #41505]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41505 >
Documentation related to svn properties on files within Parrot needs
to be cleaned
# New Ticket Created by Allison Randal
# Please include the string: [perl #41264]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41264 >
Extracted from ticket # 40443.
...properties don't get serialized so if you
chromatic wrote:
The only time I've ever used properties in PIR was to mark an object
initializer, but we have better ways to handle that now too. I don't object
to having them, but I do think we ought to have at least one good use case to
help decide what they need to do and how
ou'd always pay for having the data member available in the PMC
struct. Otherwise, you could copy everything to a new struct with a new PMC
member, but that's also painful.
The only time I've ever used properties in PIR was to mark an object
initializer, but we have better way
Leopold Toetsch wrote:
>
> Properties are never inherited, they belong to just that one PMC.
Well, yeah. That's what they're designed to do. But agreed that for the
sake of clarity attributes and properties should keep two separate names.
> Therefore a
> much more effic
Hi @all,
[ shortened: ]
Recommendation: Deprecate property support in PMCs.
Allison: Would it help if we call them "static attributes" and "dynamic
attributes"?
No. Attributes and properties are almost orthogonal concepts.
Properties are per PMC (or object,
On Fri, Nov 11, 2005 at 11:23:34AM -0800, Jerry Gay via RT wrote:
> has this been addressed, even partially? it seems that it has, but this
> ticket, nor the related email thread
> (http://www.nntp.perl.org/group/perl.perl6.internals/29394) has been
> updated since may 2005.
The ticket can be clos
has this been addressed, even partially? it seems that it has, but this
ticket, nor the related email thread
(http://www.nntp.perl.org/group/perl.perl6.internals/29394) has been
updated since may 2005.
~jerry
I don't understand why you think you need the eval here?
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
> There is syntax to define trait and properties
> but is there an API?
>
> my $b = eval '$a but true'; # setting a true property
>
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 retriev
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 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 e
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
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 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 a
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 eva
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.
Incident
Patrick R. Michaud wrote:
[ see below for some more ]
Actually, overnight I realized there's a relatively good-sized
project that needs figuring out -- identifying character properties
such as isalpha, islower, isprint, etc. Here I'll briefly sketch
how I'd like it to work, an
On Wed, May 04, 2005 at 12:30:48PM -0400, Dan Sugalski wrote:
> At 10:21 AM -0500 5/4/05, Patrick R. Michaud wrote:
> >Actually, overnight I realized there's a relatively good-sized
> >project that needs figuring out -- identifying character properties
> >such as isal
le to take on?
Actually, overnight I realized there's a relatively good-sized
project that needs figuring out -- identifying character properties
such as isalpha, islower, isprint, etc. Here I'll briefly sketch
how I'd like it to work, and maybe someone enterprising can take
things
rnight I realized there's a relatively good-sized
project that needs figuring out -- identifying character properties
such as isalpha, islower, isprint, etc. Here I'll briefly sketch
how I'd like it to work, and maybe someone enterprising can take
things from there for us.
Currently P
# New Ticket Created by Will Coleda
# Please include the string: [perl #31181]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31181 >
Implement character class & properties testing (for regular expressions)
# New Ticket Created by Will Coleda
# Please include the string: [perl #31134]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31134 >
Find a decent way of including Unicode properties tables. (Not for
the fa
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
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
Larry noted:
> There's a lot to be said for being able to write
things like:
[ & + ]
Now I'm supposing that & binds tighter than | as usual, so the
brackets wouldn't always be necessary:
& +
|
& +
FWIW, I'm strongly in favour of adding & to rules.
Indeed, if Larry were to gi
[ + | + ]
or really, just
& <|>+
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 and what's swahili...
Larry
string-like things via scalar
: 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
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 occu
ry.
I swear, I'm going to rename these things to Fred and Barney and not
tell anyone which is which...
Ordered by ascending esotericism:
Fields: Class data members.
Properties: Syntactic sugar for getter and setter methods.
Attributes: Extensible metadata for c
At 4:41 PM +0100 2/27/04, Paolo Molaro wrote:
On 02/27/04 Dan Sugalski wrote:
> What .NET calls an attribute parrot calls a property
> What .NET calls a property parrot calls an attribute
[...]
Oh, yeah. No matter which way we go we'll be confusing someone, since
there are languages that call
attribute an attribute.
> The .NET reversal's just the big nasty one.
In the CLR properties are defined by:
a name
an optional set method
an optional get method
One of the two methods must exist (enabling readonly/writeonly
properties). So, the only thing CLR proper
At 5:29 PM -0500 2/26/04, Mitchell N Charity wrote:
docs/pdds/pdd15_objects.pod, =head2 Translation, includes (edited)
What .NET calls an attribute parrot calls a property
What .NET calls a property parrot calls an attribute
Ouch.
Oh, yeah. No matter which way we go we'll be confusing someone,
docs/pdds/pdd15_objects.pod, =head2 Translation, includes (edited)
What .NET calls an attribute parrot calls a property
What .NET calls a property parrot calls an attribute
Ouch.
In these lines one hears the echos of future years of confusion,
endlessly repeated explanations, failed searches
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 a
SUPER::STORE($newval but [EMAIL PROTECTED]) }
> }
> @bar but= property_wrap(false, foo);
>
> ? The examples I remember from the As and Es all have round brackets
> around trait parameters (Hmm. And I can only remember is-trait examples
> too). Granted, the universe c
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
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?
> ...r
--- 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
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: C is not a trait.
But indeed foo would a
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{
--- 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 rig
[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
> 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 Y
--- 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
On Tuesday, December 2, 2003, at 12:37 PM, Luke Palmer wrote:
Michael Lazzaro writes:
There were also vaguely threatening proposals to have <> and
>>op<<
do slightly different things. I assume that is also dead, and that
<> is (typically) a syntax error.
Ack. No, slightly different things would
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
Ã
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,
> >n
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*
; (Sorry, no
fancy chars here. :)
> 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:
>
>
ght 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
> vectorizab
> 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;
> >
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
#x27;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
On Thursday, November 27, 2003, at 04:21 , Larry Wall wrote:
(Oh, apparently C# 2.0 is thinking along the same lines with its
"partial classes", though I haven't looked at those in detail.)
My reading was that C# 2's partial classes were merely a mechanism for
placing long method definitions in
,
um, yes.
> Now the hard question.
>
> my $tst = Baz.new();
>
> How do I set a zippy property on $tst explicitly using Bar's zippy?
Probably just
$tst but= Bar::zippy;
I imagine that properties work just like other names, so they can be
stuck in package symbol ta
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/
> : 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
> : 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! :)
> : Ju
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
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... :-)
: Just for my vote, I want to be able to declare new pr
--- 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/
--- 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
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
&g
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 to be lexical? If a value or
: container with
me 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 are created when you assign a
: value to a previously nonexistant key, but that's exactly
ty you have to say:
> >
> > $x but= bar;
>
> I think that would 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.
Assumi
--- 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
>
sh restriction; people who know how 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 predeclare
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 comp
--- 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.
[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)
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 C to assign a property to a I:
:
: $a = $b but foo; # $a has property foo, $b
Here's a series of questions/confirmation requests about how properties
work (but specifically run-time properties, not traits):
Use C to assign a property to a I:
$a = $b but foo; # $a has property foo, $b does not
Properties are just out-of-band methods:
if $x.foo { prin
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
--- 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?
Treati
> 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
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
, evil man for reminding me of this. I have yet to
brainvomit about stack-streams. (I have found an interesting analogy
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
> implement
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, typedef-
it like this, I wonder?
Since C 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 C "object", you should be able to
override them individually if you want, for example, an alternate
. Thanks. Still I 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.
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;
ty
--- 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.
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 of
1 - 100 of 346 matches
Mail list logo
