Re: Built-in properties vs. user-defined methods (was: 'is' and action at a distance)
On 5/19/01 4:49 AM, Graham Barr wrote:
> On Sat, May 19, 2001 at 06:41:29PM +1000, Damian Conway wrote:
>> Graham wrote:
>>> On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote:
> print keys $foo.prop; # prints "NumberHeard"
> print values $foo.prop; # prints "loneliestever"
>>>
>>> This is an example of one of my concerns about namespace overlap
>>> with methods. What would happen if there was a method called prop ?
>>> Have we basically said that there cannot be a method called prop ?
>>
>> No, we have basically said that there cannot be a method called prop if you
>> want to access the object's properties through its prop property.
>
> Which mean that any class which defines a method prop, prevents any user
> from determining the properties of any of its object instances.
>
> I am not saying that this is a bad thing, but it will need to be docuemnted
> that doing this has such consequences. Unless there is another syntax
> for determining all the properties of a value.
To recap my previous message(s) on this topic...
My interpretation of this has always been than it's a naming *convention*
issue. After all, "system stuff" and "user stuff" have always had to live
together in the various Perl namespaces. But historically, there've been
guidelines to make this manageable.
Take the method namespace, for example. That's shared by the system and the
user, with the simple guideline that the system claims uppercase methods
(AUTOLOAD, TIEHASH, etc.) The class/package namespace follows the same
guidelines (ARRAY, HASH, SCALAR, etc.)
Even Perl 6 properties (appear to :) solve the namespace problem by
convention: all-lowercase properties are reserved for built-ins: constant,
memoized, etc. User-defined properties are Title Cased: $foo.Notes,
$bar.Purpose, etc.
The problem area is the intersection between:
* reading built-in properties, and
* calling user-defined methods
Both lay claim to the $foo.lowercase_letters syntax and naming convention,
leading the the problems cited in other posts.
Actually, it's only as big a problem as the proliferation of built-in
properties makes it. If the list of built-in properties is small and fairly
constant, it's probably something that can be dealt with.
I've tossed around ideas like changing the convention for built-in
properties to uppercase (to match built-in classes and methods), but it
still strikes me as ugly:
$foo is CONSTANT = 5;
if($foo.CONSTANT) { ... }
Ick. Then there's the suggestions to differentiate between method calls and
property access, but that kind of kills a huge part of the whole properties
scheme. I basically have no good solutions at this point, heh. I just
figured I'd re-spew my take on the subject for the benefit of this list...or
something :)
-John
A couple of ideas about properties
Note the time I sent this out. My mind may not be thinking quite straight
at this point, so bear with me.
First of all, the dot dispute. If we want a way to absolutely make sure
we're checking a scalar's properties, why not reuse our keywords?
$foo is constant; #sets $foo's constant property to true
is $foo constant; #returns value of $foo's constant property
This avoids the possible ambiguity of C<$foo.constant> without adding any
new keywords or requiring the absence of a C<.prop> member. This also reads
like English:
Foo is constant.
Is foo constant?
Second, the values vs. variables problem. I'm sorry, but
C<(+$foo).whatever> is just way too ugly. Plus, it's really hacky and
inexpressive. Perl is supposed to be an expressive language, right?
This issue can be avoided altogether if we just say, "properties must
declare whether they attach to variables or values." This makes some
sense--what does C mean attached to a value? Is attaching C
to a variable a good idea?
This could also probably be done with minimal keyword impact. I'm not sure
if anyone has said how properties are implemented, but for the sake of
argument I'll assume they're somehow implemented as subs. If so, we could
just do:
sub foo is property(value) {#property that attaches to the value
...
}
sub bar is property(variable) { #property that attaches to the variable
...
}
Even if it was actually implemented some other way, all we'd need to do is
make sure that we can attach properties to it somehow. (The C
property would itself attach to a variable, not a value.)
--Brent Dax
[EMAIL PROTECTED]
Re: properties
On Sun, May 20, 2001 at 12:46:35AM -0500, Jonathan Scott Duff wrote: > my $a is true = 0; # variable property > my $a = 0 is true; # variable property > my ($a) = 0 is true;# value property Wow. Totally ETOOCONFUSING. -- "I find that anthropomorphism really doesn't help me with a place full of bugs." -- Megahal (trained on asr), 1998-11-06
Re: A couple of ideas about properties
On Sun, May 20, 2001 at 01:09:28AM -0700, Brent Dax wrote: > This also reads like English: > Is foo constant? Until you realise that in order to actually use it sensibly, you'll have to say something like if (is $foo constant) instead of (as I would prefer) if ($foo is constant) -- "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken
Re: 'is' and action at a distance
On Sat, May 19, 2001 at 11:26:36AM +1000, Damian Conway wrote: > Not. The run-time property is set on the *value* in $Foo, not on the variable > itself. Change the value, change the properties. Ok, that makes me happy. :) -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Death follows me like a wee followey thing. -- Quakeman
RE: A couple of ideas about properties
Simon Cozens:
>On Sun, May 20, 2001 at 01:09:28AM -0700, Brent Dax wrote:
>> This also reads like English:
>> Is foo constant?
> Until you realise that in order to actually use it sensibly, you'll
have to say something like
> if (is $foo constant)
> instead of (as I would prefer)
> if ($foo is constant)
That depends on how you read an if statement. Personally, I read them
inside out, so I would read it as:
Is foo constant?
If so, do this.
Of course, most people do read them left to right, which does seem a lot
more like natural language. So maybe I'm just weird. (Inside out is more
useful for me in general when programming, so I just apply it everywhere.
Think about complicated subscripts or parenthesized expressions and you'll
see why.)
Having infix C be its value in Boolean context would probably not be a
good idea, so I won't suggest it.
An interesting thought just occured to me: are we going to implement tying
through properties?
my $foo is tied('Tie::SomethingOrOther', *@params);
This kinda fits in with the other properties we're using, where they
(conceptually) don't have any effects until later in the program. (Of
course, just as C<$fh is chomped> does actually do *something* at that
point, C<$foo is tied> would actually do something, but you don't think of
it as doing so.) Plus, you can access the underlying object through
$foo.tied (or whatever mechanism it may, but probably won't be, changed to).
Plus, that would mean that we'd freed up the C keyword.
This brings up another point: How do we un-property something? I know that
to undo $foo is true, you can just say $foo is false, but what if you now
want the variables trueness to be just like any other variable's trueness?
Perhaps we should add something to take away a property:
$foo is true; #$foo.prop{true}=(whatever)
.
.
.
$foo isnt true; #delete($foo.prop{true}), at least in Perl 5 terms
If we went with the C suggestion I made above, that means we've
just replaced a specific mechanism (untie()) with a more general mechanism
(isnt). In fact, if you muck with the meaning of not a bit, you could have
it be:
$foo is not true;
which avoids the adding of C, as well as the seemingly inevitable
problem of people putting the apostrophe in. I think the compiler would be
able to figure out what not means based on context. Of course, I could be
wrong. I've never written a real parser before, much less one as magical as
Perl's.
--Brent Dax
[EMAIL PROTECTED]
Fear the sys command on a windows boot disk. It can ruin your whole day.
Re: Perl, the new generation
Adam Turoff <[EMAIL PROTECTED]> writes:
> It's also amazing how long some people can go without seeing a
> statement modifier or non-default delimiters like s{}{};. In the
> micro view, that's OK. In the macro view, it leads to Perl Mongers
> meetings that feel more like AA:
Which reminds me, must write up that proposal for YAPC::Europe...
--
Piers Cawley
www.iterative-software.com
Re: properties
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> The C is actually optional wherever it can be inferred, which is handy
DC> for chained properties:
DC> my $bar is Persistent Public Logged;
DC> ...
DC> return $bar is Open Smoking("non") Theme($theme);
DC> and can also improve the euphony (eulecty???) of code:
DC> return undef Because($borked);
hmm, that is poor code as returning a real undef will break in a list
context. so how would a value property be attached passed back to an
empty list? what happens below:
sub reason {
return is Because('i said so') ;
}
@excuses = reason() ;
$excuse = reason() ;
$first_excuse = shift @excuses ;
do any of those have a Because value property?
BTW i think the clarification of permanent and value properties was well
timed. now we need to come up with both a keyword/syntax and some
standard english descriptions for them. i use value property in the
above and it works for me -it's succinct, easy to understand, and
accurate. there have been several descriptions of (my so-called)
permanent properties and none jump out at me. those are the compile time
ones for variables and subs and other non-values.
but that brings up a point, what kind of properties does an anonymous
sub carry, permanent or value? explain this code (with correct damian
syntax i hope):
my $st_cmp = sub is SortCode('ST') { $a->[0] cmp $b->[0] } ;
$st_cmp is SortCode('GRT') ;
what does that do or mean?
DC> As the last example shows, within such overriding methods, there has to
DC> be some way of accessing the actual property we're repackaging. We do
DC> that via the builtin C property, which returns a reference to a
DC> hash containing all the properties of a value or variable:
DC> $foo = 1 is Number("loneliest") Heard("ever");
DC> print $foo.Number; # prints "loneliest"
DC> print $foo.prop{Number};# ditto
DC> print keys $foo.prop; # prints "NumberHeard"
DC> print values $foo.prop; # prints "loneliestever"
and what if $foo had a method named 'prop'? shouldn't there be an out of
band way of accessing that propery hash? why not also have a special
function (not using method/prop syntax)
$foo_prop = value_props( $foo ) ;
$foo_var_prop = perm_props( $foo ) ;
those return hash refs to the value and permanent (variable/sub)
props. in a hash or list context they return the key/value list.
also these can be used to access individual properties with the property
name as the optional second argument and the value(s) as the optional
list after that.
$sort_code = value_props( $foo, 'SortCode' ) ;
perm_props( $foo, 'SortCode', 'ST' ) ;
perm_props( $foo, 'SortCode' ) = 'ST' ;
the last one assigns the prop value with an lvalue call.
most of the time the . form should used but having these funcs supported
means you can always be explicit about what you want and you can bypass
any bizarro names that are in your object tree.
DC> my $var is Purpose("var demo") = 1 is Purpose("val demo");
DC> print $var.Purpose; # prints "var demo", not "val demo"
DC> the variable first:
or use perm_props( $foo, 'Purpose' ) ;
DC> print (+$var).Purpose; # prints "val demo", not "var demo"
or use value_props( $foo, 'Purpose' ) ;
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
Re: 'is' and action at a distance
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> I think it would be better if we stilled two curds with one bone. We LW> can have a more obscure name, plus differentiate the prop tables at the LW> same time. So how 'bout we have two methods, such as: LW> $foo.variable_is LW> $foo.value_is hmm, in catching up with mail i saw damian's long property exegesis and i replied with a suggestion asking to split the value/permanent (or as above value/variable) props and then i see this. good to know i am on the right wavelength. but can a code ref a set of variable properties? that is why i am using the term permanent (or set at compile time and unmutable). another point: how can you delete properties? obviously this can only be done with value properties. an accessor method has no clean way of separating plain access $foo.bar() from some way to assign a null list to it. you can assign an explict undef but that is not the same as deletion. so a delete_value_prop func/method should be supported in some fashion. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
Slice refs
Um, this is a tiny little diversion here prompted by something that came up
on perl-beginners, of all places... it's not possible in perl 5 to make a
reference to an array or hash slice without doing some copying. It would
be nice if perl 6 made that possible. Maybe it already does and I haven't
grokked that from the exegeses yet.
That's it. We now return you to the Clinton discussion ("it depends what
the meaning of 'is' is...")
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
Re: Slice refs
Peter Scott wrote:
>
> Um, this is a tiny little diversion here prompted by something that
> came up on perl-beginners, of all places... it's not possible in
> perl 5 to make a reference to an array or hash slice without doing
> some copying.
>
Hey, this is *Perl*! Of course it's possible...
---cut---cut---cut---cut---cut--
@A = (1..10); # array
@I = (3..5);# indices of desired slice
$ref =
sub{my%k;@k{@{+pop}}=\(@_);splice@_,$_,!$k{$_}for reverse 0..@_;\@_}->(@A,\@I);
print "@A\n";
print "@A[@I]\n";
print "@$ref\n";
$ref->[1] = 99;
print "@A\n";
print "@A[@I]\n";
print "@$ref\n";
---cut---cut---cut---cut---cut--
;-)
>
> It would be nice if perl 6 made that possible.
>
I guess that would be:
$ref = sub{my%k;%k{+pop}=\(@_);splice@_,$_,!%k{$_}for @_..0:-1;@_}.(@A,\@I);
>
> Maybe it already does and I haven't grokked that from the exegeses yet.
>
I'm pretty sure Exegesis II doesn't mention *that* particular technique ;-)
Damian
Re: Slice refs
At 01:31 PM 5/21/2001 +1000, Damian Conway wrote:
>> Um, this is a tiny little diversion here prompted by something that
>> came up on perl-beginners, of all places... it's not possible in
>> perl 5 to make a reference to an array or hash slice without doing
>> some copying.
>>
>
>Hey, this is *Perl*! Of course it's possible...
>
>@A = (1..10); # array
>@I = (3..5);# indices of desired slice
>
>$ref =
> sub{my%k;@k{@{+pop}}=\(@_);splice@_,$_,!$k{$_}for reverse
> 0..@_;\@_}->(@A,\@I);
Oh, well, if I'd known it was *that* succinct...
But... that *does* involve copying; the original poster was talking about
huge arrays where copying was actually significant. You've got the list of
keys and values in the temporary hash there. It certainly violates the
spirit of the request. Which still seems like a reasonable request.
A reference to a slice in perl 5 yields the list of the references to the
slice members. Is that the way it's going to be in perl 6?
