David Green writes:
> On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
> >So all the laziness goes into the array implementation.  But you don't
> >even need to write your iterator fancily.  If you just write your scalar
> >version of postcircumfix:<>, Perl will do the rest.
> 
> So if you use an iterator in list context, Perl will automatically call it 
> repeatedly for you?
> That still means Perl has to know when something is an iterator, which is 
> fine for <> (or whatever it ends up being called), but when your object 
> has different ways to iterate (e.g. .keys, .values, .kv), they'd have to 
> be defined as "is iterator" or some such.  

Since operators are going to be less DWIMmy this time around, I suppose
I should have said "Perl does the rest if your class does iterator".  So
the iterator role would define the listy version for you.

> >    method postcircumfix:<> ($self: *%opt) returns List {
> >        scalar $self.<*%opt>, $self.<*%opt>  # [1]
> >    }
> >If I write it functionally like that, Perl will still do all the rest.
> >Laziness is built right in the language.
> 
> Ah, nice!  But doesn't the scalar definition need to be part of the method 
> too?  
> 
>     method postcircumfix:<> ($self: *%opt) returns Scalar|List  #??
>     {
>         given want
>         {
>             when Scalar { get_next_value, increment_counter, etc; }
>             when List { return scalar $self.<*%opt>, list $self.<*%opt>; }
>             # hm, what about void context?  
>             # (should probably iterate once, like scalar context)
>         }
>     }
> 
> Or can you define separate methods for scalar and list contexts, and have 
> Perl call whichever one is appropriate?  (Which would be neat... 
> polymorphism from the other end.)

That was the idea, but I realize that I did it wrong.  I also realize
that there isn't a right way yet.  Dispatching on return value is
something that is pretty hard to implement, and impossible to implement
correctly, as it has a tendency to create paradoxes.

So for now I'd say that you have to put them both in the same method.
Which seems to imply that the iterator role would look for a method name
to use for scalar context.  Like sip :-)

Luke

Reply via email to