> -----Original Message----- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > <snip /> > One thing I'm missing here, for Finn's design below: > > values[0] = null // always null. > values[1] = reference to a 'foo' Property instance > values[2] = reference to a 'baz' Property instance > > Can't we just have, say, values[1] refer to the > parent's Property instance in cases where inheritance > is applicable? > > I.e., for all those references to the 'foo' property > instance for the children of an FO where that value > would be inherited, we don't have to create a new > Property instance, just a reference to the inherited > instance. >
That sounds indeed very much like the sort of thing I'm referring to, expressed with more profound background knowledge, so more to the point. > [Me: ] > > The difference would be that, instead of n > > Property objects, each with > > its own FObj, you would end up with one larger > > Property object --larger, > > because it has to store references of all FObj's to > > which it applies - that > > is in some way shared by n FObj's. > > > [Glen: ] > I think this could be done more simply by the above, > just have values[1] refer to the property of the > parent instead. > Agreed. What I'm very concerned about, for example, are cases like tables, where it would be quite awkward to have the TableCell FObj's reference their own copy of a Property instance --thus increasing their size in memory - while there would be a way to get the value (resolved/unresolved) of the ancestor in question, directly without any recursion, given the necessary adjustments. IIC the TableRow FObj's Property instances will always be available as long as any Cells are being processed. Same goes for the Table and the Columns while any Rows are processed. I admit, this is a quite different form of inheritance, but it serves as an illustration. (Thinking of my recent colspan excursions here: does every cell really need its own colspan variable where you could simply retrieve it from the column (if specified)? This also has me doubting about simply ignoring implicit columns at LM creation stage, like the proposed (and recently applied) patch 25809 does. The corresponding FObj would simply not exist. If it did, a LM would automatically be instantiated for it. I'm thinking of creating 'a' (at least one) column in the FOTree, but I'll discuss this in another thread... ) > But if the problem is the *recursion* necessary to > determine the property instance to inherit--here, not > the memory problem, but processing speed--I'm thinking > of a PropertyWindow instance as follows: > My concern, I believe, is both. Take, for instance, the font-size property. I would consider it to be best practice in XSL-FO to specify the value that will be used the most throughout the rest of the document on the fo:flow, and use specified values to override this value only where it is absolutely necessary to do so. This, to me, means that when it comes to processing, there has to be an advantage to adhere to such practices, WRT memory consumption as well as WRT speed. I mean: if it takes only a little more time to process at FOTree building stage, it might be worth it if you can avoid a lot of recursive calls later on in the process. So... > A PropertyWindow would be used temporarily during FObj > property initialization to hold references to all the > property instances that would be relevant for that > FObj should a property not be explicitly defined. > > So, to populate the property instances for a > particular FObj, i.e., the "values" array: > > 1.) read any incoming attributes and make properties > out of them. > > 2.) for any properties undefined, access the > PropertyWindow to determine the property instances to > use for them. No recursion needed now. > Sounds good, and while we're at it, could we test for equal specified values on any ancestors in step 1, so we can use the advantages of inheritance to the max...? We don't really want to *punish* users who feel like specifying 'font-size="12pt"' on 80K different FObj's that are descendants of the fo:flow, I think. In the proposed case, IMHO, there should be only one Property instance for 'font-size="12pt"'. Is this a correct view? Or is this outright impossible for some reason I'm missing? > 3.) if the FObj has any child objects, create a new > (temporary) PropertyWindow for their > processing, based on the FObj's (parent) > PropertyWindow and the value of its own Properties. > This temporary PropertyWindow can be dropped once the > children's FObjs have been processed. So the number > of open PropertyWindow instances during processing > would just be equal to the depth of the tree at the > current point of processing. > > (What I'm describing above is may very well be a > common design pattern, I don't know its name, > however.) > Me neither... If it turns out not to be one, we could call it the 'Mazza-Window' :) > OTOH, for any XSL functions which request, "run-time", > to use different Property values than that obtained by > simple inheritance--we can't rely on the above. These > functions are relatively infrequently used, and IMO do > not need to be as optimized as normal inheritance > would be--i.e., we still have to support them, but we > shouldn't be altering the speed of the base processing > in order to optimize for *these* functions--recursion > would be OK here, if it allows speed/memory saving for > usual processing. > Except maybe the most obvious cases like a flat 'from-parent()'? Cheers, Andreas
