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
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:
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 METHOD" being executed in Role context. I wont ev
Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
> : Damian may not like the colon, but I couldn't help thinking that the "_"
> : could be replaced with ":" and things would be cleaner. Example:
>
> Well, but the _ really is part of the name,
On Fri, 2005-07-22 at 20:35 +0200, "TSa (Thomas Sandlaß)" wrote:
> Ups, I hoped that the type system would find out mismatches of the
> objects actual structure and the methods expectations of it. Essentially
> rendering the method in question not applicable to the object anymore.
I'm not sure th
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
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 privat
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
>
On Fri, Jul 22, 2005 at 12:53:45AM -0700, Brent 'Dax' Royal-Gordon wrote:
: 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 i
Ack, I screwed up that last email with some bad copy and paste. Ignore it
in favor of this one please :)
---
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 people
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 people to think of the private methods as being in a different
> namespace so that there's no confusion about the fact
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
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 do
> 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 privat
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 priv
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.
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" ?
On 7/21/05 8:14 PM, Larry Wall wrote:
> On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
>> 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 th
On Thu, Jul 21, 2005 at 10:17:13PM +0200, "TSa (Thomas Sandlaß)" wrote:
: 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 intellect
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
: attribut
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 squint
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 th
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 @
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 access
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 diffe
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
HaloO Sam,
you wrote:
This in turn implies that the $.foo syntax is, in general, bad
practice!
Yup.
I claim the opposit. But I might have a very different meaning in mind
when I say that. So it's opposit in an orthogonal direction :)
Not very huffmanised, is it?
The syntax is just right
On Thu, Jul 21, 2005 at 05:16:39PM +1200, Sam Vilain wrote:
: Making $.foo =:= $?SELF.foo, and getting to the "raw" attribute $.SUPER::foo
: seems like the better solution to me. But of course, it would, because
: that's
: how *I* program, and $?SELF != all(@coders).
:
: Then we could even sneak
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 va
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 $.m
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, onl
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 varia
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
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 without the users of the class knowing which
one is the "real" on
34 matches
Mail list logo
