A Friday 18 December 2009 15:02:58 Ted Horst escrigué:
> On 2009-12-18, at 05:28, Francesc Alted wrote:
> > A Friday 18 December 2009 11:54:49 Maarten Sneep escrigué:
> >> On 18 dec 2009, at 11:43, Francesc Alted wrote:
> >>> Hi List,
> >>>
> >>> I'm about to merge the links branch into trunk, but suddenly it
> >>> occurred
> >>> to me a new idea on how to dereferring soft/external links.
> >>> Currently,
> >>> these links work like this:
> >>>
> >>> f = tb.openFile('links.h5', 'w')
> >>> g = f.createGroup('/', 'g')
> >>> a1 = f.createCArray(g, 'a', tb.Int64Atom(), shape=(10000,))
> >>> la = f.createSoftLink('/', 'la', '/g/a') # /la points to /g/a
> >>>
> >>> and dereferring la is implemented via the `__call__()` method:
> >>>
> >>> a2 = la() # a2 is the 'a' CArray
> >>>
> >>> But I think now that perhaps it would be better to implement
> >>> dereferencing via a property (say `target`):
> >>>
> >>> a2 = la.target # a2 is the 'a' CArray
> >>>
> >>> That would allow to natural naming to work even through links
> >>> referring
> >>> to groups. For example, if lg
> >>>
> >>> lg = f.createSoftLink('/', 'lg', '/g') # /lg points to /g
> >>>
> >>> then we could do:
> >>>
> >>> a3 = f.root.lg.target.a # a3 is the 'a' CArray
> >>>
> >>> which I think is consistent with the way that PyTables uses to
> >>> access
> >>> nodes. What people think?
> >>
> >> Hi,
> >>
> >> Do it in a way that doesn't require me to know if it is a link or
> >> not,
> >> group or otherwise. Of course when writing you will know, but not
> >> when
> >> using. I think that means I prefer the first method.
> >
> > Thanks for your feedback Maarten.
> >
> > Hard links already implement your suggested way that doesn't require
> > to know
> > if it is a link or not (in fact, hard links are just meant for
> > providing
> > different paths to the same node). However, soft and external links
> > *do* need
> > to have a different personality than the nodes they point to. This
> > is because
> > you need to know that, say, '/path/to/node' is a link or not in
> > order to know
> > the different instance variable or methods that you can use.
> >
> >> In addition you can add a property to manipulate the link itself,
> >> but not
> >> for normal use of the data.
> >
> > Unfortunately, I think I cannot go the property venue. In the
> > middle of the
> > property implementation I realized that an external link needs a way
> > to pass
> > parameters to the dereferring method. For example, if:
> >
> > la = f.createExternalLink('/', 'lg', 'externalfile.h5:/g')
> >
> > then we can derefer the link is several ways:
> >
> > la() # open external file in 'r'ead-only mode (default)
> > la('a') # open external file in 'a'ppend mode
> > la(METADATA_CACHE_SIZE=2**24) # open external file with specific
> > param
> >
> > And as it would be desirable to have the same interface for soft and
> > external
> > links, then I think I'll stick with the special `__call__` method
> > for the
> > moment.
>
> If __call__ means 'open', then wouldn't it be clearer (more explicit)
> to just have a method named open?
No, it doesn't mean 'open', but rather 'dereference'. Be in mind that such a
'dereference' method should be valid for both soft links and external links.
However, I prefer to make soft and external instances callables (so that
`link()` is enough) instead of forcing people to use a longer method name
(like `link.dereference()`).
--
Francesc Alted
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Pytables-users mailing list
Pytables-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pytables-users
