At 12:32 PM 9/9/2005 -0700, John Anderson wrote:
Phillip J. Eby wrote:
Right now, however, if you define a biref with the schema API, you have
to do half of it in A, and half in B. This is fundamentally broken
because it means you can't have *any* modularity and still relate things
in different parcels. So, we need a way to define both sides of a biref
from only one place.
Can you avoid this problem with global attributes like we had in parcel
xml? A has a reference to a global attribute foo. the foo attribute is
also in A(or some global location). B uses the global attribute foo and
references it in A. Therefore B depends on A but A doesn't depend on B. It
does, however, require that some modulue use the global attribute foo, but
it doesn't have to be B. I think I used this in parcel xml to avoid
circular dependencies.
You're describing something that isn't a problem to begin with. If parcel
A were exporting such an attribute, it would be because parcel A *knows* it
has clients that are extending it in that particular way. The issue here
is for things that parcel A *doesn't* know about, so it can't possibly
export an attribute for them. In all of the examples I gave there is no
way for parcel A to know it even needs to provide such an attribute, let
alone what characteristics it should have. For example, the calendar
parcel has no way to know it should export an attribute for the sharing
parcel to use to track something that has to do with sharing.
(The implementation of my proposal would in fact use global attributes,
though; it's just that they're automatically generated and managed.)
You just don't have to give it a name, or add it to the class by
hand. The name this attribute will be automatically given is
"osaf.sharing.UIDMap.items.inverse", which of course cannot collide with
any of the calendar-specific attributes defined by the calendar
parcel. It does mean that it's more awkward to access that attribute, if
you really need to access it for some reason, because you have to use
getattr(ob,name) or ob.getAttributeValue(name) (where 'name' is
"osaf.sharing.UIDMap.items.inverse"). You can't just say 'ob.name' the
way you can with attributes that are created explicitly.
Personally, I'd prefer if we mangled the attribute name so it could be
looked up with ob.mangledName. A simple possibily would be
osaf_sharing_UIDMap_items_inverse_, but maybe we could think of a nicer
mangle. I think awkwardness of access is worse than the risk of name collision.
That's what the annotation API is for; it allows you to access names
without any mangling at all, so this is much less awkward than typing out
mangled names. Also, one very useful side benefit of the dotted syntax is
that is actually an address that helps you find the attribute's
definition. In fact, you can use 'schema.importString(name)' in order to
retrieve the original object that defined that attribute. Mangled names
however have to be mangled and un-mangled by a human in order to use them,
which is considerably more awkward than e.g. 'SidebarInfo(foo).color'. In
any case, for the specific example above it's entirely moot, because the
other end of the bidirectional reference is never used; the attribute could
be named "PPTU$OU%$#)%&#$%(&#$&%" for all that Morgen cares. ;)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
