On Jul 24, 2005, at 2:40 AM, Sam Vilain wrote:
Stevan Little wrote:
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
Stevan Little wrote:
This is extended into the other sigil types;
has %.foo;
is sugar for this:
has Hash $foo; # or has %foo, but really, the point is it's
# an implementation detail, right?
method foo is rw {
return Proxy.new( :FETCH{ $foo }, # or a facade
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
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
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
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
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
:
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
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
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
On 7/21/05, Larry Wall [EMAIL PROTECTED] wrote:
Have at it...
The only thing I immediately don't like is the use of the normal identifier
character _ to indicate the specialness of a particular variable (or
attribute or whatever we're calling them these days). IMO, a _ should
just be a _ no
Larry Wall wrote:
has $x; # private rw, no accessors, not virtual, name lexically scoped
has $_x;# private rw, rw _x accessor, not virtual, name class scoped
Even if I come across as intellectually handicapped but could
someone help me over this mental bridge: What is the
On Thursday 21 July 2005 12:48 pm, Larry Wall wrote:
* Don't need to topicalize self any more.
* .foo can (again) always be the topic without warnings.
Thank you.
Do the following exist then:
has @x; # private, lexically scoped
has @_x; # private, class scoped, rw _x accessor
On Thu, Jul 21, 2005 at 02:29:33PM -0600, Paul Seamons wrote:
: On Thursday 21 July 2005 12:48 pm, Larry Wall wrote:
: * Don't need to topicalize self any more.
:
: * .foo can (again) always be the topic without warnings.
:
: Thank you.
:
: Do the following exist then:
:
:has @x;
Larry,
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.
I personally don't like this, I think it brings us back to Mix-ins and
(possibly) looses some of
On Thu, Jul 21, 2005 at 05:15:34PM -0400, Stevan Little wrote:
: Larry,
:
: 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
On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
: On 7/21/05, Larry Wall [EMAIL PROTECTED] wrote:
: Have at it...
:
: The only thing I immediately don't like is the use of the normal identifier
: character _ to indicate the specialness of a particular variable (or
: attribute or
Larry Wall wrote:
: Do the following exist then:
:has @x; # private, lexically scoped
[...]
:has %y; # private, lexically scoped
[...]
Yes, the sigil is fairly orthogonal to all this, hopefully.
Yes, for isn't the sigil just a compact form of saying does Hash or
does Array ? (as
Sam Vilain [EMAIL PROTECTED] writes:
Larry Wall wrote:
Users of the class includes people subclassing the class, so to them
they need to be able to use $.month_0 and $.month, even though there
is no has $.month_0 declared in the Class implementation, only
has $.month.
We thought
Piers Cawley wrote:
Users of the class includes people subclassing the class, so to them
they need to be able to use $.month_0 and $.month, even though there
is no has $.month_0 declared in the Class implementation, only
has $.month.
We thought about defining the attribute variables
On Tue, Jul 19, 2005 at 02:21:44PM +1200, Sam Vilain wrote:
: Larry Wall wrote:
: Users of the class includes people subclassing the class, so to them
: they need to be able to use $.month_0 and $.month, even though there
: is no has $.month_0 declared in the Class implementation, only
:
On Mon, Jul 18, 2005 at 03:34:36PM +1200, Sam Vilain wrote:
: Say I make an accessor method for an attribute that doesn't really
: 'exist'.
:
: For instance, a good example of this is the month_0 vs month
: properties on a date object; I want to make both look equivalent as
: real properties, but
Larry Wall wrote:
Users of the class includes people subclassing the class, so to them
they need to be able to use $.month_0 and $.month, even though there
is no has $.month_0 declared in the Class implementation, only
has $.month.
We thought about defining the attribute variables that
23 matches
Mail list logo
