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
