[PATCH] Iterator proof of concept
Leopold Toetsch
Subject: [RfC] Yet another iterator proposal.
Date: Mon, 10 Mar 2003 16:17:35 +0100
I (as well as our tireless summarizer) thought, the concept ought to be ok.
But a test says more then 1000 RfCs so here is a first step towards
implementation:
- only for arrays/integers currently
- only minimal aggregate semantics are implemented for the iterator
- 1 failing test, which is ok:
$ imcc t/pmc/pmc_70.pasm
Iterator init without aggregate
(init could be implemented, then e.g. C<assign PIter, Paggregate> for
attaching the aggregate to the iterator)
Comments welcome :-)
leo
PS playing with the patch needs "make realclean" as well as my latest
imcc commit from CVS.
Leopold Toetsch
> After the overwhelming amount of f'ups to my proposal:
Still :)
One more comment:
The iterator class is intended to pass almost every method on to the
aggregate, e.g.
> + PMC* getprop (STRING* key) {
> + return ((PMC *)SELF->data)->vtable->getprop(INTERP,
> + (PMC *)SELF->data, key);
> + }
I think, this is the same behavior as a reference. Hence the Iterator
class could inherit from a Ref class and just override iterator specific
functions.
Are there any thoughts about a Ref (or Reference) class?
leo
Leopold Toetsch
> Leopold Toetsch wrote:
>> + PMC* getprop (STRING* key) {
>> + return ((PMC *)SELF->data)->vtable->getprop(INTERP,
>> + (PMC *)SELF->data, key);
>> + }
> I think, this is the same behavior as a reference. Hence the Iterator
> class could inherit from a Ref class and just override iterator specific
> functions.
> Are there any thoughts about a Ref (or Reference) class?
I really hate code duplication, so ...
Summary: The Iterator behaves like the aggregate it is attached to. All
the get_<type> methods would just delegate the method to the ->data
member as shown above for the C<getprop> method.
Is this the same as the functionality of a Reference class?
Thanks for answering,
leo