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'
# 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
This tests are actually passing. I unfudged the tests with commit
https://github.com/perl6/roast/commit/a5397a6a09
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
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
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.
# URL: 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
Made a few more text edits in r17591. Paul Cochrane's changes approved,
ticket resolved.
: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 places to glean information
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #41505]
# in the subject line of all future correspondence about this issue.
# URL: 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.
# URL: 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 to do them
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, as that's a PMC too
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 efficient implementation
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 ways to handle that now too. I don't
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 closed;
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
# API to do it without an eval
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
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 Parrot offers quite a few ops
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 from
I'd planned
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 isalpha, islower, isprint, etc. Here
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, and maybe someone
# New Ticket Created by Will Coleda
# Please include the string: [perl #31181]
# in the subject line of all future correspondence about this issue.
# URL: 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.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31134
Find a decent way of including Unicode properties tables
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
.
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 properties have in common with
Parrot
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
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
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
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
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
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
--- 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 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
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
--- 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
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
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
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
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
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;
1 - 100 of 316 matches
Mail list logo
