On 10/15/07, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
> [As agreed, CC:ing r-devel since others might be interested in this as well.]
>
> Hi.
>
> On 10/15/07, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
> >
> > Hi Hadley,
> >
> > On 15 October 2007 at 09:51, hadley wickham wrote:
> > | Would you consider making digest a generic function? That way I could
> > | (e.g.) make a generic method for ggplot objects which didn't depend
> > | (so much) on their internal representation.
> >
> > Well, generally speaking, I always take patches :)
>
> I see know problems in doing this. The patch would be:
>
> digest <- function(...) UseMethod("digest");
> digest.default <- <current digest function>.
>
> I think that should do, and I don't think it has any surprising side
> effects so it could be added in the next release. Dirk, can you do
> that?
>
> >
> > I have to admit that I am fairly weak on these aspects of the S language.
> > One question is: how to the current users of digest (i.e. Henrik's and
> > Seth's caching mechanism, for example) use it on arbitrary objects _without_
> > it being generic?
>
> I basically put everything I want into a list() and pass that to
> digest::digest().
Yes, that's what I'm doing too.
> >
> > | The reason I ask is that I'm using digest as a way of coming up with a
> > | unique file name for each example graphic. I want to be able to
> > | easily compare the appearance of examples between versions, but
> > | currently the digest depends on internal details, so it's hard to
> > | match up graphics between versions.
>
> See loadCache(key) and saveCache(object, key) in R.cache, which
> basically loads and saves results from and to a file cache based on a
> key object - no need to specify paths or filenames. You can specify
> paths etc if you want to, but by default it is just transparent.
The problem is I need to refer to the image from the documentation, so
I do need to know it's path. I also want to be able to look at the
image, so if the digests are different I can see what the difference
is (I'm planning to automate this with the imagemagick compare command
line tool).
> However, I think Hadley is referring to a different problem.
> Basically, he got an object containing a lot of fields, but for his
> purposes it is only a subset of the fields that he wants to use to
> generate a consistent the hashcode. If he pass any other field, that
Yes, exactly.
> will break the consistency. In that case, the designer of the class
> has to identify the fields that makes uniquely identify the state of
> the object. I do that for many of my object and pass them down in a
> list() structure to digest(). I agree, by making digest() generic,
> one can make the code nicer. [If there is a need to dispatch on
> multiple arguments, we have to go for S4, but otherwise S3 gives the
> minimal modification].
>
> Side comment: This basically comes down to how for instance Java deals
> with hashCode() and equals() etc. By default the object as is used to
> generate the hashcode (and can be used by equals() compare objects).
Yes, that's the model I was thinking of too.
Hadley
--
http://had.co.nz/
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
