czt-devel — For programmers using the CZT code

[CZT-Devel] Location of template and example files

[Petra M. <pe...@cs...>]

Hi,

I think we need an agreement on handling template and example files.

Template files are files from which source code is generated. The template
files of Gnast (the source code genetator) are currently located in src/vm
and the java source code lives in src/java (which is inconsistent with 
most other
czt subprojects where the java source code lives in src). However, if 
the java
source code lives in src, where should the template files live? I am 
planning
to add some template files to the parser. One is needed for the scanner, 
which
is used by different parsers. To avoid duplicating code I want to write 
an xml
file containing the java source code and an xsl script which transforms the
xml into java source code so that several versions of the scanner can be
generated from just one file. This approach can probably also be used to 
handle
the different parser versions (Z, OZ, TCOZ etc.).
I've got the same problem in corejava where I want to generate ZChar.java
and ZString.java from an XML file.

I can think of several approaches:
1) Gnast approach: src/vm, src/xsl, src/java directories
2) Java lives in src, template files live in another directory called 
templates or
   xsl or whatever

Another question is where the generated source code should go in. It 
could go
into src, but then the clean target is difficult to write. Each 
generated file has
to be removed and it is likely to forget one. Another possibility is to 
put it
into build/src and compile into build/classes. Then the clean target 
just needs to
remove the build directory.



Example files are currently distributed randomly in the project tree.
Some are in zml/examples, unicode examples are in jedit, and some
subprojects like the parser also have their own locale example files.
I wonder whether it is a good idea to have just one location for example
files so that they can be used by different czt subprojects.
Another point of confusion are the file endings. It would be nice to
have a common schema for the different file types (latex, utf8, utf16,
xml, z, oz, tcoz) so that tools can use that information. Are there existing
conventions? As far as I know tex and zed are used for latex specifications.
What about Object Z latex specifications?

Any ideas, suggestions, etc.?

Petra

[CZT-Devel] [Announce] ZML and Z AST API change

[Petra M. <pe...@cs...>]

Hi all,

the ZML has changed slightly in CVS.

Operator templates now use an inheritance hierarchy for
Operator and Operand.  This is more consistent with other parts
of the schema, and allows stronger typing within the Java AST.
This has changed the XML format from:
<OptempPara ...>
  <Operand/>
  <Word>*</Word>
  <Operand/>
</OptempPara>
    to
<OptempPara ...>
  <Operand/>
  <Operator><Word>*</Word></Operator>
  <Operand/>
</OptempPara>

Changes to the Z AST classes:
- method getWordOrOperand() in OptempPara has renamed to getOper()
   and now contains a List of Oper
- Oper is a new abstract class; the base class of Operand and Operator
- Operator is a new class, containing a Word (which is of type String)

Petra

Re: [CZT-Devel] Object-Z parser v1.0

[Timothy M. <tim...@sv...>]

Petra Malik wrote:
> Just got an idea what the error could be ... each OptempPara needs Cat 
> and Prec set in order to be valid.
> Could you please make sure that you alsways call setCat(...) and 
> setPrec(...) before validating.
> 
Problem solved! I was only setting Prec for infix templates.  I now have 
Prec set as 0 for all the other templates.

Thanks,
Tim

Re: [CZT-Devel] Object-Z parser v1.0

[Petra M. <pe...@cs...>]

Hi Tim,


Petra Malik wrote:

> Unfortunately the validator is still throwing exceptions. But this 
> time I cannot find a meaningful
> error message. All the messages are null as far as I can see. I have 
> got no idea ... perhaps this is a bug in Jaxb.
> Anyway, it will take some time to solve this :-(

Just got an idea what the error could be ... each OptempPara needs Cat 
and Prec set in order to be valid.
Could you please make sure that you alsways call setCat(...) and 
setPrec(...) before validating.

Petra

Re: [CZT-Devel] Object-Z parser v1.0

[Petra M. <pe...@cs...>]

I added a very first version of the new scanner. To run the parser, you 
now also need parser.jar, which
is generated when installing subproject parser by running ant within 
directory <CZT_HOME>/parser.

In order to use the new scanner you need to edit Main.java (just search 
for scanner and you will find the
place). Since the new scanner is not working very well, I left the 
original scanner as the default.

Next thing to do: parse the %%Zchar and %%Zword so that the scanner 
knows them.
At the moment, the scanner uses a fixed map of known latex commands.

Timothy Miller wrote:

> That sounds like a good plan. I already have a SmartScanner version in 
> there - I think it's much the same as the original. It's probably best 
> to use Mark's original version so we don't have multiple versions of 
> the same file floating around.

I didn't bother to do it know; I just used the existing SmartScanner.

> When I hacked your scanner into the parser, it seemed to go fairly 
> smoothly. I ran the bbook.utf8 example through it. The only problem 
> was that it seemed to think that "[NAME, DATE]" was a narrative 
> paragraph. I'm not sure if there is a hidden ZED token (is there a ZED 
> token in unicode?) to start that paragraph, but it didn't seem to 
> recognise it.

Ahhh, right. This is a bug in bbook.utf8. The ZED token is missing ... I 
should update the example files.

> By the way, I made a small change to the parser now so it handles ZED 
> instead of ZSECTION (or did I mention this already?).

Thanks! :-)

Petra

Re: [CZT-Devel] Object-Z parser v1.0

[Timothy M. <tim...@sv...>]

Petra Malik wrote:
> I fixed some bugs in corejava.
> One of them is quite nasty and I am not sure how to convince gnast to 
> generate the correct code.
> I modified the generated code and checked it in to get rid of the bug 
> for now (I have to find
> a long term solution later).
> Unfortunately the validator is still throwing exceptions. But this time 
> I cannot find a meaningful
> error message. All the messages are null as far as I can see. I have got 
> no idea ... perhaps this is a bug in Jaxb.
> Anyway, it will take some time to solve this :-(
>
Sorry for making your life hard! :)

> But first I want to connect my scanner with your parser.
> Hopefully I can check in a first version later this day.
> I am planning to copy the current version of my scanner and Marks 
> SmartScanner into your (oz/parser)
> directory. Then we can modify them till it works without affecting the 
> other tools and later we have to decide
> into which package the scanner should go and how it can be used by 
> different parsers, transformers, etc.
> 
> Hope you are happy with that.
> 
That sounds like a good plan. I already have a SmartScanner version in 
there - I think it's much the same as the original. It's probably best 
to use Mark's original version so we don't have multiple versions of the 
same file floating around.

When I hacked your scanner into the parser, it seemed to go fairly 
smoothly. I ran the bbook.utf8 example through it. The only problem was 
that it seemed to think that "[NAME, DATE]" was a narrative paragraph. 
I'm not sure if there is a hidden ZED token (is there a ZED token in 
unicode?) to start that paragraph, but it didn't seem to recognise it.

By the way, I made a small change to the parser now so it handles ZED 
instead of ZSECTION (or did I mention this already?).

Cheers,
Tim

Re: [CZT-Devel] Object-Z parser v1.0

[Petra M. <pe...@cs...>]

Hi,

Timothy Miller wrote:

> Make sure you do an 'ant clean'. If a new token is added in the 
> parser, but the scanner is not rebuilt, it seems to cause problems. I 
> can't see why... the scanner uses the newest sym.java, but hat should 
> solve the problem.

Thanks, that solved the problem.

I fixed some bugs in corejava.
One of them is quite nasty and I am not sure how to convince gnast to 
generate the correct code.
I modified the generated code and checked it in to get rid of the bug 
for now (I have to find
a long term solution later).
Unfortunately the validator is still throwing exceptions. But this time 
I cannot find a meaningful
error message. All the messages are null as far as I can see. I have got 
no idea ... perhaps this is a bug in Jaxb.
Anyway, it will take some time to solve this :-(

But first I want to connect my scanner with your parser.
Hopefully I can check in a first version later this day.
I am planning to copy the current version of my scanner and Marks 
SmartScanner into your (oz/parser)
directory. Then we can modify them till it works without affecting the 
other tools and later we have to decide
into which package the scanner should go and how it can be used by 
different parsers, transformers, etc.

Hope you are happy with that.

Petra

Re: [CZT-Devel] Object-Z parser v1.0

[Timothy M. <tim...@sv...>]

Hi,

> Ups, I get lots of parse error exceptions.
> The first one (if I just run run.sh) is:
> 
> \nat :Syntax error at character 126 of input
> Couldn't repair and continue parse at character 126 of input
> java.lang.Exception: Can't recover from previous error(s)
> 
> That's not what you want to demonstrate, or do I miss something?
> 
Make sure you do an 'ant clean'. If a new token is added in the parser, 
but the scanner is not rebuilt, it seems to cause problems. I can't see 
why... the scanner uses the newest sym.java, but hat should solve the 
problem.

Cheers,
Tim

Re: [CZT-Devel] Object-Z parser v1.0

[Petra M. <pe...@cs...>]

Hi Tim,

Timothy Miller wrote:

> Ah, yes, I have tried this, but in visitOpTempPara in the AstToJaxb 
> class, each element in the WordOrOperand list is typecast to a Term, 
> so the typecast from a String fails.

Ughh, I forgot about this. :-(
It seems that nobody has used operator templates before.
I am going to fix that now ...

> I've just checked in a version of the parser that demonstrates this. 
> It also has the GENSCH rule added to it.

Ups, I get lots of parse error exceptions.
The first one (if I just run run.sh) is:

\nat :Syntax error at character 126 of input
Couldn't repair and continue parse at character 126 of input
java.lang.Exception: Can't recover from previous error(s)

That's not what you want to demonstrate, or do I miss something?

Petra

Re: [CZT-Devel] Object-Z parser v1.0

[Timothy M. <tim...@sv...>]

Petra Malik wrote:
> 
> This tells that there is a DeclName inside OptempPara but a Word or an 
> Operand is expected.
> The WordOrOperand List within OptempPara can only contain Strings or 
> instances of class
> Operand. I guess you are trying to add DeclName instead which is 
> possible; but you get an invalid
> AST.
> Does that help?
> 
Ah, yes, I have tried this, but in visitOpTempPara in the AstToJaxb 
class, each element in the WordOrOperand list is typecast to a Term, so 
the typecast from a String fails.

I've just checked in a version of the parser that demonstrates this. It 
also has the GENSCH rule added to it.

Thanks,
Tim

Re: [CZT-Devel] Object-Z parser v1.0

[Petra M. <pe...@cs...>]

Hi again,

Timothy Miller wrote:

> Also, I am having a problem with the AST validator that I cannot 
> solve, but which I think you may be able to. I get an exception when 
> validating operator templates, which you should be able to reproduce 
> if you go to Main.java in the source, and in the "getAst" method, 
> uncomment the lines doing the validation. If you could have a look at 
> that when you get a chance, and let me know what I'm doing wrong, I 
> would be very greatful.

I fixed a bug in corejava (so you have to update and recompile it).
However, there are still exceptions:

... lots of crap ...

DefaultValidationEventHandler: [ERROR]: tag name 
"net.sourceforge.czt.z.jaxb.gen.DeclNameElement" is not allowed. 
Possible tag names are: 
<net.sourceforge.czt.z.jaxb.gen.OperandElement>,<net.sourceforge.czt.z.jaxb.gen.OptempPara.Word> 

     Location:  obj: 
net.sourceforge.czt.z.jaxb.gen.impl.OptempParaElementImpl@384065

... more crap ...

This tells that there is a DeclName inside OptempPara but a Word or an 
Operand is expected.
The WordOrOperand List within OptempPara can only contain Strings or 
instances of class
Operand. I guess you are trying to add DeclName instead which is 
possible; but you get an invalid
AST.
Does that help?

Petra

Re: [CZT-Devel] Object-Z parser v1.0

[Petra M. <pe...@cs...>]

Hi Tim,

Timothy Miller wrote:

> Yes, Mark mentioned your unicode scanner when he rang the other day, 
> so I checked it out of CVS and connected to the parser. It seemed to 
> work ok, but the toolkit libraries are all in latex, so I couldn't use 
> operators etc yet.

Ohhh, you are already done? You are very quick! :-)
Did you check it in somewhere in CVS so that we can continue improving 
it together?
I also added a latex scanner, it is in 
parser/src/net/sourceforge/czt/scanner/LatexLexer.java.
It first transforms latex into unicode and then scans the unicode.

>> - ZSECTION:
>
> ZSECTION is the latex tag "\begin{zsection}" and SECTION is just the 
> word "section". Because unicode doesn't have a ZSECTION character, I 
> think the best solution would be to remove the ZSECTION token from the 
> parser and have the latex scanner ignore it. This won't cause any 
> problems with an lalr parser.

The standard tells that \begin{zsection} should be converted to ZED.
Is your parser happy with getting a ZED token there?

>> - GENSCH:
>
> Yes, I noticed this too. The token should be GENSCH, but he problem is 
> that a schema definition in latex is:
>   \begin{schema}{Name}
>
> and a generic schema definition is
>   \begin{schema}{Name}[Params]
>
> So we need a two-token lookahead to tell whether it has parameters. I 
> was avoiding this in the parser by combinining them:
>   SCH boxName:bn optFormalParameters:ofp schemaText:st END
>
> So the parameters are optional. The easiest solution for now is to add 
> a GENSCH rule as well, but a longer term solution would be to 
> implement the lookahead.

I see. My latex to unicode converter has the same problem (and I haven't 
solved it yet).
Lets follow your suggestions. Could you add the GENSCH rule?

Next I am going to change the unicode scanner to return the differnt 
stroke characters ...
lets see how we get on with this :-)

Regards,
Petra

Re: [CZT-Devel] Object-Z parser v1.0

[Timothy M. <tim...@sv...>]

Hi Petra,

> thanks for providing this nice parser :-)
> 
I'm glad you like it!! :)

> Mark suggested to use my scanner together with your parser. I had a 
> short look
> at your token names and was very happy to find out that most of the 
> token names
> are equal.
Yes, Mark mentioned your unicode scanner when he rang the other day, so 
I checked it out of CVS and connected to the parser. It seemed to work 
ok, but the toolkit libraries are all in latex, so I couldn't use 
operators etc yet.

> However, there are still a few things I am not sure how to 
> handle:
> 
> - DELTA (one of your tokens) is not defined as a symbolic keyword in the
>   Z standard. Do you need that at all? Should I change my scanner to 
> recognice
>   that token as well?
> 
Yes, that is an Object-Z token that is used to identify secondary 
attributes, so an OZ scanner will need to return it.

> - ZSECTION (one of your tokens):
>   What is the difference between ZSECTION and SECTION?
>   Is ZSECTION an alphabetic keyword as well?  Is it an OZ keyword?
> 
ZSECTION is the latex tag "\begin{zsection}" and SECTION is just the 
word "section". Because unicode doesn't have a ZSECTION character, I 
think the best solution would be to remove the ZSECTION token from the 
parser and have the latex scanner ignore it. This won't cause any 
problems with an lalr parser.

> - NUMSTROKE, NEXTSTROKE, OUTSTROKE, and INSTROKE
>   (some of your tokens) are handled equally by my scanner. My scanner
>   returns the STROKE token, which is a String, and it is left to the parser
>   to figure out which kind of stroke it is.  I guess it is quite easy
>   to change the scanner to return the four different kinds of strokes ...
>   but if we want to stay as close to the standard as possible we should go
>   for STROKE.
> 
Yes, I noticed this. The reason I am using the 4 different types is that 
I am trying to make the parser as independent of the scanner as 
possible. The same problem occurs when we want to extract strokes from 
DECORWORDs to create a DeclName instance. However, if we want to follow 
the standard, I propose two possible solutions:
- Create an interface called something like CZTScanner, which provides 
methods for extracting strokes from DECORWORDs and from STROKEs, and 
have each scanner implement this interface. This removes any lexical 
work from the parser; or
- Do what I think your latex scanner seems to do and convert everything 
to unicode before sending it to the parser.

The best solution from a design point of view would probably be to do both?

> - GENSCH (one of my tokens):
>   I couldn't find the corresponding token in you parser. Is it GCH?
>   Since the name GENSCH is used in the standard I would like to use that
>   name as well (makes it easier for others to read the code).
>
Yes, I noticed this too. The token should be GENSCH, but he problem is 
that a schema definition in latex is:
   \begin{schema}{Name}

and a generic schema definition is
   \begin{schema}{Name}[Params]

So we need a two-token lookahead to tell whether it has parameters. I 
was avoiding this in the parser by combinining them:
   SCH boxName:bn optFormalParameters:ofp schemaText:st END

So the parameters are optional. The easiest solution for now is to add a 
GENSCH rule as well, but a longer term solution would be to implement 
the lookahead.

> - the following tokens are probably OZ tokens (could you please check
>   whether I am right):
>   CLASS, STATE, INIT, INITWORD, OPSCH, VISIBILITY, INHERITS,
>   DCNJ, DGCH, DSQC, PARALLEL, ASSOCPARALLEL, GCH,
>   CLASSCOM, ENDCLASSCOM, CLASSCOMWORD, DECLWORD,
Yes, these are all OZ tokens, except DECLWORD, which is a normal 
DECORWORD, but it occurs before a colon in a declaration. This is 
returned in Mark's SmartScanner to eliminate the set elaboration vs. set 
comprehension problem.

>   BOXNAME
I return BOXNAME after I see a "\begin{schema}" or "\begin{class}" 
otherwise the SmartScanner gets confused. The rule is:
   SCH NAME SchemaText END

The smart scanner sees NAME and begins lookahead, consuming the first 
DECORWORD token in SchemaText if there is one. When it stops lookahead, 
it returns all the backed-up tokens, not analysing them to see if they 
are before a colon, therefore they will never be returned DECLWORDs. I 
know that probably doesn't make sense just reading it. The BOXNAME was 
just a quick workaround to get the parser up and running. The best 
solution is to change the SmartScanner class.

>   I don't know how to change my scanner to recognice these tokens. Where
>   can I learn about the unicode characters in OZ?
> 
I'm not sure about the unicode characters. The best bet would be the 
people from NUS. I recall having read some papers on their XML stuff, 
and they mention unicode characters. I will ask Roger Duke or Graeme 
Smith the next time I see one of them - they may have an idea.

Perhaps someone on this mailing list can help?

> - _APPLICATION, _RENAME (some of your tokens)
>   I have got no idea what those are good for. I guess my scanner doesn't 
> have
>   to worry about those since these are used internally?
> 
Yes, they are just used to force precedence in the parser - they are not 
tokens. This is why they start with an underscore... I should really 
document that in the parser! :)

> 
> By the way, do you know whether it is possible to connect one scanner to 
> different
> parsers? I am worried about the sym.java class generated by the cup 
> parser. The
> scanner usually needs the sym.java class, but since I've got several of 
> them there
> remains the question which one should the scanner use?
> 
I'm not sure I understand your problem. I know that you can get cup to 
write the symbols to a specified file name, but it seems that your 
problem is in knowing which class to use in the scanner? I doubt that 
jflex would have any support for that... it doesn't seem very adapt to 
reuse. I do know that you can ask cup to produce the sym.java file as a 
class instead of an interface, so you can create an instance of that 
class and pass it to the scanner?

Thanks for your feedback,
Tim

Re: [CZT-Devel] Object-Z parser v1.0

[Petra M. <pe...@cs...>]

Hi again,

Petra Malik wrote:

> - NUMSTROKE, NEXTSTROKE, OUTSTROKE, and INSTROKE
>   (some of your tokens) are handled equally by my scanner. My scanner
>   returns the STROKE token, which is a String, and it is left to the 
> parser
>   to figure out which kind of stroke it is.  I guess it is quite easy
>   to change the scanner to return the four different kinds of strokes ...
>   but if we want to stay as close to the standard as possible we 
> should go
>   for STROKE.

Mark just pointed out that there is no reason to stick so closely to the 
standard.
I suggest that I change my scanner to return NUMSTROKE, NEXTSTROKE,
etc. ...

Petra

Re: [CZT-Devel] Object-Z parser v1.0

[Petra M. <pe...@cs...>]

Hi Tim,

thanks for providing this nice parser :-)

Mark suggested to use my scanner together with your parser. I had a 
short look
at your token names and was very happy to find out that most of the 
token names
are equal. However, there are still a few things I am not sure how to 
handle:

- DELTA (one of your tokens) is not defined as a symbolic keyword in the
   Z standard. Do you need that at all? Should I change my scanner to 
recognice
   that token as well?

- ZSECTION (one of your tokens):
   What is the difference between ZSECTION and SECTION?
   Is ZSECTION an alphabetic keyword as well?  Is it an OZ keyword?

- NUMSTROKE, NEXTSTROKE, OUTSTROKE, and INSTROKE
   (some of your tokens) are handled equally by my scanner. My scanner
   returns the STROKE token, which is a String, and it is left to the parser
   to figure out which kind of stroke it is.  I guess it is quite easy
   to change the scanner to return the four different kinds of strokes ...
   but if we want to stay as close to the standard as possible we should go
   for STROKE.

- GENSCH (one of my tokens):
   I couldn't find the corresponding token in you parser. Is it GCH?
   Since the name GENSCH is used in the standard I would like to use that
   name as well (makes it easier for others to read the code).

- the following tokens are probably OZ tokens (could you please check
   whether I am right):
   CLASS, STATE, INIT, INITWORD, OPSCH, VISIBILITY, INHERITS,
   DCNJ, DGCH, DSQC, PARALLEL, ASSOCPARALLEL, GCH,
   CLASSCOM, ENDCLASSCOM, CLASSCOMWORD, DECLWORD,
   BOXNAME
   I don't know how to change my scanner to recognice these tokens. Where
   can I learn about the unicode characters in OZ?

- _APPLICATION, _RENAME (some of your tokens)
   I have got no idea what those are good for. I guess my scanner 
doesn't have
   to worry about those since these are used internally?


By the way, do you know whether it is possible to connect one scanner to 
different
parsers? I am worried about the sym.java class generated by the cup 
parser. The
scanner usually needs the sym.java class, but since I've got several of 
them there
remains the question which one should the scanner use?

Regargs,
Petra

[CZT-Devel] Object-Z parser v1.0

[Timothy M. <tim...@sv...>]

Hi all,

This is just a quick note to let people know that I have checked a
preliminary version of anObject-Z parser in to the CZT sourceforge
server. The module name is 'oz'. Feedback is most welcome.

If you are only interested in Z, you can also check it out. It parses Z
as well... it's basically a Z parser with Object-Z class paragraphs.
I've tried to follow the ISO Z standard as closely as possible, just
making my own decisions for the Object-Z stuff. I've had a bit of
trouble with some precedence stuff, so at the moment a couple of things
are missing, e.g. schema negation. There are also a few other problems,
e.g. no nested word glue. The input is Latex.

To compile, just type 'ant', unless you are using a version of JavaCup <
1.0k. In that case, run './cup.sh' followed by 'ant code'.

To run a specification, type './run.sh file'. This will parse the
toolkits (number, sequence, Object-Z toolkits etc.) and then the
file supplied on the command line. It only accepts one file at this
primitive stage. There is a small Object-Z example in
'examples/dms.tex'. This will produce a basic GUI (thanks to Petra for
the code for that!) with your specification as a
JTree. If you just type './run.sh' (or 'ant run') this will start the
GUI with just the toolkits in the tree. This will throw an exception,
but it is related to the Jaxb stuff - you should still be able to see
the tree.

Happy parsing!

Tim

[CZT-Devel] Re: Inheritance hierarchy for factory classes

[Petra M. <pe...@cs...>]

Hi,

after reading an extreme programming book, I changed the factories as 
suggested by Tim.
The book told me that the design should be as simple as possible and one 
shouldn't implement
features that are not needed at the time of its implementation. :-)

The object Z factory now extends the Z factory.

Petra

[CZT-Devel] Developer Guidelines

[Petra M. <pe...@cs...>]

Hi all,

I started to write a document that contains information for developers.
The source is in
  web/src/content/xdocs/developer.xml

To build it change into the directory web,
call forrest (http://xml.apache.org/forrest/)
and have a look at
  web/build/site/developer.html

Comments, corrections, contributions, etc.
are very welcome.

Petra

[CZT-Devel] Inheritance hierarchy for factory classes

[<pe...@cs...>]

Hi Tim,

I am cc'ing czt-devel since other developers
might be interested in that topic as well.

Tim wrote:
> One other question: is it possible to have the OzFactory interface and
> it's implementation inherit from ZFactory (and ZFactoryImpl)? I may be
> missing something that makes this not very sensible from a design point
> of view, but from a user view I think that this would be better.

We (Mark and I) decided to do it this way since it is not guaranteed that
Z extensions are designed in a tree like structure that you need for
inheritance hierarchies (without multiple inheritance).
For instance, currently there is a zpatt and an oz package. We could
inherit ZpattFactory and OzFactory from ZFactory, but what should we
do if we want to provide a ZpattOz package which uses elements from
both packages (zpatt and oz)? The ZpattOzFactory cannot extend OzFactory
and ZpattFactory since multiple inheritance is not possible in Java.

In order to overcome the inconvenience of having multiple factory classes,
I want to provide a Delegator (a proxy class which can implement several
interfaces). You can have a look at net.sourceforge.czt.util.Delegator
and try whether it works. There is also a junit test in
corejava/tests/net/sourceforge/ctz/util/DelegatorTest.java
which should show how the Delegator class can be used.
I am going to provide an example that uses the Delegator class
as soon as possible.

Any comments are welcome. We are not sure whether having a ZpattOz package
is possible at all. Perhaps we are trying to be too general but achieve
nothing from this approach?

Petra

[CZT-Devel] Corejava release 1.1.1

[Petra M. <pe...@cs...>]

Hi,

corejava 1.1.1 has been released. It contains Java source code for
Z annotated syntax trees, reading and writing XML files etc.

This release fixes a few bugs:

  * API Change:
    change all immutable properties to be mutable since immutable properties
    are no longer needed (they were there for historic reasons)
    => all getter methods that return an immutable list in corejava_1_1_0
       now return a (mutable) list (an example is getDeclName() in AxPara)
    => there are a few more setters now (an example is setName(String)
       in ZSect)
    => there are a few more default factory methods in CoreFactory and
       CoreFactoryImpl (an example is createAxPara())
    => some of the constructors of the implementation classes in package
       have changed; now none of the constructors accepts arguments
       (this should not have influence on applications since these
       constructors are not supposed to be used by applications :-)
    => remove class ImmutableList since it is no longer used

  * add namespace information to the DOM output and write each node
    on its own line (indentation is still missing)

  * use the CLASSPATH environment variable when running the examples
    and tests to avoid NoClassDefFoundError when CLASSPATH is set properly
    but jwsdp.home is not set


Hava fun,
Petra