3:04 p.m.
Hi folks,
I wonder is it possible to add a field to a JavaClass and to set an array
as its type. The setType(String) method does not support arrays yet and I
don't want to use the other two variants of this method (taking Class and
JavaResource parameters).
I looked at the mentioned method (setType(String)). And found a suitable
place where I could add the support for arrays. However, I'm afraid that
JDT's AST class does not have a convenient newArray....() method.
Or maybe I'm missing something?
Cheers,
Ivan
9:53 a.m.
Hey Ivan!
You're correct, the JDT probably doesn't have a convenient method for this
(it doesn't have much that is convenient,) but what are your proposed
changes?
~Lincoln
On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov
<ivan.st.ivanov(a)gmail.com>wrote:
Hi folks,
I wonder is it possible to add a field to a JavaClass and to set an array
as its type. The setType(String) method does not support arrays yet and I
don't want to use the other two variants of this method (taking Class and
JavaResource parameters).
I looked at the mentioned method (setType(String)). And found a suitable
place where I could add the support for arrays. However, I'm afraid that
JDT's AST class does not have a convenient newArray....() method.
Or maybe I'm missing something?
Cheers,
Ivan
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
4:30 p.m.
Hi Lincoln,
I'm hacking now a solution. Something like:
if (Types.isArray(simpleName))
{
Name name = ast.newSimpleName(Types.stripArray(simpleName));
Type typeOfArray = ast.newSimpleType(name);
type = ast.newArrayType(typeNoArray);
}
I'm just trying to find the most suitable place of the above snippet in the
setType method. Maybe I'll do some refactoring of the existing code.
I noticed also that the code inside:
if (!Strings.areEqual(typeName, simpleName) && requiresImport)
...should also be touched to support arrays.
BTW, we have the same issue with generic types as well. So I'm looking into
them too.
Cheers,
Ivan
P.S. Don't you think that we should have the simple name (e.g. File) in the
field declaration instead of the whole type:
right now it is:
import java.io.File;
public class Test {
private java.io.File file;
}
On Mon, Jul 23, 2012 at 5:53 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
Hey Ivan!
You're correct, the JDT probably doesn't have a convenient method for this
(it doesn't have much that is convenient,) but what are your proposed
changes?
~Lincoln
On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com
> wrote:
> Hi folks,
>
> I wonder is it possible to add a field to a JavaClass and to set an array
> as its type. The setType(String) method does not support arrays yet and I
> don't want to use the other two variants of this method (taking Class and
> JavaResource parameters).
>
> I looked at the mentioned method (setType(String)). And found a suitable
> place where I could add the support for arrays. However, I'm afraid that
> JDT's AST class does not have a convenient newArray....() method.
>
> Or maybe I'm missing something?
>
> Cheers,
> Ivan
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
4:46 p.m.
Hi Ivan,
Using the fully qualified name avoids class name conflicts, so it is
much safer to use than to rely on imports only.
Regards,
George Gastaldi
2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
Hi Lincoln,
I'm hacking now a solution. Something like:
if (Types.isArray(simpleName))
{
Name name = ast.newSimpleName(Types.stripArray(simpleName));
Type typeOfArray = ast.newSimpleType(name);
type = ast.newArrayType(typeNoArray);
}
I'm just trying to find the most suitable place of the above snippet in the
setType method. Maybe I'll do some refactoring of the existing code.
I noticed also that the code inside:
if (!Strings.areEqual(typeName, simpleName) && requiresImport)
...should also be touched to support arrays.
BTW, we have the same issue with generic types as well. So I'm looking into
them too.
Cheers,
Ivan
P.S. Don't you think that we should have the simple name (e.g. File) in the
field declaration instead of the whole type:
right now it is:
import java.io.File;
public class Test {
private java.io.File file;
}
On Mon, Jul 23, 2012 at 5:53 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
>
> Hey Ivan!
>
> You're correct, the JDT probably doesn't have a convenient method for this
> (it doesn't have much that is convenient,) but what are your proposed
> changes?
>
> ~Lincoln
>
> On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov
> <ivan.st.ivanov(a)gmail.com> wrote:
>>
>> Hi folks,
>>
>> I wonder is it possible to add a field to a JavaClass and to set an array
>> as its type. The setType(String) method does not support arrays yet and I
>> don't want to use the other two variants of this method (taking Class and
>> JavaResource parameters).
>>
>> I looked at the mentioned method (setType(String)). And found a suitable
>> place where I could add the support for arrays. However, I'm afraid that
>> JDT's AST class does not have a convenient newArray....() method.
>>
>> Or maybe I'm missing something?
>>
>> Cheers,
>> Ivan
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
4:58 p.m.
Hi George,
Yes, I realized that. So it's up to us to decide which option we take:
1) It is safe to have the fully qualified name in the field declarations,
but it is kinda ugly
2) Declaring the fields with non fully qualified names looks natural (all
of us use this style), but it may produce class name clashes in one out of
1000 or more cases. E.g. adding java.util.Date and java.sql.Date to a class.
I don't mind to keep it in the current way. But when I show the generated
classes to the people, they might get the feeling that something does not
look like in their IDEs.
Regards,
Ivan
On Tue, Jul 24, 2012 at 12:46 AM, George Gastaldi <gegastaldi(a)gmail.com>wrote:
Hi Ivan,
Using the fully qualified name avoids class name conflicts, so it is
much safer to use than to rely on imports only.
Regards,
George Gastaldi
2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
> Hi Lincoln,
>
> I'm hacking now a solution. Something like:
>
> if (Types.isArray(simpleName))
> {
> Name name = ast.newSimpleName(Types.stripArray(simpleName));
> Type typeOfArray = ast.newSimpleType(name);
> type = ast.newArrayType(typeNoArray);
> }
>
> I'm just trying to find the most suitable place of the above snippet in
the
> setType method. Maybe I'll do some refactoring of the existing code.
>
> I noticed also that the code inside:
>
> if (!Strings.areEqual(typeName, simpleName) && requiresImport)
>
> ...should also be touched to support arrays.
>
> BTW, we have the same issue with generic types as well. So I'm looking
into
> them too.
>
> Cheers,
> Ivan
>
> P.S. Don't you think that we should have the simple name (e.g. File) in
the
> field declaration instead of the whole type:
>
> right now it is:
>
> import java.io.File;
>
> public class Test {
>
> private java.io.File file;
>
> }
>
> On Mon, Jul 23, 2012 at 5:53 PM, Lincoln Baxter, III
> <lincolnbaxter(a)gmail.com> wrote:
>>
>> Hey Ivan!
>>
>> You're correct, the JDT probably doesn't have a convenient method for
this
>> (it doesn't have much that is convenient,) but what are your proposed
>> changes?
>>
>> ~Lincoln
>>
>> On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov
>> <ivan.st.ivanov(a)gmail.com> wrote:
>>>
>>> Hi folks,
>>>
>>> I wonder is it possible to add a field to a JavaClass and to set an
array
>>> as its type. The setType(String) method does not support arrays yet
and I
>>> don't want to use the other two variants of this method (taking Class
and
>>> JavaResource parameters).
>>>
>>> I looked at the mentioned method (setType(String)). And found a
suitable
>>> place where I could add the support for arrays. However, I'm afraid
that
>>> JDT's AST class does not have a convenient newArray....() method.
>>>
>>> Or maybe I'm missing something?
>>>
>>> Cheers,
>>> Ivan
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.org
>> "Simpler is better."
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
5:14 p.m.
Hi Ivan,
Yeah, I have to agree with you, this is something that should be
improved. I also don't like having FQN in field declarations.
But, figuring it out how to avoid name clashes may be harder to
implement than using this strategy.
Regards,
George Gastaldi
2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
Hi George,
Yes, I realized that. So it's up to us to decide which option we take:
1) It is safe to have the fully qualified name in the field declarations,
but it is kinda ugly
2) Declaring the fields with non fully qualified names looks natural (all of
us use this style), but it may produce class name clashes in one out of 1000
or more cases. E.g. adding java.util.Date and java.sql.Date to a class.
I don't mind to keep it in the current way. But when I show the generated
classes to the people, they might get the feeling that something does not
look like in their IDEs.
Regards,
Ivan
On Tue, Jul 24, 2012 at 12:46 AM, George Gastaldi <gegastaldi(a)gmail.com>
wrote:
>
> Hi Ivan,
>
> Using the fully qualified name avoids class name conflicts, so it is
> much safer to use than to rely on imports only.
>
> Regards,
>
> George Gastaldi
>
> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
> > Hi Lincoln,
> >
> > I'm hacking now a solution. Something like:
> >
> > if (Types.isArray(simpleName))
> > {
> > Name name = ast.newSimpleName(Types.stripArray(simpleName));
> > Type typeOfArray = ast.newSimpleType(name);
> > type = ast.newArrayType(typeNoArray);
> > }
> >
> > I'm just trying to find the most suitable place of the above snippet in
> > the
> > setType method. Maybe I'll do some refactoring of the existing code.
> >
> > I noticed also that the code inside:
> >
> > if (!Strings.areEqual(typeName, simpleName) && requiresImport)
> >
> > ...should also be touched to support arrays.
> >
> > BTW, we have the same issue with generic types as well. So I'm looking
> > into
> > them too.
> >
> > Cheers,
> > Ivan
> >
> > P.S. Don't you think that we should have the simple name (e.g. File) in
> > the
> > field declaration instead of the whole type:
> >
> > right now it is:
> >
> > import java.io.File;
> >
> > public class Test {
> >
> > private java.io.File file;
> >
> > }
> >
> > On Mon, Jul 23, 2012 at 5:53 PM, Lincoln Baxter, III
> > <lincolnbaxter(a)gmail.com> wrote:
> >>
> >> Hey Ivan!
> >>
> >> You're correct, the JDT probably doesn't have a convenient method
for
> >> this
> >> (it doesn't have much that is convenient,) but what are your proposed
> >> changes?
> >>
> >> ~Lincoln
> >>
> >> On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov
> >> <ivan.st.ivanov(a)gmail.com> wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> I wonder is it possible to add a field to a JavaClass and to set an
> >>> array
> >>> as its type. The setType(String) method does not support arrays yet
> >>> and I
> >>> don't want to use the other two variants of this method (taking
Class
> >>> and
> >>> JavaResource parameters).
> >>>
> >>> I looked at the mentioned method (setType(String)). And found a
> >>> suitable
> >>> place where I could add the support for arrays. However, I'm afraid
> >>> that
> >>> JDT's AST class does not have a convenient newArray....() method.
> >>>
> >>> Or maybe I'm missing something?
> >>>
> >>> Cheers,
> >>> Ivan
> >>>
> >>> _______________________________________________
> >>> forge-dev mailing list
> >>> forge-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/forge-dev
> >>>
> >>
> >>
> >>
> >> --
> >> Lincoln Baxter, III
> >> http://ocpsoft.org
> >> "Simpler is better."
> >>
> >> _______________________________________________
> >> forge-dev mailing list
> >> forge-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >>
> >
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
5:27 p.m.
Maybe something like:
private boolean fieldNeedsFQN(String typeName)
String simpleName = Types.toSimpleName(typeName);
// This works both with simple as well as with qualified names
Import import = getOrigin().getImport(simpleName);
if (import != null && !import.getQualifiedName().equals(typeName)) {
return true;
}
return false;
}
On Tue, Jul 24, 2012 at 1:14 AM, George Gastaldi <gegastaldi(a)gmail.com>wrote:
Hi Ivan,
Yeah, I have to agree with you, this is something that should be
improved. I also don't like having FQN in field declarations.
But, figuring it out how to avoid name clashes may be harder to
implement than using this strategy.
Regards,
George Gastaldi
2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
> Hi George,
>
> Yes, I realized that. So it's up to us to decide which option we take:
>
> 1) It is safe to have the fully qualified name in the field declarations,
> but it is kinda ugly
> 2) Declaring the fields with non fully qualified names looks natural
(all of
> us use this style), but it may produce class name clashes in one out of
1000
> or more cases. E.g. adding java.util.Date and java.sql.Date to a class.
>
> I don't mind to keep it in the current way. But when I show the generated
> classes to the people, they might get the feeling that something does not
> look like in their IDEs.
>
> Regards,
> Ivan
>
>
> On Tue, Jul 24, 2012 at 12:46 AM, George Gastaldi <gegastaldi(a)gmail.com>
> wrote:
>>
>> Hi Ivan,
>>
>> Using the fully qualified name avoids class name conflicts, so it is
>> much safer to use than to rely on imports only.
>>
>> Regards,
>>
>> George Gastaldi
>>
>> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
>> > Hi Lincoln,
>> >
>> > I'm hacking now a solution. Something like:
>> >
>> > if (Types.isArray(simpleName))
>> > {
>> > Name name = ast.newSimpleName(Types.stripArray(simpleName));
>> > Type typeOfArray = ast.newSimpleType(name);
>> > type = ast.newArrayType(typeNoArray);
>> > }
>> >
>> > I'm just trying to find the most suitable place of the above snippet
in
>> > the
>> > setType method. Maybe I'll do some refactoring of the existing code.
>> >
>> > I noticed also that the code inside:
>> >
>> > if (!Strings.areEqual(typeName, simpleName) &&
requiresImport)
>> >
>> > ...should also be touched to support arrays.
>> >
>> > BTW, we have the same issue with generic types as well. So I'm looking
>> > into
>> > them too.
>> >
>> > Cheers,
>> > Ivan
>> >
>> > P.S. Don't you think that we should have the simple name (e.g. File)
in
>> > the
>> > field declaration instead of the whole type:
>> >
>> > right now it is:
>> >
>> > import java.io.File;
>> >
>> > public class Test {
>> >
>> > private java.io.File file;
>> >
>> > }
>> >
>> > On Mon, Jul 23, 2012 at 5:53 PM, Lincoln Baxter, III
>> > <lincolnbaxter(a)gmail.com> wrote:
>> >>
>> >> Hey Ivan!
>> >>
>> >> You're correct, the JDT probably doesn't have a convenient
method for
>> >> this
>> >> (it doesn't have much that is convenient,) but what are your
proposed
>> >> changes?
>> >>
>> >> ~Lincoln
>> >>
>> >> On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov
>> >> <ivan.st.ivanov(a)gmail.com> wrote:
>> >>>
>> >>> Hi folks,
>> >>>
>> >>> I wonder is it possible to add a field to a JavaClass and to set
an
>> >>> array
>> >>> as its type. The setType(String) method does not support arrays
yet
>> >>> and I
>> >>> don't want to use the other two variants of this method
(taking
Class
>> >>> and
>> >>> JavaResource parameters).
>> >>>
>> >>> I looked at the mentioned method (setType(String)). And found a
>> >>> suitable
>> >>> place where I could add the support for arrays. However, I'm
afraid
>> >>> that
>> >>> JDT's AST class does not have a convenient newArray....()
method.
>> >>>
>> >>> Or maybe I'm missing something?
>> >>>
>> >>> Cheers,
>> >>> Ivan
>> >>>
>> >>> _______________________________________________
>> >>> forge-dev mailing list
>> >>> forge-dev(a)lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/forge-dev
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Lincoln Baxter, III
>> >> http://ocpsoft.org
>> >> "Simpler is better."
>> >>
>> >> _______________________________________________
>> >> forge-dev mailing list
>> >> forge-dev(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > forge-dev mailing list
>> > forge-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>> >
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
5:35 p.m.
Right, that could work.
Fancy a pull request ? Test included please ! :)
2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
Maybe something like:
private boolean fieldNeedsFQN(String typeName)
String simpleName = Types.toSimpleName(typeName);
// This works both with simple as well as with qualified names
Import import = getOrigin().getImport(simpleName);
if (import != null && !import.getQualifiedName().equals(typeName)) {
return true;
}
return false;
}
On Tue, Jul 24, 2012 at 1:14 AM, George Gastaldi <gegastaldi(a)gmail.com>
wrote:
>
> Hi Ivan,
>
> Yeah, I have to agree with you, this is something that should be
> improved. I also don't like having FQN in field declarations.
> But, figuring it out how to avoid name clashes may be harder to
> implement than using this strategy.
>
> Regards,
>
> George Gastaldi
>
> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
> > Hi George,
> >
> > Yes, I realized that. So it's up to us to decide which option we take:
> >
> > 1) It is safe to have the fully qualified name in the field
> > declarations,
> > but it is kinda ugly
> > 2) Declaring the fields with non fully qualified names looks natural
> > (all of
> > us use this style), but it may produce class name clashes in one out of
> > 1000
> > or more cases. E.g. adding java.util.Date and java.sql.Date to a class.
> >
> > I don't mind to keep it in the current way. But when I show the
> > generated
> > classes to the people, they might get the feeling that something does
> > not
> > look like in their IDEs.
> >
> > Regards,
> > Ivan
> >
> >
> > On Tue, Jul 24, 2012 at 12:46 AM, George Gastaldi <gegastaldi(a)gmail.com>
> > wrote:
> >>
> >> Hi Ivan,
> >>
> >> Using the fully qualified name avoids class name conflicts, so it is
> >> much safer to use than to rely on imports only.
> >>
> >> Regards,
> >>
> >> George Gastaldi
> >>
> >> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
> >> > Hi Lincoln,
> >> >
> >> > I'm hacking now a solution. Something like:
> >> >
> >> > if (Types.isArray(simpleName))
> >> > {
> >> > Name name = ast.newSimpleName(Types.stripArray(simpleName));
> >> > Type typeOfArray = ast.newSimpleType(name);
> >> > type = ast.newArrayType(typeNoArray);
> >> > }
> >> >
> >> > I'm just trying to find the most suitable place of the above
snippet
> >> > in
> >> > the
> >> > setType method. Maybe I'll do some refactoring of the existing
code.
> >> >
> >> > I noticed also that the code inside:
> >> >
> >> > if (!Strings.areEqual(typeName, simpleName) &&
requiresImport)
> >> >
> >> > ...should also be touched to support arrays.
> >> >
> >> > BTW, we have the same issue with generic types as well. So I'm
> >> > looking
> >> > into
> >> > them too.
> >> >
> >> > Cheers,
> >> > Ivan
> >> >
> >> > P.S. Don't you think that we should have the simple name (e.g.
File)
> >> > in
> >> > the
> >> > field declaration instead of the whole type:
> >> >
> >> > right now it is:
> >> >
> >> > import java.io.File;
> >> >
> >> > public class Test {
> >> >
> >> > private java.io.File file;
> >> >
> >> > }
> >> >
> >> > On Mon, Jul 23, 2012 at 5:53 PM, Lincoln Baxter, III
> >> > <lincolnbaxter(a)gmail.com> wrote:
> >> >>
> >> >> Hey Ivan!
> >> >>
> >> >> You're correct, the JDT probably doesn't have a convenient
method
> >> >> for
> >> >> this
> >> >> (it doesn't have much that is convenient,) but what are your
> >> >> proposed
> >> >> changes?
> >> >>
> >> >> ~Lincoln
> >> >>
> >> >> On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov
> >> >> <ivan.st.ivanov(a)gmail.com> wrote:
> >> >>>
> >> >>> Hi folks,
> >> >>>
> >> >>> I wonder is it possible to add a field to a JavaClass and to
set an
> >> >>> array
> >> >>> as its type. The setType(String) method does not support arrays
yet
> >> >>> and I
> >> >>> don't want to use the other two variants of this method
(taking
> >> >>> Class
> >> >>> and
> >> >>> JavaResource parameters).
> >> >>>
> >> >>> I looked at the mentioned method (setType(String)). And found
a
> >> >>> suitable
> >> >>> place where I could add the support for arrays. However,
I'm afraid
> >> >>> that
> >> >>> JDT's AST class does not have a convenient newArray....()
method.
> >> >>>
> >> >>> Or maybe I'm missing something?
> >> >>>
> >> >>> Cheers,
> >> >>> Ivan
> >> >>>
> >> >>> _______________________________________________
> >> >>> forge-dev mailing list
> >> >>> forge-dev(a)lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Lincoln Baxter, III
> >> >> http://ocpsoft.org
> >> >> "Simpler is better."
> >> >>
> >> >> _______________________________________________
> >> >> forge-dev mailing list
> >> >> forge-dev(a)lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > forge-dev mailing list
> >> > forge-dev(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >
> >> _______________________________________________
> >> forge-dev mailing list
> >> forge-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> >
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
5:38 p.m.
Sure :-)
But not today, as I'm a bit sleepy (it's nearly 2am here in Bulgaria). :-)
On Tue, Jul 24, 2012 at 1:35 AM, George Gastaldi <gegastaldi(a)gmail.com>wrote:
Right, that could work.
Fancy a pull request ? Test included please ! :)
2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
> Maybe something like:
>
> private boolean fieldNeedsFQN(String typeName)
> String simpleName = Types.toSimpleName(typeName);
> // This works both with simple as well as with qualified names
> Import import = getOrigin().getImport(simpleName);
> if (import != null && !import.getQualifiedName().equals(typeName)) {
> return true;
> }
> return false;
> }
>
> On Tue, Jul 24, 2012 at 1:14 AM, George Gastaldi <gegastaldi(a)gmail.com>
> wrote:
>>
>> Hi Ivan,
>>
>> Yeah, I have to agree with you, this is something that should be
>> improved. I also don't like having FQN in field declarations.
>> But, figuring it out how to avoid name clashes may be harder to
>> implement than using this strategy.
>>
>> Regards,
>>
>> George Gastaldi
>>
>> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
>> > Hi George,
>> >
>> > Yes, I realized that. So it's up to us to decide which option we take:
>> >
>> > 1) It is safe to have the fully qualified name in the field
>> > declarations,
>> > but it is kinda ugly
>> > 2) Declaring the fields with non fully qualified names looks natural
>> > (all of
>> > us use this style), but it may produce class name clashes in one out
of
>> > 1000
>> > or more cases. E.g. adding java.util.Date and java.sql.Date to a
class.
>> >
>> > I don't mind to keep it in the current way. But when I show the
>> > generated
>> > classes to the people, they might get the feeling that something does
>> > not
>> > look like in their IDEs.
>> >
>> > Regards,
>> > Ivan
>> >
>> >
>> > On Tue, Jul 24, 2012 at 12:46 AM, George Gastaldi <
gegastaldi(a)gmail.com>
>> > wrote:
>> >>
>> >> Hi Ivan,
>> >>
>> >> Using the fully qualified name avoids class name conflicts, so it is
>> >> much safer to use than to rely on imports only.
>> >>
>> >> Regards,
>> >>
>> >> George Gastaldi
>> >>
>> >> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
>> >> > Hi Lincoln,
>> >> >
>> >> > I'm hacking now a solution. Something like:
>> >> >
>> >> > if (Types.isArray(simpleName))
>> >> > {
>> >> > Name name = ast.newSimpleName(Types.stripArray(simpleName));
>> >> > Type typeOfArray = ast.newSimpleType(name);
>> >> > type = ast.newArrayType(typeNoArray);
>> >> > }
>> >> >
>> >> > I'm just trying to find the most suitable place of the above
snippet
>> >> > in
>> >> > the
>> >> > setType method. Maybe I'll do some refactoring of the
existing
code.
>> >> >
>> >> > I noticed also that the code inside:
>> >> >
>> >> > if (!Strings.areEqual(typeName, simpleName) &&
requiresImport)
>> >> >
>> >> > ...should also be touched to support arrays.
>> >> >
>> >> > BTW, we have the same issue with generic types as well. So
I'm
>> >> > looking
>> >> > into
>> >> > them too.
>> >> >
>> >> > Cheers,
>> >> > Ivan
>> >> >
>> >> > P.S. Don't you think that we should have the simple name
(e.g.
File)
>> >> > in
>> >> > the
>> >> > field declaration instead of the whole type:
>> >> >
>> >> > right now it is:
>> >> >
>> >> > import java.io.File;
>> >> >
>> >> > public class Test {
>> >> >
>> >> > private java.io.File file;
>> >> >
>> >> > }
>> >> >
>> >> > On Mon, Jul 23, 2012 at 5:53 PM, Lincoln Baxter, III
>> >> > <lincolnbaxter(a)gmail.com> wrote:
>> >> >>
>> >> >> Hey Ivan!
>> >> >>
>> >> >> You're correct, the JDT probably doesn't have a
convenient method
>> >> >> for
>> >> >> this
>> >> >> (it doesn't have much that is convenient,) but what are
your
>> >> >> proposed
>> >> >> changes?
>> >> >>
>> >> >> ~Lincoln
>> >> >>
>> >> >> On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov
>> >> >> <ivan.st.ivanov(a)gmail.com> wrote:
>> >> >>>
>> >> >>> Hi folks,
>> >> >>>
>> >> >>> I wonder is it possible to add a field to a JavaClass and
to set
an
>> >> >>> array
>> >> >>> as its type. The setType(String) method does not support
arrays
yet
>> >> >>> and I
>> >> >>> don't want to use the other two variants of this
method (taking
>> >> >>> Class
>> >> >>> and
>> >> >>> JavaResource parameters).
>> >> >>>
>> >> >>> I looked at the mentioned method (setType(String)). And
found a
>> >> >>> suitable
>> >> >>> place where I could add the support for arrays. However,
I'm
afraid
>> >> >>> that
>> >> >>> JDT's AST class does not have a convenient
newArray....() method.
>> >> >>>
>> >> >>> Or maybe I'm missing something?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Ivan
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> forge-dev mailing list
>> >> >>> forge-dev(a)lists.jboss.org
>> >> >>> https://lists.jboss.org/mailman/listinfo/forge-dev
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Lincoln Baxter, III
>> >> >> http://ocpsoft.org
>> >> >> "Simpler is better."
>> >> >>
>> >> >> _______________________________________________
>> >> >> forge-dev mailing list
>> >> >> forge-dev(a)lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > forge-dev mailing list
>> >> > forge-dev(a)lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
>> >> >
>> >> _______________________________________________
>> >> forge-dev mailing list
>> >> forge-dev(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > forge-dev mailing list
>> > forge-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>> >
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
1:41 a.m.
It's 2:40 am here, so I'll read and comment more fully tomorrow, but Types
should only be fully qualified if there is an existing import that
conflicts with the FQN of the type that was added to the source file.
Hopefully that makes sense :)
~Lincoln
On Mon, Jul 23, 2012 at 6:38 PM, Ivan St. Ivanov
<ivan.st.ivanov(a)gmail.com>wrote:
Sure :-)
But not today, as I'm a bit sleepy (it's nearly 2am here in Bulgaria). :-)
On Tue, Jul 24, 2012 at 1:35 AM, George Gastaldi <gegastaldi(a)gmail.com>wrote:
> Right, that could work.
> Fancy a pull request ? Test included please ! :)
>
> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
> > Maybe something like:
> >
> > private boolean fieldNeedsFQN(String typeName)
> > String simpleName = Types.toSimpleName(typeName);
> > // This works both with simple as well as with qualified names
> > Import import = getOrigin().getImport(simpleName);
> > if (import != null && !import.getQualifiedName().equals(typeName))
{
> > return true;
> > }
> > return false;
> > }
> >
> > On Tue, Jul 24, 2012 at 1:14 AM, George Gastaldi <gegastaldi(a)gmail.com>
> > wrote:
> >>
> >> Hi Ivan,
> >>
> >> Yeah, I have to agree with you, this is something that should be
> >> improved. I also don't like having FQN in field declarations.
> >> But, figuring it out how to avoid name clashes may be harder to
> >> implement than using this strategy.
> >>
> >> Regards,
> >>
> >> George Gastaldi
> >>
> >> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
> >> > Hi George,
> >> >
> >> > Yes, I realized that. So it's up to us to decide which option we
> take:
> >> >
> >> > 1) It is safe to have the fully qualified name in the field
> >> > declarations,
> >> > but it is kinda ugly
> >> > 2) Declaring the fields with non fully qualified names looks natural
> >> > (all of
> >> > us use this style), but it may produce class name clashes in one out
> of
> >> > 1000
> >> > or more cases. E.g. adding java.util.Date and java.sql.Date to a
> class.
> >> >
> >> > I don't mind to keep it in the current way. But when I show the
> >> > generated
> >> > classes to the people, they might get the feeling that something does
> >> > not
> >> > look like in their IDEs.
> >> >
> >> > Regards,
> >> > Ivan
> >> >
> >> >
> >> > On Tue, Jul 24, 2012 at 12:46 AM, George Gastaldi <
> gegastaldi(a)gmail.com>
> >> > wrote:
> >> >>
> >> >> Hi Ivan,
> >> >>
> >> >> Using the fully qualified name avoids class name conflicts, so it
is
> >> >> much safer to use than to rely on imports only.
> >> >>
> >> >> Regards,
> >> >>
> >> >> George Gastaldi
> >> >>
> >> >> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
> >> >> > Hi Lincoln,
> >> >> >
> >> >> > I'm hacking now a solution. Something like:
> >> >> >
> >> >> > if (Types.isArray(simpleName))
> >> >> > {
> >> >> > Name name =
ast.newSimpleName(Types.stripArray(simpleName));
> >> >> > Type typeOfArray = ast.newSimpleType(name);
> >> >> > type = ast.newArrayType(typeNoArray);
> >> >> > }
> >> >> >
> >> >> > I'm just trying to find the most suitable place of the
above
> snippet
> >> >> > in
> >> >> > the
> >> >> > setType method. Maybe I'll do some refactoring of the
existing
> code.
> >> >> >
> >> >> > I noticed also that the code inside:
> >> >> >
> >> >> > if (!Strings.areEqual(typeName, simpleName) &&
> requiresImport)
> >> >> >
> >> >> > ...should also be touched to support arrays.
> >> >> >
> >> >> > BTW, we have the same issue with generic types as well. So
I'm
> >> >> > looking
> >> >> > into
> >> >> > them too.
> >> >> >
> >> >> > Cheers,
> >> >> > Ivan
> >> >> >
> >> >> > P.S. Don't you think that we should have the simple name
(e.g.
> File)
> >> >> > in
> >> >> > the
> >> >> > field declaration instead of the whole type:
> >> >> >
> >> >> > right now it is:
> >> >> >
> >> >> > import java.io.File;
> >> >> >
> >> >> > public class Test {
> >> >> >
> >> >> > private java.io.File file;
> >> >> >
> >> >> > }
> >> >> >
> >> >> > On Mon, Jul 23, 2012 at 5:53 PM, Lincoln Baxter, III
> >> >> > <lincolnbaxter(a)gmail.com> wrote:
> >> >> >>
> >> >> >> Hey Ivan!
> >> >> >>
> >> >> >> You're correct, the JDT probably doesn't have a
convenient method
> >> >> >> for
> >> >> >> this
> >> >> >> (it doesn't have much that is convenient,) but what
are your
> >> >> >> proposed
> >> >> >> changes?
> >> >> >>
> >> >> >> ~Lincoln
> >> >> >>
> >> >> >> On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov
> >> >> >> <ivan.st.ivanov(a)gmail.com> wrote:
> >> >> >>>
> >> >> >>> Hi folks,
> >> >> >>>
> >> >> >>> I wonder is it possible to add a field to a JavaClass
and to
> set an
> >> >> >>> array
> >> >> >>> as its type. The setType(String) method does not
support arrays
> yet
> >> >> >>> and I
> >> >> >>> don't want to use the other two variants of this
method (taking
> >> >> >>> Class
> >> >> >>> and
> >> >> >>> JavaResource parameters).
> >> >> >>>
> >> >> >>> I looked at the mentioned method (setType(String)).
And found a
> >> >> >>> suitable
> >> >> >>> place where I could add the support for arrays.
However, I'm
> afraid
> >> >> >>> that
> >> >> >>> JDT's AST class does not have a convenient
newArray....()
> method.
> >> >> >>>
> >> >> >>> Or maybe I'm missing something?
> >> >> >>>
> >> >> >>> Cheers,
> >> >> >>> Ivan
> >> >> >>>
> >> >> >>> _______________________________________________
> >> >> >>> forge-dev mailing list
> >> >> >>> forge-dev(a)lists.jboss.org
> >> >> >>> https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Lincoln Baxter, III
> >> >> >> http://ocpsoft.org
> >> >> >> "Simpler is better."
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> forge-dev mailing list
> >> >> >> forge-dev(a)lists.jboss.org
> >> >> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >> >>
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > forge-dev mailing list
> >> >> > forge-dev(a)lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >> >
> >> >> _______________________________________________
> >> >> forge-dev mailing list
> >> >> forge-dev(a)lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > forge-dev mailing list
> >> > forge-dev(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >
> >> _______________________________________________
> >> forge-dev mailing list
> >> forge-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> >
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
1:41 a.m.
Otherwise, just use the Simple type.
On Tue, Jul 24, 2012 at 2:41 AM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
It's 2:40 am here, so I'll read and comment more fully
tomorrow, but Types
should only be fully qualified if there is an existing import that
conflicts with the FQN of the type that was added to the source file.
Hopefully that makes sense :)
~Lincoln
On Mon, Jul 23, 2012 at 6:38 PM, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com
> wrote:
> Sure :-)
>
> But not today, as I'm a bit sleepy (it's nearly 2am here in Bulgaria). :-)
>
> On Tue, Jul 24, 2012 at 1:35 AM, George Gastaldi <gegastaldi(a)gmail.com>wrote:
>
>> Right, that could work.
>> Fancy a pull request ? Test included please ! :)
>>
>> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
>> > Maybe something like:
>> >
>> > private boolean fieldNeedsFQN(String typeName)
>> > String simpleName = Types.toSimpleName(typeName);
>> > // This works both with simple as well as with qualified names
>> > Import import = getOrigin().getImport(simpleName);
>> > if (import != null &&
!import.getQualifiedName().equals(typeName))
>> {
>> > return true;
>> > }
>> > return false;
>> > }
>> >
>> > On Tue, Jul 24, 2012 at 1:14 AM, George Gastaldi <gegastaldi(a)gmail.com
>> >
>> > wrote:
>> >>
>> >> Hi Ivan,
>> >>
>> >> Yeah, I have to agree with you, this is something that should be
>> >> improved. I also don't like having FQN in field declarations.
>> >> But, figuring it out how to avoid name clashes may be harder to
>> >> implement than using this strategy.
>> >>
>> >> Regards,
>> >>
>> >> George Gastaldi
>> >>
>> >> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
>> >> > Hi George,
>> >> >
>> >> > Yes, I realized that. So it's up to us to decide which option
we
>> take:
>> >> >
>> >> > 1) It is safe to have the fully qualified name in the field
>> >> > declarations,
>> >> > but it is kinda ugly
>> >> > 2) Declaring the fields with non fully qualified names looks
natural
>> >> > (all of
>> >> > us use this style), but it may produce class name clashes in one
>> out of
>> >> > 1000
>> >> > or more cases. E.g. adding java.util.Date and java.sql.Date to a
>> class.
>> >> >
>> >> > I don't mind to keep it in the current way. But when I show
the
>> >> > generated
>> >> > classes to the people, they might get the feeling that something
>> does
>> >> > not
>> >> > look like in their IDEs.
>> >> >
>> >> > Regards,
>> >> > Ivan
>> >> >
>> >> >
>> >> > On Tue, Jul 24, 2012 at 12:46 AM, George Gastaldi <
>> gegastaldi(a)gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Ivan,
>> >> >>
>> >> >> Using the fully qualified name avoids class name conflicts, so
it
>> is
>> >> >> much safer to use than to rely on imports only.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> George Gastaldi
>> >> >>
>> >> >> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
>> >> >> > Hi Lincoln,
>> >> >> >
>> >> >> > I'm hacking now a solution. Something like:
>> >> >> >
>> >> >> > if (Types.isArray(simpleName))
>> >> >> > {
>> >> >> > Name name =
ast.newSimpleName(Types.stripArray(simpleName));
>> >> >> > Type typeOfArray = ast.newSimpleType(name);
>> >> >> > type = ast.newArrayType(typeNoArray);
>> >> >> > }
>> >> >> >
>> >> >> > I'm just trying to find the most suitable place of the
above
>> snippet
>> >> >> > in
>> >> >> > the
>> >> >> > setType method. Maybe I'll do some refactoring of the
existing
>> code.
>> >> >> >
>> >> >> > I noticed also that the code inside:
>> >> >> >
>> >> >> > if (!Strings.areEqual(typeName, simpleName)
&&
>> requiresImport)
>> >> >> >
>> >> >> > ...should also be touched to support arrays.
>> >> >> >
>> >> >> > BTW, we have the same issue with generic types as well. So
I'm
>> >> >> > looking
>> >> >> > into
>> >> >> > them too.
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Ivan
>> >> >> >
>> >> >> > P.S. Don't you think that we should have the simple
name (e.g.
>> File)
>> >> >> > in
>> >> >> > the
>> >> >> > field declaration instead of the whole type:
>> >> >> >
>> >> >> > right now it is:
>> >> >> >
>> >> >> > import java.io.File;
>> >> >> >
>> >> >> > public class Test {
>> >> >> >
>> >> >> > private java.io.File file;
>> >> >> >
>> >> >> > }
>> >> >> >
>> >> >> > On Mon, Jul 23, 2012 at 5:53 PM, Lincoln Baxter, III
>> >> >> > <lincolnbaxter(a)gmail.com> wrote:
>> >> >> >>
>> >> >> >> Hey Ivan!
>> >> >> >>
>> >> >> >> You're correct, the JDT probably doesn't have
a convenient
>> method
>> >> >> >> for
>> >> >> >> this
>> >> >> >> (it doesn't have much that is convenient,) but
what are your
>> >> >> >> proposed
>> >> >> >> changes?
>> >> >> >>
>> >> >> >> ~Lincoln
>> >> >> >>
>> >> >> >> On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov
>> >> >> >> <ivan.st.ivanov(a)gmail.com> wrote:
>> >> >> >>>
>> >> >> >>> Hi folks,
>> >> >> >>>
>> >> >> >>> I wonder is it possible to add a field to a
JavaClass and to
>> set an
>> >> >> >>> array
>> >> >> >>> as its type. The setType(String) method does not
support
>> arrays yet
>> >> >> >>> and I
>> >> >> >>> don't want to use the other two variants of
this method (taking
>> >> >> >>> Class
>> >> >> >>> and
>> >> >> >>> JavaResource parameters).
>> >> >> >>>
>> >> >> >>> I looked at the mentioned method
(setType(String)). And found a
>> >> >> >>> suitable
>> >> >> >>> place where I could add the support for arrays.
However, I'm
>> afraid
>> >> >> >>> that
>> >> >> >>> JDT's AST class does not have a convenient
newArray....()
>> method.
>> >> >> >>>
>> >> >> >>> Or maybe I'm missing something?
>> >> >> >>>
>> >> >> >>> Cheers,
>> >> >> >>> Ivan
>> >> >> >>>
>> >> >> >>> _______________________________________________
>> >> >> >>> forge-dev mailing list
>> >> >> >>> forge-dev(a)lists.jboss.org
>> >> >> >>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Lincoln Baxter, III
>> >> >> >> http://ocpsoft.org
>> >> >> >> "Simpler is better."
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> forge-dev mailing list
>> >> >> >> forge-dev(a)lists.jboss.org
>> >> >> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > forge-dev mailing list
>> >> >> > forge-dev(a)lists.jboss.org
>> >> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
>> >> >> >
>> >> >> _______________________________________________
>> >> >> forge-dev mailing list
>> >> >> forge-dev(a)lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > forge-dev mailing list
>> >> > forge-dev(a)lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
>> >> >
>> >> _______________________________________________
>> >> forge-dev mailing list
>> >> forge-dev(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > forge-dev mailing list
>> > forge-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>> >
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
4:43 p.m.
Hi guys!
Sorry, maybe I mislead you a bit yesterday. The setType(String) was working
[nearly] as expected: it imports the type and then creates the field with
its simple name. Sorry again!
Now I'm working on making setType(String) support arrays and generics. I
did it for the array, but now I'm hacking the JDT API for adding a
parameterized type.
Cheers,
Ivan
On Tue, Jul 24, 2012 at 9:41 AM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
Otherwise, just use the Simple type.
On Tue, Jul 24, 2012 at 2:41 AM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
> It's 2:40 am here, so I'll read and comment more fully tomorrow, but
> Types should only be fully qualified if there is an existing import that
> conflicts with the FQN of the type that was added to the source file.
> Hopefully that makes sense :)
>
> ~Lincoln
>
>
> On Mon, Jul 23, 2012 at 6:38 PM, Ivan St. Ivanov <
> ivan.st.ivanov(a)gmail.com> wrote:
>
>> Sure :-)
>>
>> But not today, as I'm a bit sleepy (it's nearly 2am here in Bulgaria).
>> :-)
>>
>> On Tue, Jul 24, 2012 at 1:35 AM, George Gastaldi
<gegastaldi(a)gmail.com>wrote:
>>
>>> Right, that could work.
>>> Fancy a pull request ? Test included please ! :)
>>>
>>> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
>>> > Maybe something like:
>>> >
>>> > private boolean fieldNeedsFQN(String typeName)
>>> > String simpleName = Types.toSimpleName(typeName);
>>> > // This works both with simple as well as with qualified names
>>> > Import import = getOrigin().getImport(simpleName);
>>> > if (import != null &&
>>> !import.getQualifiedName().equals(typeName)) {
>>> > return true;
>>> > }
>>> > return false;
>>> > }
>>> >
>>> > On Tue, Jul 24, 2012 at 1:14 AM, George Gastaldi <
>>> gegastaldi(a)gmail.com>
>>> > wrote:
>>> >>
>>> >> Hi Ivan,
>>> >>
>>> >> Yeah, I have to agree with you, this is something that should be
>>> >> improved. I also don't like having FQN in field declarations.
>>> >> But, figuring it out how to avoid name clashes may be harder to
>>> >> implement than using this strategy.
>>> >>
>>> >> Regards,
>>> >>
>>> >> George Gastaldi
>>> >>
>>> >> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com>:
>>> >> > Hi George,
>>> >> >
>>> >> > Yes, I realized that. So it's up to us to decide which
option we
>>> take:
>>> >> >
>>> >> > 1) It is safe to have the fully qualified name in the field
>>> >> > declarations,
>>> >> > but it is kinda ugly
>>> >> > 2) Declaring the fields with non fully qualified names looks
>>> natural
>>> >> > (all of
>>> >> > us use this style), but it may produce class name clashes in
one
>>> out of
>>> >> > 1000
>>> >> > or more cases. E.g. adding java.util.Date and java.sql.Date to
a
>>> class.
>>> >> >
>>> >> > I don't mind to keep it in the current way. But when I show
the
>>> >> > generated
>>> >> > classes to the people, they might get the feeling that
something
>>> does
>>> >> > not
>>> >> > look like in their IDEs.
>>> >> >
>>> >> > Regards,
>>> >> > Ivan
>>> >> >
>>> >> >
>>> >> > On Tue, Jul 24, 2012 at 12:46 AM, George Gastaldi <
>>> gegastaldi(a)gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi Ivan,
>>> >> >>
>>> >> >> Using the fully qualified name avoids class name conflicts,
so it
>>> is
>>> >> >> much safer to use than to rely on imports only.
>>> >> >>
>>> >> >> Regards,
>>> >> >>
>>> >> >> George Gastaldi
>>> >> >>
>>> >> >> 2012/7/23 Ivan St. Ivanov
<ivan.st.ivanov(a)gmail.com>:
>>> >> >> > Hi Lincoln,
>>> >> >> >
>>> >> >> > I'm hacking now a solution. Something like:
>>> >> >> >
>>> >> >> > if (Types.isArray(simpleName))
>>> >> >> > {
>>> >> >> > Name name =
ast.newSimpleName(Types.stripArray(simpleName));
>>> >> >> > Type typeOfArray = ast.newSimpleType(name);
>>> >> >> > type = ast.newArrayType(typeNoArray);
>>> >> >> > }
>>> >> >> >
>>> >> >> > I'm just trying to find the most suitable place of
the above
>>> snippet
>>> >> >> > in
>>> >> >> > the
>>> >> >> > setType method. Maybe I'll do some refactoring of
the existing
>>> code.
>>> >> >> >
>>> >> >> > I noticed also that the code inside:
>>> >> >> >
>>> >> >> > if (!Strings.areEqual(typeName, simpleName)
&&
>>> requiresImport)
>>> >> >> >
>>> >> >> > ...should also be touched to support arrays.
>>> >> >> >
>>> >> >> > BTW, we have the same issue with generic types as
well. So I'm
>>> >> >> > looking
>>> >> >> > into
>>> >> >> > them too.
>>> >> >> >
>>> >> >> > Cheers,
>>> >> >> > Ivan
>>> >> >> >
>>> >> >> > P.S. Don't you think that we should have the
simple name (e.g.
>>> File)
>>> >> >> > in
>>> >> >> > the
>>> >> >> > field declaration instead of the whole type:
>>> >> >> >
>>> >> >> > right now it is:
>>> >> >> >
>>> >> >> > import java.io.File;
>>> >> >> >
>>> >> >> > public class Test {
>>> >> >> >
>>> >> >> > private java.io.File file;
>>> >> >> >
>>> >> >> > }
>>> >> >> >
>>> >> >> > On Mon, Jul 23, 2012 at 5:53 PM, Lincoln Baxter, III
>>> >> >> > <lincolnbaxter(a)gmail.com> wrote:
>>> >> >> >>
>>> >> >> >> Hey Ivan!
>>> >> >> >>
>>> >> >> >> You're correct, the JDT probably doesn't
have a convenient
>>> method
>>> >> >> >> for
>>> >> >> >> this
>>> >> >> >> (it doesn't have much that is convenient,) but
what are your
>>> >> >> >> proposed
>>> >> >> >> changes?
>>> >> >> >>
>>> >> >> >> ~Lincoln
>>> >> >> >>
>>> >> >> >> On Sat, Jul 21, 2012 at 4:04 PM, Ivan St. Ivanov
>>> >> >> >> <ivan.st.ivanov(a)gmail.com> wrote:
>>> >> >> >>>
>>> >> >> >>> Hi folks,
>>> >> >> >>>
>>> >> >> >>> I wonder is it possible to add a field to a
JavaClass and to
>>> set an
>>> >> >> >>> array
>>> >> >> >>> as its type. The setType(String) method does
not support
>>> arrays yet
>>> >> >> >>> and I
>>> >> >> >>> don't want to use the other two variants
of this method
>>> (taking
>>> >> >> >>> Class
>>> >> >> >>> and
>>> >> >> >>> JavaResource parameters).
>>> >> >> >>>
>>> >> >> >>> I looked at the mentioned method
(setType(String)). And found
>>> a
>>> >> >> >>> suitable
>>> >> >> >>> place where I could add the support for
arrays. However, I'm
>>> afraid
>>> >> >> >>> that
>>> >> >> >>> JDT's AST class does not have a convenient
newArray....()
>>> method.
>>> >> >> >>>
>>> >> >> >>> Or maybe I'm missing something?
>>> >> >> >>>
>>> >> >> >>> Cheers,
>>> >> >> >>> Ivan
>>> >> >> >>>
>>> >> >> >>>
_______________________________________________
>>> >> >> >>> forge-dev mailing list
>>> >> >> >>> forge-dev(a)lists.jboss.org
>>> >> >> >>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> Lincoln Baxter, III
>>> >> >> >> http://ocpsoft.org
>>> >> >> >> "Simpler is better."
>>> >> >> >>
>>> >> >> >> _______________________________________________
>>> >> >> >> forge-dev mailing list
>>> >> >> >> forge-dev(a)lists.jboss.org
>>> >> >> >>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >> > _______________________________________________
>>> >> >> > forge-dev mailing list
>>> >> >> > forge-dev(a)lists.jboss.org
>>> >> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >> >> >
>>> >> >> _______________________________________________
>>> >> >> forge-dev mailing list
>>> >> >> forge-dev(a)lists.jboss.org
>>> >> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > forge-dev mailing list
>>> >> > forge-dev(a)lists.jboss.org
>>> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >> >
>>> >> _______________________________________________
>>> >> forge-dev mailing list
>>> >> forge-dev(a)lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > forge-dev mailing list
>>> > forge-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
4314
days inactive
4317
days old
11 comments
3 participants
participants (3)
-
George Gastaldi -
Ivan St. Ivanov -
Lincoln Baxter, III