Re: Fw: perl6 operator precedence table
Larry Wall wrote: [...] Maybe we should ... to mean and so on forever: a[0...; 0...:10; 0...:100] Except then we couldn't use it to mean what Ruby means by it, which might be handier in real life. No more yada-yada-yada? Brad
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
One first thing I notice while I'm supposed to be doing homework. :-) Wasn't class MyClass; supposed to work along the line of Perl5's package MyClass; and make everything following that statement the definition of MyClass?
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
Hi,
Many thanks Michael, this is very useful, really. I had lost all the
OO discussion and this document is very helpful.
I really like the part of context transformations, I hope something
like this gets in.
Just a silly note:
Recipe 1.9: Using Subroutines as Objects
Problem:
You want to use a subroutine as if it were an object.
Solution:
Just do it:
sub mysub { ... };
my $var = mysub.foo;
I think it was said that the way to avoid the ambiguity here is to add
to sub name.
For example:
my $var = msyub.foo; # call foo method on mysub object
my $var2 = mysub.foo; # equivalent to mysub().foo()
Best,
-angel
Delegation syntax
Problem:
You want to use delegation (rather than inheritance)
to add some capabilities of one class or object to
another class or object.
Solution:
Use a PROXY block:
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
when 'steer' { $left_front_wheel, $right_front_wheel }
}
...
}
Discussion:
The PROXY block behaves as if the following were
true. The block has a topic. The topic is an object
that represents a method call. This object stringifies
to the name of the method called. The block is called
each time a method call is invoked on the enclosing
class, or an instance of the class. The whens' blocks
are a list of things that are proxies for (ie delegatees
of) the matched call.
Roughly speaking, my idea is to do Damian's Delegation
class dressed using new clothes that look like ones from
the Apos that have come out since he wrote the module
at http://tinyurl.com/1qsk. A longer example follows.
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
attr $left_rear_wheel is Wheel;
attr $right_rear_wheel is Wheel;
attr FlyWheel $flywheel .= new;
attr MP3::Player $mp3 .= new;
when 'steer'{ $left_front_wheel, $right_front_wheel }
when 'drive'{ 'rotate_clockwise' = $left_rear_wheel,
'rotate_anticlockwise' = $right_rear_wheel }
when 'power'{ 'brake' = $flywheel }
when 'brake'{ / .*_wheel / }
when 'halt' { 'brake' = SELF }
when /^MP_(.+)/ { sub { $1 } = $mp3 }
when 'debug'{ 'dump' = ATTRS }
}
...
}
or something like this.
--
ralph
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
On Wednesday, October 9, 2002, at 07:54 PM, Chris Dutton wrote:
One first thing I notice while I'm supposed to be doing homework. :-)
Wasn't class MyClass; supposed to work along the line of Perl5's
package MyClass; and make everything following that statement the
definition of MyClass?
Yeah, I think so too, but don't know for sure. The class MyClass
would mirror sub declarations, allowing you to make anonymous
classes, assign properties to classes, etc. The package-style class
MyClass; would work, um, just like packages.
One reason I can think of to choose the first instead of the second
would be if you wanted properties (or parent classes!) to be able to
alter the grammar of an individual class, which would be a neat way to
tack different OO zealotry onto a class without enforcing it on others:
class MyClass is wackyGrammar {
...
}
vs.
{
class MyClass;
...
use wackyGrammar;
}
there would be a minor problem because you've already entered the
grammar of a class by the time you get to the 'use' . (A hybrid
approach, a packagelike class MyClass is wackyGrammar; would also
work, tho.)
In theory, *both* could be made to work with little effort. I think it
depends on how much we want to treat classes like packages, vs. classes
like objects. I arbitrarily chose to put the non-package example in
because it was more likely to provoke counterexamples. ;-)
MikeL
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
On Thursday, October 10, 2002, at 02:33 AM, Angel Faus wrote: Just a silly note: Recipe 1.9: Using Subroutines as Objects I think it was said that the way to avoid the ambiguity here is to add to sub name. Thanks, applied. MikeL
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
On Wed, 9 Oct 2002, Michael Lazzaro wrote: PLEASE contribute to this document! Email me with suggestions, yes or no votes on recipe approaches, info on philosophies or best-guess syntax, etc., or discuss them here on perl6-language. Very nice. I hope this evolves into a useful perl6 reference. Here are some comments on section 1. Recipe 1.6 my $obj = MyClass.new(...); # synonymous, if ... is empty Yes. my $obj = MyClass(...); This seems to assume that objects have a default method if you treat them like a subroutine. Kinda tcl-ish, but I don't recall anything like this in the apocalypes. my $obj = MyClass; I think $obj would contain a reference to MyClass, not an instance of MyClass. my $obj is MyClass; # similar to above, but autovivifying? This declares $obj as a MyClass, but does not instantiate it. If I recall the discussion on this subject, the preferred syntax was my $obj is Myclass .= new(...); Notice that you still have to explicitly invoke the new method. The is MyClass merely prevents you from assigning a non-MyClass value to $obj. The difference between my $i is int = 3 and my $obj is MyClass = MyClass.new is that 3 is already an instance of int. MyClass does not have a textual representation which the compiler will recognize unless you perform some source filtering/lexical rules tricks. The theory about being autovivified according to the default constructor is nice, but I think it is not true. If you do not explicitly assign a value to a variable (number, string, or object), it gets a value of undef. Autovivification refers to the automatic creation of the *variable*, not the value. If you use a variable before declaring it, the variable is created with a value of undef. Similarly, if you use a hash or array item which does not exist, it is autovivified with a value of undef. Recipe 1.10 1.11 Issue: Or can you? In perl5, class methods are the same as instance methods. The difference is that they receive a class reference as $self instead of an object instance. (perl5 class references happen to be strings, but we won't hold perl6 to that.) So it is not yet known whether class methods in perl6 will have any greater distinction from instance methods than that. Recipe 1.15 I think the thought here was to use the binding operator. my ClassAlias := MyClass; ~ John Williams
Re: Interface lists (was Re: Interfaces)
On Mon, 30 Sep 2002, Michael G Schwern wrote:
: On Tue, Oct 01, 2002 at 01:36:19AM +0100, Simon Cozens wrote:
: [EMAIL PROTECTED] (Michael G Schwern) writes:
: method _do_internal_init ($num) is private {
:
: Just thinking aloud, would
: sub foo is method is private is integer is fungible {
:
: be better written as
: sub foo is fungible private integer method {
:
: or not?
It's potentially ambiguous. Here's a bad example, but there are probably
better ones:
my $foo is rw cmp ;
Plus we have to worry about arguments to properties, if we allow
anything other than (). I'd personally like to see some properties
that can take a closure as their argument, but the parser would have
to know that in advance or the method property above would slurp
up the subroutine block by accident. Or the sub block itself needs
a keyword.
: How about seperated by commas, like any other list?
:
: method foo is fungible, private, integer {
Is ambiguous:
my ($foo is foo, bar, $bar is baz) = (1,2);
Also, precedence of comma with respect to assignment causes problems.
We may be able to relax this later somehow, but for now we're saying
that is...is...is... isn't all that onerous.
To which the only correct reply is, but...but...but... :-)
Larry
Re: Interfaces
On Mon, 7 Oct 2002, chromatic wrote: : On Wed, 02 Oct 2002 04:12:44 -0700, Michael G Schwern wrote: : : I like the class Vehicle is interface as a shorthand for declaring every : method of a class to be an interface. : : Perhaps associating a property with a class can be shorthand for associating : that property with every method of the class? Not in general, since the class needs to be able to have properties apart from from its methods, such as its parent classes. But a particular property such as interface could certainly be set up to be distributive over the methods or attributes. Larry
Re: Interfaces
On Mon, 7 Oct 2002, Andy Wardley wrote: : Nicholas Clark wrote: : I think that the first syntax : : class Car::Q is Car renames(eject = ejector_seat) : is CD_Player renames(drive = cd_drive); : : makes it more clear that I'd like to pick and choose which methods : the composite object gets from which parent. : : But now you've turned composition back into inheritance, and I think it's : important to be able to distinguish between the two. : : The car is definately not a CD player, it just has one. : : I think we need a more flexible syntax for specifying how interfaces : should be constructed in the case of composed objects, rather than : turning composition into inheritance to avoid the problem. Yes, that's important. If you've got a CD_Player *object*, it doesn't do anyone any good to pretend it's a car *object*. We too often lose sight of the fact that objects should behave like objects. That's what OO really means, after all. OO isn't about inheritance Anyway, I don't see offhand why composition can't simply be done with attributes as it is in C++, especially since attributes manifest as methods outside the class. I don't think $car.cd.eject() is all that horrible to contemplate. Larry
Object Instantiation (Was: Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1)
On Thursday, October 10, 2002, at 11:23 AM, John Williams wrote: my $obj = MyClass(...); This seems to assume that objects have a default method if you treat them like a subroutine. Kinda tcl-ish, but I don't recall anything like this in the apocalypes. my $obj = MyClass; I think $obj would contain a reference to MyClass, not an instance of MyClass. This is an area that's been bothering me for a while now (the Apoc's so far don't directly address it, AFAIK.) Here's why: Instantiating new objects is *darn* frequent in OO programming. And of those objects, a sizable number -- possibly even a majority -- have constructors with no required arguments, e.g. default constructors. And pretty much every one of those constructors is going to be named .new. Therefore, since creating an object using a default constructor is really common, it should be drop-dead simple. I think there's utility in trying to accommodate: $obj = MyClass.new(...);# normal case $obj = MyClass.new; # if the constructor takes no args $obj = MyClass(...) # implied new w/ args $obj = MyClass; # implied new, no args Since instantiating a class is MUCH more common than is passing classes themselves around, the latter case could be expanded instead: $obj = MyClass; # instantiate it, using the default constructor $obj = MyClass.TYPE;# assign a reference to MyClass $obj = 'MyClass'; # ... or just treat it as a string? trading less code in the very common case for more code in the not-as-common case. (It would make other things simpler, too, e.g. transformations.) So tho I have no say in the decision, I'm REALLY hoping that we can leave out the new(). (The idea of being able to drop the new() was stolen from languages in which the name of the constructor is the same as the name of the class, there is no new() at all.) As far as the syntax for type declarations: I have less bees about this one. Clearly, my $obj is MyClass; should declare a variable of type MyClass. (You're right, it shouldn't autoviv.) So what's the simplest syntax for typing + instantiation, together? Dunno, maybe my $obj is MyClass .= new; is it, but still I'm hoping for an alternative that is easier to explain to people when I'm training them. Hmm, think, think... MikeL
Re: remote generators and a macro language proposal
On Thu, 10 Oct 2002, Chip Salzenberg wrote:
: According to Luke Palmer:
: for ( grep { $_{smoker} and $_{age} 18 } Subscribers ) {
: .send($Cigarette_Advertisement)
: }
:
: Hm, would this work too:
:
: for ( grep { .{smoker} and .{age} 18 } Subscribers )
: { .send($ciggie_ad) }
:
: ? I think .{x} reads better than $_{x} , esp. in parallel with the
: method call in the same loop.
Didn't see the original, but if those are attributes, why wouldn't
it just be:
for grep { .smoker and .age 18 } Subscribers {
.send($ciggie_ad)
}
'Course, this might be more readable:
for Subscribers {
.send($ciggie_ad) if .smoker and .age 18;
}
Most smokers don't know what grep means, after all...
Larry
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
On Wed, 9 Oct 2002, Chris Dutton wrote:
: Wasn't class MyClass; supposed to work along the line of Perl5's
: package MyClass; and make everything following that statement the
: definition of MyClass?
Yes, though we're thinking of limiting that construct to the front
of a file, along with module MyModule;. That is, we discourage
people from writing
{
class MyClass;
...
}
when they mean
class MyClass {
...
}
Larry
Re: Delegation syntax
: Problem:
:
: You want to use delegation rather than inheritance to
: add some capabilities of one class or object to
: another class or object.
:
: Solution:
:
: Use a PROXY block:
:
: class MyClass {
:
: PROXY {
: attr $left_front_wheel is Wheel;
: attr $right_front_wheel is Wheel;
:
: when 'steer'{ $left_front_wheel, $right_front_wheel }
: }
: ...
: }
I think this is falling into the use overload gobbledygook trap.
If something is part of the method interface, it ought to be declared
as a method. It's the *implementation* syntax that should be screwed
around with to do delegation. Something like:
method steer is really(Wheel) is also(???) { .profit!!! }
I guess now we need C??? and C!!! tokens now to go with C
:::---)))
Larry
