It makes sense when you can't predict in advance what metadata people will
want to store. I wrestled a lot at the beginning with trying to come up with
"universal names," but somehow it seemed that a field named "patient_ID" is
unlikely to be of interest to astronomers :-). (Or me, for that matter.)
The thing about image processing is that it rarely suffers from a bottleneck in
handling the metadata; all you really need is fast access to the pixels. So
this is a fairly specific solution for Images. Like you, I use types with
fields
in most other cases.
--Tim
On Monday, August 31, 2015 08:44:45 AM Cedric St-Jean wrote:
> Hi Tim, thanks for the answer. I wasn't talking about Image specifically,
> but that's an interesting way to flexibly store all the memos. Is that your
> general go-to solution, have a properties dictionary inside each object? It
> feels more like a Python solution than Julia, but it makes a lot of sense
> for medium-to-large objects.
>
> On Monday, August 31, 2015 at 4:34:38 AM UTC-4, Tim Holy wrote:
> > Re Image (assuming you mean the Image from Images.jl), you can just add a
> > "hash" property---no recreation/redesign needed. Wouldn't necessarily have
> > to
> > be a nullable, either. For efficiency, Images implements a `@get` macro,
> > so
> >
> > @get img "hash" hashfunc(img)
> >
> > would:
> > - extract the stored "hash" property, if it already exists, without
> > computing
> > hashfunc(img)
> > - compute and create the "hash" property, if it doesn't exist
> >
> > --Tim
> >
> > On Sunday, August 30, 2015 10:04:26 PM Cedric St-Jean wrote:
> > > I tend to use memoization heavily in my mostly-functional code.
> >
> > Memoize.jl
> >
> > > is neat, but it doesn't use a WeakKeyDict.
> > >
> > > 1. Is there any specific reason for that? Won't that code just hog the
> > > objects forever?
> > >
> > > 2. In SBCL, weak dictionaries and weak references had terrible O(N²)
> > > performance (I could never understand why), is that also the case for
> >
> > Julia?
> >
> > > 3. In many cases, it makes more sense to store the memoized value inside
> > > the object's field (for instance, storing the hash for an image). That
> >
> > will
> >
> > > be a good place to use Nullable, right?
> > >
> > > # Obviously I don't mean to recreate Image specifically
> > > type Image
> > >
> > > ...
> > > hash_value::Nullable{int}
> > >
> > > end
> > >
> > > function hash(img::Image)
> > >
> > > if isnull(img.hash_value)
> > >
> > > return img.hash_value = ...
> > >
> > > else
> > >
> > > return get(img.hash_value)
> > >
> > > end
> > >
> > > end
> > >
> > > 4. I still don't have the hang of Julia macros. In Common Lisp, I could
> > > easily write my own
> > > (defstruct* Image
> > >
> > > ... normal fields
> > > (cache hash))
> > >
> > > and have the above code automatically generated. What's the best syntax
> >
> > to
> >
> > > use with Julia? Something like
> > > @type_cached Image begin
> > >
> > > ...
> > > cache(hash)
> > >
> > > end
> > >
> > > function hash_impl(img::Imaeg)
> > >
> > > ...
> > >
> > > end
> > > ? I don't like much how the `begin` makes it stick out, whereas Common
> > > Lisp's version is much more seamless. Isn't there a way to tell the
> >
> > parser
> >
> > > "keep reading this macro until `end`" without having a begin statement?
> > >
> > > Is there a better, more native solution to this problem?
> > >
> > > Cédric
