> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > ------- Additional Comments From [EMAIL PROTECTED] 2004-01-10
Glen / Finn, Hope you don't mind my interrupting here: Particularly this point I found interesting: > 3.) PropertySets.java defines those properties which are valid > for each FO--in PropertyList, the proposed implementation then uses that > information to limit the properties that can be assigned to an FObj > (i.e., only those defined as valid for it.) Am I correct here on this point? > > If so, we may need to expand the "valid" properties to include > the inheritable ones. > <snip /> > Do we need to expand then the property sets for each FO to include the > inheritable properties (you may already have done so, I'm not sure if those > were included)--and do we also need to somehow additionally qualify *those* > properties as "valid for the FO but not directly relevant for it"? (I > think "yes" for the first question, "no" for the second.) IIC the initial strategy WRT inherited properties was to add methods to the FObj's to get these from their parent. I think the problem with this implementation is that, in the case of very large documents with deeply nested elements that inherit a property which is specified at the top-level, you would end up with one getter being dispatched to the parent's getter, and this in its turn being dispatched to yet another ancestor's getter (or Makers in case of Property creation)... In this case, however, I think you can't fully 'push' these onto the descendants, as this would lead to absurd storage-reqs for quite average-sized documents. OTOH, the inherited property value (resolved or unresolved) can indeed be supposed as available at parse time, because a parent is per se processed *before* any of its children. I just wonder if this has something to do with Finn's other idea of moving logic to the property side to save on unnecessary calls to empty methods ? > 4.) Finally, I'm too far removed from my C programming days to understand the > math here: > this.specified = new int[(indices[0] >> 5) + 1]; He's dividing the value by 32 [or 2^5], right? > (where indices[0] defines the number of properties valid for the FObj) > also, in putSpecified(int idx, Property value), you code this: > specified[i >> 5] |= 1 << (i & 31); > I'm not clear what this is doing either. What does putSpecified() do, and > what's the point of the i & 31 and the Or'ing? I *definitely* *have* *to* take a closer look at that code! I *definitely* *have* *to* take a closer look at that code! I *definitely* *have* *to* take a closer look at that code! ... That's all I can add for you now, Glen. Sorry :( Cheers, Andreas
