You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jaxme-dev@ws.apache.org by Frederic Ahring <FA...@de.ibm.com> on 2005/08/12 17:36:41 UTC

Re: AbstractJavaMethod.removeThrows etc

Hi, Jochen...

> supply a proper patch (diff -ub oldFile newFile), and I'll apply it. 
> (Sorry for asking, but it is always best to talk in patches and the 
like.)
not sure about this, but I you want it...
please keep in mind that I have neither CVS nor diff around here. I 
transfered all files to a private unix machine, running diff there, and I 
don't know how old my original sources are.

I changed AbstractJavaMethod, adding removeThrows for String, Class and 
JavaQName, and also added a clearThrows() method.

For isThrown the example stated that inheritance is not checked, so a 
check for java.net.MalformedURLException would not find the thrown 
exception java.io.IOException - I assume it was meant the other way round.

I also changed addParam to throw an IllegalParameterException when a 
parameter is added with the same name as an already existing parameter.

Finally I added two methods String[] getParamNames and JavaQName[] 
getParamTypes which, similar to Parameter[] getParams, return a list of 
parameters this function takes. getParamTypes is useful in combination 
with JavaSource.getMethod(String, JavaQName[]), as it can be directly used 
as second parameter.

This is all I had in mind for today. I checked in 
ConditionalIndentationJavaSourceObject, because I thought it would be nice 
to have addThrowNew automatically call addThrow, but it is in different 
classes. I'm not sure as to why it's split up in this way, but I didn't 
want to mess with it too much.

Other thing I have needed (but found other ways of doing it) were having a 
helpermethod which would give me an unused local variable name, for using 
as a loop variable while being called recursively. I had an Stringlist, 
initially filled with getParamNames.
In case you're interested:

    /**
     * Chooses a free variable name. If <code>wantedName</code> is already 
used it will be 'counted up' until a free
     * name is found. Adds this name to the <code>varNames List</code>.
     * 
     * @param wantedName
     *            the preferred name
     * @param varNames
     *            <code>List</code> with all variables in this method 
(gets updated)
     * @return a free variable name
     */
    private String chooseFreeVarName(String wantedName, List varNames) {
        int i = 1;
        String res;
        do {
            res = wantedName + (i > 1 ? String.valueOf(i) : "");
            i++;
            // this shouldn't happen, unless there are really 100 used 
variables or a bug in the List
            if (i > 100) { throw new RuntimeException(
                    "possible loop detected while trying to generate a 
name similar to '" + wantedName + "'"); }
        } while (varNames.contains(res));
        varNames.add(res);
        return res;
    }

I thought about adding it to jaxmejs, too, but wasn't sure if it would 
really be needed by many persons.


The second thing that I thought I needed was a possibility to generate 
JavaCode without it being part of a method, to be added later. Placeholder 
didn't completely satisfy me, as indentations would be wrong. Since I 
didn't actually need it I haven't investigated this further. But I think 
it is not yet possible, is it?

The code is roughly tested and should be simple enough not to contain too 
much bugs :)
Feel free to use all or parts of it, as you might think fits best. If you 
have more suggestions what could be usefull, tell me and I might have a 
look. But the programming part of my thesis is nearly over.

:Frederic:



Re: AbstractJavaMethod.removeThrows etc

Posted by robert burrell donkin <rd...@apache.org>.
On Fri, 2005-08-12 at 21:22 +0200, Jochen Wiedmann wrote:
> Frederic Ahring wrote:
> 
> > please keep in mind that I have neither CVS nor diff around here.
> 
> Such developer systems do still exist? :-)

one of the good things about subversion is that it's layered on webDAV
which uses http. now jame's moved to subversion (good work jochen :),
why not install subversion and give it a try? 

- robert

Re: AbstractJavaMethod.removeThrows etc

Posted by Frederic Ahring <FA...@de.ibm.com>.
Hi, Jochen

> > please keep in mind that I have neither CVS nor diff around here.
> Such developer systems do still exist? :-)
Sure. I'm currently the only one working on this part, so no internal 
infrastructure needed nor configured. I assume RAD does habe plugins for 
all this (in fact I've seen a CVS menu option somewhere) but since I'm not 
familiar with it I decided not to spend too much time fiddling with it. 
(It didn't work right away)


> The methods accepting a string are deprecated, so I decided to remove 
them finally.
no problem, I only used JavaQName, the others were just to be similar to 
what's already there.


[addThrowNew calling addThrow]
> A ConditionalIndentationJavaSourceObject doesn't necessarily have a 
> signature. Think of a static class initializer.
good point, though it could detect this and simply discard the call. 


[creating unique variable names]
> This is, imo, not necessary, because the necessary code is already in 
> place. For example, ConditionalJavaSourceObject.newJavaField(JavaQName) 
> creates a new local field with the given type and a unique name.
Geesh. Well, I haven't found it when I needed it. So now I'm blaming it on 
the documentation ;)


[Java source lines without a surrounding block]
> This should not be too difficult. One could create a subclass of 
> JavaSourceObject, which represents an anonymous block { ... }. The 
> braces could be optional, of course. This object might be added to a 
> method at a later time.
This sounds like a good idea.
Like a method it could also have a list of thrown exceptions, added to the 
surrounding method when put into place.


:Frederic:

---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org


Re: AbstractJavaMethod.removeThrows etc

Posted by Jochen Wiedmann <jo...@gmail.com>.
Frederic Ahring wrote:

> please keep in mind that I have neither CVS nor diff around here.

Such developer systems do still exist? :-)


> I changed AbstractJavaMethod, adding removeThrows for String, Class and 
> JavaQName, and also added a clearThrows() method.

I have integrated these patches, the exception being 
removeThrows(String). The methods accepting a string are deprecated, so 
I decided to remove them finally.


> Finally I added two methods String[] getParamNames and JavaQName[] 
> getParamTypes which, similar to Parameter[] getParams, return a list of 
> parameters this function takes. getParamTypes is useful in combination 
> with JavaSource.getMethod(String, JavaQName[]), as it can be directly used 
> as second parameter.

Integrated.


> This is all I had in mind for today. I checked in 
> ConditionalIndentationJavaSourceObject, because I thought it would be nice 
> to have addThrowNew automatically call addThrow, but it is in different 
> classes. I'm not sure as to why it's split up in this way, but I didn't 
> want to mess with it too much.

A ConditionalIndentationJavaSourceObject doesn't necessarily have a 
signature. Think of a static class initializer.


> Other thing I have needed (but found other ways of doing it) were having a 
> helpermethod which would give me an unused local variable name, for using 
> as a loop variable while being called recursively. I had an Stringlist, 
> initially filled with getParamNames.

This is, imo, not necessary, because the necessary code is already in 
place. For example, ConditionalJavaSourceObject.newJavaField(JavaQName) 
creates a new local field with the given type and a unique name.


> The second thing that I thought I needed was a possibility to generate 
> JavaCode without it being part of a method, to be added later. Placeholder 
> didn't completely satisfy me, as indentations would be wrong. Since I 
> didn't actually need it I haven't investigated this further. But I think 
> it is not yet possible, is it?

This should not be too difficult. One could create a subclass of 
JavaSourceObject, which represents an anonymous block { ... }. The 
braces could be optional, of course. This object might be added to a 
method at a later time.


Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org