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