[Dev] Simplifying biref definition and kind extensions

[Phillip J. Eby]

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.  ;)