xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas L Delmelle <a_l.delme...@pandora.be>
Subject Re: RTF and table/column widths - table width attribute
Date Tue, 14 Mar 2006 17:24:38 GMT
On Mar 14, 2006, at 07:43, b.ohnsorg@freenet.de wrote:

> Von: "Andreas L Delmelle"<a_l.delmelle@pandora.be>
>> BTW, dunno if you noticed, but you can pass a null into i.e.
>> LenthRangeProperty.getOptimum() to get to the underlying Property,
>> without the need for a PercentBaseContext...
>> (~ something like: LengthRangeProperty.getOptimum(null).getNumeric
>> ().getValue()?)
> No, I didn't notic this, maybe it should be mentioned in the  
> javadocs (which are sometimes a bit short of information). It's not  
> obvious to me, that a LengthRangeProperty is a replacement for the  
> width-attribute. Maybe the javadoc comment should be something like  
> this:

Good point! I must admit that I stumbled upon this myself (in  
LengthRangeProperty.getString()), trying to solve your problem... ;)

> Additionaly getWidth should be declared deprecated (again the  
> compiler helps to find every use of deprecated API...blabla) and  
> people like me, sticking to the javadocs, won't ask that much. And  
> a bit earlier on this topic it was said, that maybe some features  
> from my work, e.g. the parent-attribute of PercentBaseContext- 
> realization, may be moved to a more abstract layer. Every  
> LayoutManager has a parent (except the root), RTF export needs  
> something similar, so why not moving it towards direction of  
> abstraction.

Also a worthwhile suggestion. Don't let us stop you! :)
How 'bout introducing an AbstractPercentBaseContext which already  
offers a very basic implementation for some methods?

>> AFAICT, at first glance this seems to be used to cast certain types
>> of Property instances to generic Objects before re-casting them to
>> fit the CompoundDatatype interface --the latter cast will definitely
>> not pass the compilation stage, since Property does not implement
>> CompoundDatatype (= not all properties are compound properties). What
>> if the programmer knows beforehand that this cast *will* succeed? The
>> only viable option seems to be to trick the compiler into believing
>> that it just might work... Convenient, no? :)

> But a method "getObject" returning "this" is not necessary, every  
> class is instanceof Object so you can assign any instance to a  
> variable of type "Object" and calling methods like HashMap.put or  
> ArrayList.add results (after widening conversion)

Yes, but this does mean declaring a new local variable to hold the  
result, which I suppose the original programmer wanted to avoid (?  
guessing here, since I'm not the author... I'm just trying to make  
sense of it --maybe there is none :))

Anyway, you'd have to go:

Object o = property;
CompoundDatatype c = (CompoundDatatype) o;

or even:

CompoundDatatype c = (CompoundDatatype) ((Object) property);

where we currently have:

CompoundDatatype c = (CompoundDatatype) property.getObject();

> in calling the method containing "Object" in it's signature. It  
> makes no sense to me to reprogram the widening conversion and it's  
> not really good programming style to do that much type-guessing and  
> casting.

It's not really 'type-guessing' here. The Property instance in  
question is guaranteed to be an instance of a class implementing  
CompoundDatatype... for other properties, the methods  
PropertyMaker.getSubprop() and .setSubprop() will never be called.

> It needs time and is a possible source for runtime errors  
> (ClassCastException...) if not properly used.

Note: *if* not properly used... Now, you weren't going to use it  
improperly, were you? ;P Just kidding, of course.
Well, it won't lead to a runtime error here (see above), and  
declaring a new local variable also takes time (as does the double  
cast), so this still does not convince me...

> Maybe the properties should have a getCompoundDatatype-method which  
> may return "null".

Now, this would make sense if 50% (or more) of all FO-properties were  
compound, but I'm roughly guessing that it's closer to 15% (? widths,  
space-*, keep-*... any others).
I also seem to remember getObject() being used in the J2SE API  
itself, just can't remember where exactly. Maybe I'm imagining  
things, maybe I'm not and that's where the original author got the  
idea in the first place (?)

> Let's call it a facade or a factory method. So you the compiler  
> helps you in finding errors (someone calling this facade or factory  
> method and assigning it to the wrong type...). There are two ways  
> in Java to emulate multiple inheritance, either you use multiple  
> interfaces and do some instanceof-checks, I prefer the facade- or  
> factory-pattern. The more common objects has methods to access the  
> less common object or may create a non persistent object,  
> containing the other interface's features. Depends on personal  
> taste (I dislike casting against the direction of abstraction, the  
> other direction is made by the VM).

I see. So it is a matter of preference/personal taste? Well, the  
point is exactly that this method serves to switch the runtime type  
of a Property instance, without having to perform a cast... Still  
don't like it? :)

> I don't want to teach a how-to-program-lesson, but all my questions  
> are caused by a lack of information in the code/ javadocs. Maybe  
> some other future contributers don't ask that much (sometimes I'm  
> quite annoying) and uncomment some attributes and causing much more  
> damaga than being helpful. Or there's a FOP-cookbook, which I  
> haven't read yet but ought to study,  before spamming the dev- 
> list...(You know, what you did, I must understand first, how you  
> thought at this moment, to understand, why the code's done this way  
> to do it the same.)

Well, this is indeed something that needs work. I agree with you that  
the current state of our javadocs often raises more questions than it  
answers (in a whole lot of places)... :(
All I can say is: Feel free to update these as you see fit, and  
submit patches. It's what I try to do whenever I 'discover' how a  
certain method performs its magic.

Again: thanks for the valuable feedback!



View raw message