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
