ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Usage of star imports
Date Thu, 20 Aug 2015 08:35:18 GMT
I am +1 on the proposed change.

However, I also want to mention that we should try to avoid changing coding
guidelines as much as possible.

D.



On Thu, Aug 20, 2015 at 1:26 AM, Gianfranco Murador <
murador.gianfranco@gmail.com> wrote:

> I was thinking about the same problem , I opened a ticket for a specific
> problem of ambiguity in imports.
> https://issues.apache.org/jira/browse/IGNITE-1253
>
> 2015-08-20 7:17 GMT+02:00 Sergi Vladykin <sergi.vladykin@gmail.com>:
>
> > Agree, I don't like current approach as well and prefer explicit imports.
> > Since they are automatically maintained by IDE it will be easy enough to
> > change this.
> >
> > Sergi
> >
> > 2015-08-20 0:37 GMT+03:00 Raul Kripalani <raulk@apache.org>:
> >
> > > (Found out that org.jsr166 is an internal package in this case).
> > >
> > > *Raúl Kripalani*
> > > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > > Integration specialist
> > > http://about.me/raulkripalani |
> http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> > >
> > > On Wed, Aug 19, 2015 at 10:23 PM, Raul Kripalani <raulk@apache.org>
> > wrote:
> > >
> > > > Hello Igniters,
> > > >
> > > > First of all, congrats to all the committers, former PPMC now PMC
> > members
> > > > and mentors for the project's graduation! Great work, everybody!
> > > >
> > > > I have a question about the Coding Guidelines. Why do they enforce
> star
> > > > imports?
> > > >
> > > > It is considered a bad practice for several reasons:
> > > >
> > > > 1. It pollutes the local namespace, leading to unnecessary name
> > clashes.
> > > >
> > > > 2. Unexpected errors can occur if a class is added the package of a
> > > > dependency we import. Of course, this would be detected at compile
> time
> > > and
> > > > would make the build fail. But it's worrisome that we allow this to
> > occur
> > > > in the first place. Leads to unpredictable builds in case we have
> > > SNAPSHOT
> > > > dependencies.
> > > >
> > > > 3. It makes it absolutely necessary to use a fully-fledged IDE to
> > browse
> > > > the source. People using simpler text editors like Sublime, vi or
> emacs
> > > > will have a hard time unless they use plugins that can process
> pom.xml
> > > and
> > > > add dependencies to classpaths (I haven't even installed these
> plugins
> > –
> > > > and I use Sublime 45% of my working time, as an example).
> > > >
> > > > 4. As an example of the latter, I'm currently working on adding OSGi
> > > > support for ignite-core. I'm trying to figure out which classes
> require
> > > > package org.jsr166; and for this I'm using Sublime, not IntelliJ, for
> > > > lightweight browsing. Found several hits, but because I'm not
> familiar
> > > with
> > > > the contents of the package by heart, I have absolutely no clue which
> > > > classes of that package are being used our source files.
> > > >
> > > > If the reason/alleged benefit is simple convenience/brevity, I'm not
> > > quite
> > > > sure it outweighs all the negatives.
> > > >
> > > > Thanks,
> > > >
> > > > *Raúl Kripalani*
> > > > Apache Camel PMC Member & Committer | Enterprise Architect, Open
> Source
> > > > Integration specialist
> > > > http://about.me/raulkripalani |
> > http://www.linkedin.com/in/raulkripalani
> > > > http://blog.raulkr.net | twitter: @raulvk
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message