Property classes and eventually, new Property handling.

[John Austin <jw...@sympatico.ca>]

After my last post I went away to play in the code for a while.

Mostly to see what is necessary to isolate a minmal set of
classes related to Property handling.

What I found is:

1) Property is ubiquitous: every client class knows what package
   it lives in. As a planning point, I better think about keeping
   a Property class (or prepare to make a lot more changes and
   lose a few friends). 

2) PropertyList and PropertyListBuilder are used in fewer places.
   but they are used a lot. PropertyList is referenced 129 times  
   and PropertyListBuilder only 8 times. Most of these references 
   are in the Property class. If they can be hidden, the problem
   is bounded by the Property class.

One way to discover the scope of an API is to rename a class or a
package. Doing so breaks all of the compile units that depend on
the renamed class(es). Restoring the missing interfaces restores
the system if the restoration obeys the previous class contracts.

As I suspected, automated code generation for properties is
do-able. There are more than 17,000 lines in files generated
through Ant target: 'codegen'. Many of these are clients of the
Property class. Changes here can be localized to the XSL files
that generate the code.

-- 
John Austin <jw...@sympatico.ca>

Re: Property classes and eventually, new Property handling.

["Peter B. West" <pb...@powerup.com.au>]

Glen Mazza wrote:
> --- "Peter B. West" <pb...@powerup.com.au> wrote:
> 
>>And now for a little digression on code generation. 
>>My own view of code 
>>generation by XSLT transformation can be summed up
>>as:
>>
> 
> 
> Why, Peter, you're in disagreement with everyone else
> on this issue!  (So what else is new? ;)

Everyone else *here*, I think.  I'm sure there are some others out there 
who agree with me.  When they're released, we'll have a get-together.

>>* the canonical source is the Java code.
>>* transformations are a tool for developer
>>convenience.
>>* they should be used to generate files which are
>>then committed like 
>>any others.
>>* transformation is generally a one-off process,
>>only to be re-used in 
>>extremis.
> 
> 
> BTW, what is a "one-off process"?


Needed once - for the initial generation of the Java source.  From then 
on, required changes are minimal enough (or general enough) to be 
handled bu direct manipulation of the Java source.

>>* it is the developer's responsibility to ensure
>>that any re-generation 
>>does not lose patches to the previously generated
>>and committed source.
>>

Peter
-- 
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Re: Property classes and eventually, new Property handling.

[Glen Mazza <gr...@yahoo.com>]

--- "Peter B. West" <pb...@powerup.com.au> wrote:
> 
> And now for a little digression on code generation. 
> My own view of code 
> generation by XSLT transformation can be summed up
> as:
> 

Why, Peter, you're in disagreement with everyone else
on this issue!  (So what else is new? ;)

> * the canonical source is the Java code.
> * transformations are a tool for developer
> convenience.
> * they should be used to generate files which are
> then committed like 
> any others.
> * transformation is generally a one-off process,
> only to be re-used in 
> extremis.

BTW, what is a "one-off process"?

> * it is the developer's responsibility to ensure
> that any re-generation 
> does not lose patches to the previously generated
> and committed source.
> 

Glen

__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Re: Property classes and eventually, new Property handling.

["Peter B. West" <pb...@powerup.com.au>]

John Austin wrote:
> After my last post I went away to play in the code for a while.
> 
> Mostly to see what is necessary to isolate a minmal set of
> classes related to Property handling.
> 
> What I found is:
> 
> 1) Property is ubiquitous: every client class knows what package
>    it lives in. As a planning point, I better think about keeping
>    a Property class (or prepare to make a lot more changes and
>    lose a few friends). 
> 
> 2) PropertyList and PropertyListBuilder are used in fewer places.
>    but they are used a lot. PropertyList is referenced 129 times  
>    and PropertyListBuilder only 8 times. Most of these references 
>    are in the Property class. If they can be hidden, the problem
>    is bounded by the Property class.

In alt.design individual classes in fop.fo.properties extend 
fop.fo.Property, but these classes are singletons, providing access to 
what is effectively static information about the properties.

The multitude of property instances is represented by the interface 
fop.datatypes.PropertyValue, the abstract class AbstractPropertyValue 
and the class PropertyValueList, which implements PropertyValue, and the 
other classes in fop.datatypes which generally extend AbstractPropertyValue.

> One way to discover the scope of an API is to rename a class or a
> package. Doing so breaks all of the compile units that depend on
> the renamed class(es). Restoring the missing interfaces restores
> the system if the restoration obeys the previous class contracts.
> 
> As I suspected, automated code generation for properties is
> do-able. There are more than 17,000 lines in files generated
> through Ant target: 'codegen'. Many of these are clients of the
> Property class. Changes here can be localized to the XSL files
> that generate the code.

The classes in fop.fo.properties (apart from Property.java itself) 
*could* be generated by XSLT.  I used perl, one-off.  If I need to make 
global changes, I'll use perl again.  If I need to change, add or delete 
individual classes, I'll do it manually, based on a like-minded class if 
necessary.  Should take about two minutes.  How dramatically is the set 
of properties in XSL-FO going to change?

And now for a little digression on code generation.  My own view of code 
generation by XSLT transformation can be summed up as:

* the canonical source is the Java code.
* transformations are a tool for developer convenience.
* they should be used to generate files which are then committed like 
any others.
* transformation is generally a one-off process, only to be re-used in 
extremis.
* it is the developer's responsibility to ensure that any re-generation 
does not lose patches to the previously generated and committed source.

Using this approach, the source you extract from CVS is the source you 
compile.  If you apply a fix to that source, you know that it can go 
directly into the codebase.

An example is src/codegen/xml-lang.xml, which is transformed by 
src/codegen/xml-lang.xsl into 
org/apache/fop/datatypes/CountryLanguageScript.java.  All that I could 
find about countries, languages and scripts is in xml-lang.xml. The 
result is checked-in to CVS, and will be part of the code base of any 
checkout.  How often is this information going to change?  Only if there 
are major changes to the information content of the relevant documents 
will the structure of the files need to be revisited, and it is no 
particular hardship to manage such cases.

Yes, there are situations in which it is *extremely* convenient to use 
code-munging - the Java 1.3/1.4 situation springs to mind.  The CPP was 
extremely convenient too, for similar reasons.  XSLT is much more 
powerful than CPP.  Why is there no equivalent of CPP in Java?  Why are 
we going to such trouble to create a situation which has even greater 
capacity for obfuscation that CPP?  Because we're smarter than the 
developers of Java?  Or because we have short memories?

Peter
-- 
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>