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