On Sat, 12 Oct 2002, Larry Wall wrote:
> On Sat, 5 Oct 2002, John Williams wrote:
> : Personally, I hope they look like attributes.
>
> They will, outside the class anyway. Inside it's $.foo.
>
> : But if they do, the perl5
> : lvalue subs are not the way to do it. Why? Because an lvalue sub re
On Sat, 5 Oct 2002, John Williams wrote:
: I think everyone agrees that some sort of simple accessor syntax will be
: included (instead of the getX/setX hack). But will accessors _look_ like
: attributes or methods?
:
: # look like methods
: object.foo($value);
:
: # look like attri
On Sunday, October 6, 2002, at 12:57 AM, Noah White wrote:
>>
>>> Note that an alternate definition of "private" is often used, as
>>> follows:
>>>
>>> A "private" attribute is an attribute whose scope is restricted
>>> such that
>>> it may be accessed only within the class in which it
At 4:29 PM -0600 10/5/02, John Williams wrote:
>On Sat, 5 Oct 2002, Michael Lazzaro wrote:
>
>> Dan Sugalski wrote:
>> >
>> > There won't be any direct access to attributes outside class methods
>> > of the class that defines the attributes, unless Larry changes his
>> > mind in a big way. (A
>
>> Note that an alternate definition of "private" is often used, as
>> follows:
>>
>> A "private" attribute is an attribute whose scope is restricted such
>> that
>> it may be accessed only within the class in which it has been
>> declared,
>> OR WITHIN ANY CLASS THAT INHERITS
On Friday, October 4, 2002, at 07:39 PM, Michael Lazzaro wrote:
[SNIP]
> Definition: "private":
>
> A "private" attribute is an attribute whose scope is restricted such
> that
> it may be accessed only within the class in which it has been
> declared.
> It is not available
John Williams:
# Personally, I hope they look like attributes. But if they
# do, the perl5
# lvalue subs are not the way to do it. Why? Because an
# lvalue sub returns
# a lvalue which get set _after_ the sub returns. At that
# point it is too
# late for the sub to do anything useful wit
On Sat, 5 Oct 2002, Michael Lazzaro wrote:
> Dan Sugalski wrote:
> >
> > There won't be any direct access to attributes outside class methods
> > of the class that defines the attributes, unless Larry changes his
> > mind in a big way. (And, honestly, probably not even then) Instead
> > it'll al
At 12:53 PM -0700 10/5/02, Michael Lazzaro wrote:
>Dan Sugalski wrote:
>>
>> There won't be any direct access to attributes outside class methods
>> of the class that defines the attributes, unless Larry changes his
>> mind in a big way. (And, honestly, probably not even then) Instead
>> it'll
Dan Sugalski wrote:
>
> There won't be any direct access to attributes outside class methods
> of the class that defines the attributes, unless Larry changes his
> mind in a big way. (And, honestly, probably not even then) Instead
> it'll all be accessed via lvalue methods. If an attribute is exp
At 4:39 PM -0700 10/4/02, Michael Lazzaro wrote:
>Under the principle of TMTOWTDI, perl allows public attributes
>within a class. However, you must explicitly declare an attribute
>to be public.
There won't be any direct access to attributes outside class methods
of the class that defines the
This all looks good to me. I seem to have gone off on a tangent about
slots, so I've mercifally changed the subject.
On Fri, Oct 04, 2002 at 04:39:40PM -0700, Michael Lazzaro wrote:
> [CONS]
>
> - Making publicly accessible attributes at all is considered Bad Form
> in most OO methodologies (
(Disclaimer: My purpose in proposing this is not to recommend it, but
to document whether the idea should be endorsed, or shot down, and any
proposed canonical syntax. Note that the later implications of these
choices are quite substantial. Please discuss!)
[Draft Proposal: Attributes
13 matches
Mail list logo
