[forge-dev] Adding a field of array type
Lincoln Baxter, III
lincolnbaxter at gmail.com
Tue Jul 24 02:41:25 EDT 2012
Otherwise, just use the Simple type.
On Tue, Jul 24, 2012 at 2:41 AM, Lincoln Baxter, III <
lincolnbaxter at 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 at 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 at gmail.com>wrote:
>>
>>> Right, that could work.
>>> Fancy a pull request ? Test included please ! :)
>>>
>>> 2012/7/23 Ivan St. Ivanov <ivan.st.ivanov at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
>>> >> >> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >> > _______________________________________________
>>> >> >> > forge-dev mailing list
>>> >> >> > forge-dev at lists.jboss.org
>>> >> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >> >> >
>>> >> >> _______________________________________________
>>> >> >> forge-dev mailing list
>>> >> >> forge-dev at lists.jboss.org
>>> >> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > forge-dev mailing list
>>> >> > forge-dev at lists.jboss.org
>>> >> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >> >
>>> >> _______________________________________________
>>> >> forge-dev mailing list
>>> >> forge-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > forge-dev mailing list
>>> > forge-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/forge-dev
>>> >
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120724/28f9823f/attachment-0001.html
More information about the forge-dev
mailing list