[Rd] Re : ReferenceClasses examples {method}

[Marc Carpentier]

Hi,
Thank you for this pedagocical response. Obviously, I hadn't consider the 
$edit() call from $undo() itself...

Which made me think of a more vicious (!) example... with the possibility to 
undo what's been undone...
Viciousness isn't the point, so in this modified example :
- edits is used as an history list of 'edit actions' (i, j, oldvalue AND 
newvalue)
- a new field is used to point current position in this history list (coerced as 
integer)
- this is the opportunity to demonstrate a very simple initialize() method to 
set editspointer to 0 (because of the first call of edit() and 'length(edits) 
<<- editspointer')
- a default argument is used for the edit() method, to consider specific calls 
by undo() or unundo()
- controls and stops are maintained...
It seems to run correctly... I don't know if it's worth to share ; please use it 
freely.

Marc



----- Message d'origine ----
De : John Chambers <jmc at r-project.org>
À : Marc Carpentier <marc.carpentier at ymail.com>
Cc : r-devel at r-project.org
Envoyé le : Sam 29 janvier 2011, 0h 09min 36s
Objet : Re: ReferenceClasses examples {method}

Hi Marc,

Sort of one out of two, but very helpful.

On 1/28/11 11:01 AM, Marc Carpentier wrote:
> Dear r-devel-list, dear John Chambers,
> 
> I'm trying to learn OOP-possibilities in R and I was going through the
> documentation 'ReferenceClasses {methods}' (great work, by the way...).
> Reading associated Examples, something bothers me : it seems to me that there
> are errors in 'edit' and 'undo' methods. I think that :
> - 'undo' should update 'edits' field with :
> length(edits)<<- length(edits) - 1 #(and not - 2)

Nope.  There are actually two logical choices here, but that is not either of 
them.

Notice that the line before that is:
  edit(prev[[1]], prev[[2]], prev[[3]])
which invokes the $edit() method to effect the undo, _and_ which adds that edit 
to the $edits list.

One could just leave things that way, but we decide to hide our undo from 
Wikileaks by removing both the edits.

> - and for coherence, 'edit' should store modifications in an 'append'-style :
> edits<<- c(edits,list(backup)) #as opposed to c(list(backup),edits)

Well, that's a bit debatable, but it does expose a bug, for sure.  The current 
order might be acceptable, but $undo() is then removing the wrong end of the 
$edits list, as would have been obvious if the example had done two edits and 
then removed one.  In the current version the first backup is the most recent 
edit (and indeed is used to reset the data), but then the wrong elements of 
$edits are removed.

Given that, I agree that the opposite order of keeping the backup list is 
better.  Less copying, for one thing.

Attached is a corrected and slightly expanded version of that part of the 
example.  Anyone is encouraged to try it out; if no further problems arise, I'll 
commit its essentials.

> 
> I hope I'm not wrong and this hasn't been previously reported (I didn't find
> anything about it)
> Best regards.
> 
> PS: I first posted this message on help-list. David Winsemius suggested  me
> devel-list would probably be more appropriate and was right about that. Sorry 
>if
> you read it  again.

And indeed r-devel was the right place.  Thanks

John

> PPS: please associate my address when responding because I didn't subscribe to
> r-devel-list (I'm still far from being able to follow all its discussions...)
> 
> 
> 
> 
>