Re: Classes with several, mostly unused, attributes
On Wed, 15 Dec 2004, Abhijit Mahabal wrote: #!/usr/bin/perl -e $x = 1; Is this supposed to work? I would tend to consider it counter intuitive... #!/usr/bin/perl v6; $x = 1; Incidentally, and on a totally OT basis, I've noticed that Perl6 is supposed to have v-strings. But (current) 'perldoc perldata' warns that they won't be there after 5.8: taking all this into account I wonder wether this would be a wyse choice. I mean: maybe it hasn't been such a good thing to introduce them in the first place, but now that they're there, it may be even worse to remove them... Michele -- The amount of repetition repetition isn't that great. - Ignacy Sawicki in comp.text.tex thread Bug in FeynMF's Queues?
Re: Classes with several, mostly unused, attributes
On Thu, Dec 16, 2004 at 10:42:35AM +0100, Michele Dondi wrote:
: On Wed, 15 Dec 2004, Abhijit Mahabal wrote:
:
: #!/usr/bin/perl -e
: $x = 1;
:
: Is this supposed to work? I would tend to consider it counter intuitive...
It occurred to me as I was dropping off to sleep last night that it
can't work on any OS that processes #! for you, since there's no way
to pass an argument to the script that wouldn't be misinterpreted as
the argument to -e. So forget that subidea. -e still sets lax mode,
of course.
: #!/usr/bin/perl
: v6; $x = 1;
:
: Incidentally, and on a totally OT basis, I've noticed that Perl6 is
: supposed to have v-strings. But (current) 'perldoc perldata' warns that
: they won't be there after 5.8: taking all this into account I wonder
: wether this would be a wyse choice. I mean: maybe it hasn't been such a
: good thing to introduce them in the first place, but now that they're
: there, it may be even worse to remove them...
The problem wasn't the syntax so much as the semantics. In Perl 6,
Cv6 creates a string, not an object, so there's no way to overload
its operators to avoid conflicts with other kinds of strings.
In Perl 6 Cv6 makes a version object, not a utf-8 string, and
they compare using numeric operators instead of string operators.
(Perl 5's v-strings had a numeric component that was an old-style
floating point number version (5.00401, for instance), and you could
compare those numerically. Perl 6 will be able to handle those via
MMD without compromising the normal comparison semantics when you
compare two version objects with numeric comparisions.)
The other places v-strings cause ambiguity problems in Perl 5 have
also been addressed, at least insofar as
v6 = mumble
always autoquotes its left side even if it's a keyword, and
%blech{v6}
never autoquotes anymore, so there's never any keyword ambiguity in either
of those places.
Larry
Re: Classes with several, mostly unused, attributes
On Fri, Dec 10, 2004 at 11:05:32AM -0500, Abhijit Mahabal wrote:
: Consider a class (e.g., the hypothetical Geometry::Triangle) that can
: have several attributes (side1, side2, side3, angle1, ang_bisector1,
: side_bisector, altitude1 and so forth), most of which will not be
: needed for most instances of Geometry::Triangle.
This sounds to me more like a situation where you want to use mixins,
if you're thinking of it as different kinds of triangles.
But more likely, you just want a single private hash attribute that is
manipulated by as many publicly facing methods as you like. Method
declarations don't cost you anything on a per-object basis unless they're
autogenerated from an attribute. But a hash attribute autovivifies
just like any ordinary hash variable, and is probably clearer as well
to whoever has to read your code.
Alternately, you can still bless a hash as you typically do in Perl 5,
but then you get most of the problems of Perl 5 if you want to derive
from your class.
: I know how this can be done in P5. Using the layout Hash things are
: easy. How can P6 deal with this, without allocating too much memory to
: things that'd never get used? The layout P6Hash could come to the
: rescue, but there is still the issue of syntax:
:
: what exactly does Chas $.bisector1 do?
It does whatever the metaclass says has should do. But you really want
to have a good reason for switching metaclass behavior from the default.
: IIRC, in the P6Opaque layout,
: every instance of the class would have space the size of a PMC allocated
: for it. This behavior is not needed for P6Hash, and it should just leave
: attributes alone until they are assigned to (where defaults are also
: assigns).
I think the overhead might just be a pointer to a PMC, but I'm not
an expert on Parrot OO internals.
: In which case, maybe for that layout we can get away without declaring
: all attributes, perhaps? (Since the declaration does nothing except help
: the parser).
The layouts are mostly intended to help in detecting impedance mismatches
between different languages' objects. Doubtless you can play games with
different layouts within Perl 6, but you should recognize that you'll run
into the same issues as you get with cross-language inheritance: you'll
probably end up with inheritance being emulated by delegation, which
is likely to induce various sorts of fragilities and inefficiencies.
: I was thinking whether we could do something like this:
:
: class Triangle is layoutP6Hash does autovivify{
: method calculate_bisectors { $.bisector1 = ...;
:# $.bisector1 autovivifies
: }
: }
:
: where it is an error without the autovivify, and only P6Hash supports
: autovivification.
I'd just use a hash attribute. All other things being equal, go for
simple and standard.
Larry
Re: Classes with several, mostly unused, attributes
Larry Wall wrote:
On Fri, Dec 10, 2004 at 11:05:32AM -0500, Abhijit Mahabal wrote:
: Consider a class (e.g., the hypothetical Geometry::Triangle) that can
: have several attributes (side1, side2, side3, angle1, ang_bisector1,
: side_bisector, altitude1 and so forth), most of which will not be
: needed for most instances of Geometry::Triangle.
This sounds to me more like a situation where you want to use mixins,
if you're thinking of it as different kinds of triangles.
But more likely, you just want a single private hash attribute that is
manipulated by as many publicly facing methods as you like. Method
declarations don't cost you anything on a per-object basis unless they're
autogenerated from an attribute. But a hash attribute autovivifies
just like any ordinary hash variable, and is probably clearer as well
to whoever has to read your code.
So, apart from declaring the methods, I just need to write
.bisector1 = ...;
instead of
$.bisector1 = ...;
Yes, that looks almost as nice as with the $, though perhaps a tad less.
That leaves the issue of writing several methods that look like:
method bisector1() is rw { return %:attbisector1 };
Here is an attempt to do this using traits:
#
role hash_attributes {
has %:att;
multi sub trait_auxillary:has(hash_attributes $trait,
Class $container :
[EMAIL PROTECTED]
){
$container does hash_attributes;
for @atts - $att {
($container)::($att) := method () is rw { return %:att{$att} };
}
}
}
class Geometry::Triangle
has hash_attributes == side1 side2 side3 angle1 angle2 angle3 ...
{
method calculate_sides(){
.side1 = ...;
}
}
#=
Does that look about right?
I'd just use a hash attribute. All other things being equal, go for
simple and standard.
Does it look about standard? (especially the bit using the pipe operator)...
Thanks,
abhijit
Re: Classes with several, mostly unused, attributes
David Storrs writes: On Dec 15, 2004, at 6:11 PM, Abhijit Mahabal wrote: S01 says: # Perl 5 code is not strict by default, while Perl 6 code is. But it should be easy to relax with -e or maybe even a bare version number: this would suck. Badly. We should not be optimizing for the compiler's convenience, but for the programmer's. I find strictness _is_ for the programmer's benefit! I've had to work on some scripts which were originally written by people new to Perl who didn't know about strict (or warnings); I found I was making various sorts of errors (some embarrassingly simple) that I don't normally make, because I'm used to them being caught for me automatically. The compiler doesn't care whether you use strict or not -- it'll happily compile what you've written, even if there are logical errors in there! Although I can't prove it, I strongly suspect that the majority of times that someone sits down to do something with Perl, it's a quick one-liner or short script. Who knows? Perl is used in so many different ways there probably isn't a 'typical' user. And note that C-e is one of the things that disables strictness, so your concern about one-liners has been addressed. Strictness just gets in the way for those. A short script tends not to use many variables, so having to type Cmy a few times isn't much of a burden; nor will it be much effort to disable strictness. I think Larry's got this one right: somebody writing a short script who's getting strictness errors can get irritated by this, and therefore looking up how to disable it; whereas the current way round, a new Perl programmer writing a large script can mistype many variable names without it ever occurring to him that something like Cstrict exists and the situation could be avoided. Smylers
Re: Classes with several, mostly unused, attributes
On Dec 15, 2004, at 5:36 PM, Abhijit Mahabal wrote: I think that slackness-on-demand is a better policy than strictness-on-demand, but that, again, is just my opinion Until now, the policy in Perl has always been that it is as slack and forgiving as possible, and you have to ask if you want it to be strict with you. I hope that doesn't change. --Dks
Re: Classes with several, mostly unused, attributes
David Storrs wrote: On Dec 15, 2004, at 5:36 PM, Abhijit Mahabal wrote: I think that slackness-on-demand is a better policy than strictness-on-demand, but that, again, is just my opinion Until now, the policy in Perl has always been that it is as slack and forgiving as possible, and you have to ask if you want it to be strict with you. I hope that doesn't change. --Dks There should be little reason to complain so long as it is drop-dead easy to turn on slackness. S01 says: # Perl 5 code is not strict by default, while Perl 6 code is. But it should be easy to relax with -e or maybe even a bare version number: perl -e '$x = 1' #!/usr/bin/perl -e $x = 1; #!/usr/bin/perl v6; $x = 1; Of course, you can counter that with there should be little reason to complain so long as it is drop-dead easy to turn *strictness* on. But in either case, people are going to trip over this, expecting one(strictness/slacknesss) but getting the other. In one case (expecting slackness, but getting strictness from the compiler) it would be easier for the compiler to know that they have in fact tripped. --abhijit
Re: Classes with several, mostly unused, attributes
--- David Storrs [EMAIL PROTECTED] wrote: . . . . Obviously, however @Larry decide it should be, is the way it'll be and nothing I can say will change that. Au contraire -- that's what this list is for. State your opinion, man! :) That said: this would suck. Badly. We should not be optimizing for the compiler's convenience, but for the programmer's. I'm pretty sure that's the case so far. The @Larry are trying to do as much of the for as possible while minimally reducing the latter, though, and that's also good. Although I can't prove it, I strongly suspect that the majority of times that someone sits down to do something with Perl, it's a quick one-liner or short script. Strictness just gets in the way for those. (And, for the record; I make my living writing Perl, mostly large programs, and I always use strict in those programs. I want strict. I like strict. Strict is good. I just don't want strict by default.) For the record likewise, I also make my living writing perl scripts, and the huge preponderance of them fall into one of two major categories: 1) tools which use one or more of our in-house libraries such as modules to parse a particular file layout, or 2) little 5 or 10 line utility scripts that handle a frequently needed niche. (Or maybe that correct wierd behavior by reimplementing our strange version of head) That said, it's the strange and usually VERY old script that doesn't start with use strict; use warnings; In fact, one of those little utility scripts is explicitly for that: it opens a file and puts things like those pragma and a stamp for who started it when and when at the top. (Mostly it just edits itself into a new file. :) I for one (minority or not) would like strictures unless otherwise requested, though I think the last I heard was the right approach -- strict by default in modules and classes, but not in simple scripts. Doesn't that handle it? PH __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Classes with several, mostly unused, attributes
Paul Hodges writes: That said, it's the strange and usually VERY old script that doesn't start with use strict; use warnings; Moreover, it should be a clue to us that there's a shirt stating: #!/usr/bin/perl -w use strict; Hinting that this is the way you start a perl program. While I don't like strict all that much for my small programs, apparently a bunch of people do. But it's mainly a toss-up whether it's on or off by default. It's definitely off by default for -e scripts. It's definitely on by default for modules. But the main program could go either way. I'd actually like to see it on by default for the consistency (noticing that there are a few different ways of being consistent) that everything in a file has strict on. Larry has proposed a three-character no strict. I'm not sure there's really much to complain about. He's thinking in the right direction (how could we assume otherwise :-). And this particular issue has nothing to do with making things easy for the compiler. There are some things that are, like classes being closed at runtime unless asked otherwise. But note that you can still keep them open, so we're not taking away any rope, we're just making you ask for it. I doubt terseness is an issue when you're modifying classes at runtime. Luke
Re: Classes with several, mostly unused, attributes
On Dec 10, 2004, at 11:05 AM, Abhijit Mahabal wrote:
Consider a class (e.g., the hypothetical Geometry::Triangle) that can
have several attributes (side1, side2, side3, angle1, ang_bisector1,
side_bisector, altitude1 and so forth), most of which will not be
needed for most instances of Geometry::Triangle.
I know how this can be done in P5. Using the layout Hash things are
easy. How can P6 deal with this, without allocating too much memory to
things that'd never get used? The layout P6Hash could come to the
rescue, but there is still the issue of syntax:
what exactly does Chas $.bisector1 do? IIRC, in the P6Opaque layout,
every instance of the class would have space the size of a PMC
allocated for it. This behavior is not needed for P6Hash, and it
should just leave attributes alone until they are assigned to (where
defaults are also assigns).
In which case, maybe for that layout we can get away without declaring
all attributes, perhaps? (Since the declaration does nothing except
help the parser).
I was thinking whether we could do something like this:
class Triangle is layoutP6Hash does autovivify{
method calculate_bisectors { $.bisector1 = ...;
# $.bisector1 autovivifies
}
}
where it is an error without the autovivify, and only P6Hash supports
autovivification.
If it's an error without the autovivify and only P6Hash supports
autovivify, then isn't this redundant? Simply saying 'P6Hash' should
get me the autovivify behavior for free. (Incidentally that is 'should'
as in 'that is the way I think it would make sense for it to work in an
ideal universe' not 'should' as in 'based on the implementation, here
is the behavior I expect').
If, for some reason, I DON'T want that behavior, then I can pick
another layout or explicitly say 'does noautovivify'.
Incidentally, I just want to go on record as saying that the verbosity
of class declarations in P6 is really starting to skeeve me. I keep
reminding myself that these are the edge cases that are being
discussed, that you don't need all this stuff for the common case
(right?) that Perl 6 can be pretty much the same easy, succint, fun
language that I know and love, that sensible defaults will be chosen so
that in the common case the things I get automatically are the things I
wanted anyway. But, occasionally, I still find myself going
eeew...Java.
Re: Classes with several, mostly unused, attributes
David Storrs wrote: Incidentally, I just want to go on record as saying that the verbosity of class declarations in P6 is really starting to skeeve me. I keep reminding myself that these are the edge cases that are being discussed, that you don't need all this stuff for the common case (right?) that Perl 6 can be pretty much the same easy, succint, fun language that I know and love, that sensible defaults will be chosen so that in the common case the things I get automatically are the things I wanted anyway. But, occasionally, I still find myself going eeew...Java. I have been having the opposite feeling: I rather like the verboseness of class declarations, and their self documenting nature. It's not like java in that I have the freedom to be as specific or as vague as I want to be. I can say C has Cat %.foo is shape(Dog) if I want to, or Chas %.foo otherwise. Except for cases like the hypothetical Geometry::Triangle I can live with this, and maybe even in that case, because again it is probably a Good Idea. I don't know what happens when we have classes for which we do not know all the attributes ahead of time, but for that something like AUTOMETH would work. All this is subjective, of course, and I am fully with you that the possibility of being succinct should be open, to the extent that it is, er, possible. But there is a Pandora's box here: 1. When a class is composed, all the roles and the current class are meshed together; Clearly, if a role uses an attribute expecting it to be a particular type, it must explicitly say so (to avoid clashes with other roles or the class). Taciturnity, then, is open only to classes. 2. It will also be impossible to spot typos in argumentless method calls because that could be an undeclared attribute. (of the current class or any of its ancestors or roles) 3. If we use $.foo without declaring it, how would the compiler know if it is an object attribute or a class attribute? I think that slackness-on-demand is a better policy than strictness-on-demand, but that, again, is just my opinion --abhijit
Re: Classes with several, mostly unused, attributes
On Dec 15, 2004, at 6:11 PM, Abhijit Mahabal wrote: David Storrs wrote: On Dec 15, 2004, at 5:36 PM, Abhijit Mahabal wrote: I think that slackness-on-demand is a better policy than strictness-on-demand, but that, again, is just my opinion Until now, the policy in Perl has always been that it is as slack and forgiving as possible, and you have to ask if you want it to be strict with you. I hope that doesn't change. --Dks There should be little reason to complain so long as it is drop-dead easy to turn on slackness. S01 says: # Perl 5 code is not strict by default, while Perl 6 code is. But it should be easy to relax with -e or maybe even a bare version number: perl -e '$x = 1' #!/usr/bin/perl -e $x = 1; #!/usr/bin/perl v6; $x = 1; Of course, you can counter that with there should be little reason to complain so long as it is drop-dead easy to turn *strictness* on. But in either case, people are going to trip over this, expecting one(strictness/slacknesss) but getting the other. In one case (expecting slackness, but getting strictness from the compiler) it would be easier for the compiler to know that they have in fact tripped. --abhijit Obviously, however @Larry decide it should be, is the way it'll be and nothing I can say will change that. That said: this would suck. Badly. We should not be optimizing for the compiler's convenience, but for the programmer's. Although I can't prove it, I strongly suspect that the majority of times that someone sits down to do something with Perl, it's a quick one-liner or short script. Strictness just gets in the way for those. (And, for the record; I make my living writing Perl, mostly large programs, and I always use strict in those programs. I want strict. I like strict. Strict is good. I just don't want strict by default.) --Dks
Classes with several, mostly unused, attributes
Consider a class (e.g., the hypothetical Geometry::Triangle) that can
have several attributes (side1, side2, side3, angle1, ang_bisector1,
side_bisector, altitude1 and so forth), most of which will not be
needed for most instances of Geometry::Triangle.
I know how this can be done in P5. Using the layout Hash things are
easy. How can P6 deal with this, without allocating too much memory to
things that'd never get used? The layout P6Hash could come to the
rescue, but there is still the issue of syntax:
what exactly does Chas $.bisector1 do? IIRC, in the P6Opaque layout,
every instance of the class would have space the size of a PMC allocated
for it. This behavior is not needed for P6Hash, and it should just leave
attributes alone until they are assigned to (where defaults are also
assigns).
In which case, maybe for that layout we can get away without declaring
all attributes, perhaps? (Since the declaration does nothing except help
the parser).
I was thinking whether we could do something like this:
class Triangle is layoutP6Hash does autovivify{
method calculate_bisectors { $.bisector1 = ...;
# $.bisector1 autovivifies
}
}
where it is an error without the autovivify, and only P6Hash supports
autovivification.
--abhijit
