On Mar 14, 2006, at 07:43, [EMAIL PROTECTED] wrote:

Von: "Andreas L Delmelle"<[EMAIL PROTECTED]>

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!


Cheers,

Andreas

Reply via email to