incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ichiro Furusato <ichiro.furus...@gmail.com>
Subject Re: Switching to different bracing style?
Date Sat, 20 Jul 2013 22:17:23 GMT
All I'm doing is replicating the existing objects and instantiation order
by capturing that configuration in an XML file, which replaces, in two
parts, the module configuration and the redeclarations in
jspwiki.properties using identical syntax files. Nothing more. A dependency
manager would be great but then we're heading into the complexity of
Spring, which is lovely and golden but extremely heavyweight, especially
for a wiki. But I don't want to get into a religious discussion with Spring
advocates since we're already in a religious discussion with syntax
advocates.

One thing I have always liked about JSPWiki is its simplicity. I'm actually
trying to simplify (or at least organise) the bootstrap code, not make it
more complicated. If you have any ideas on how to actually accomplish such
a dependency manager without making life more complicated for either the
team programmers or those hacking the code I'm all ears.

Ichiro


On Sun, Jul 21, 2013 at 2:53 AM, Janne Jalkanen <Janne.Jalkanen@ecyrd.com>wrote:

>
> It sounds to me like you're reinventing Spring here.
>
> The initialization order is very tricky, yes.  A better solution would be
> to have a dependency manager (you could declare the dependencies using
> annotations) for example, and then autodiscover the components from the
> class path. XML is just doing manually stuff that should be done
> automatically anyway.
>
> /Janne
>
> On Jul 20, 2013, at 16:18 , Ichiro Furusato <ichiro.furusato@gmail.com>
> wrote:
>
> > Well, what I'm doing right now is pretty drastic. I don't in the end know
> > what's going to happen to this but I continue to move forward.
> >
> > As a progress report, I've so far begun to gradually replace some of the
> > managers with interfaces, built the EntityManager that acts like a
> > bootstrap loader and creates all of the managers from an XML
> configuration
> > file, then provides Map-style access to them (so that all of the getter
> > methods in WikiEngine could be removed). Instantiation of managers is now
> > happening within the EntityManager rather than within the WikiEngine.
> I've
> > managed to do the first five managers (in instantiation order), but I'm
> > noting that the order in which things are instantiated and initialised is
> > in the future going to get a bit tricky, so if everything fails my
> fallback
> > is to let the WikiEngine request the managers from the EntityManager
> using
> > the existing instantiation/initialisation order via local variables,
> > providing access only via the EntityManager once everything is up and
> > running.
> >
> > Not sure that makes sense written down but my tests are passing.
> >
> > Changing the coding convention to "Style C" is relatively easy within
> > Eclipse: just select the code you want formatted and choose
> Source:Format,
> > then go in and make any minor adjustments. With all due respect, I wish I
> > agreed with your idea of a readable convention -- I frankly don't find
> the
> > long-and-drawn-out vertical of the Avalon style easy to read at all since
> > even with a reasonable size screen it's about twice as many lines as the
> > Eclipse/Sun standard. But I likewise respect that each of us has norms
> that
> > we've grown used to. I didn't bring the subject up and I think computers
> > telling us what to do (e.g. Sonar) is regrettable, but I would like this
> > resolved so I don't spend too much time formatting and reformatting the
> > code I'm working on. I've so far touched probably two dozen files and I
> > don't want to spend hours trying to match Style B. Getting to Style C
> takes
> > seconds since (as I mentioned above) it's roughly the default in Eclipse.
> >
> > And frankly, I'm not myself all *that* fussed about what the convention
> is
> > but recognise that it's better to be consistent across a project. I'd
> just
> > rather have this resolved.
> >
> > This reminds me of a two line aphorism a friend and I wrote (each one
> line)
> > on a post-it during a meeting:
> >
> >    Code is poetry
> >    Machines don't care
> >
> > With that in mind I'm going back to coding...
> >
> > Ichiro
> >
> >
> > On Sat, Jul 20, 2013 at 11:28 PM, Janne Jalkanen
> > <Janne.Jalkanen@ecyrd.com>wrote:
> >
> >>
> >> BTW, changing the coding convention also means that anyone maintaining
> any
> >> sort of a patch against the current codebase will  need to do a complete
> >> rebase.  Which is why I would advise against doing anything so drastic
> >> except during major releases (which can be expected to break backwards
> >> compatibility anyway).
> >>
> >> /Janne
> >>
> >> On Jul 20, 2013, at 13:32 , Ichiro Furusato <ichiro.furusato@gmail.com>
> >> wrote:
> >>
> >>> Hi Janne,
> >>>
> >>> I've looked around the Apache site and unfortunately can find no
> ASF-wide
> >>> coding conventions. It seems that ASF has never had a consistent set of
> >>> conventions across its many projects, with some choosing an Avalon-like
> >>> style for braces to avoid the K&R style (with all other syntax
> following
> >>> the Sun standard). Other projects adopted other styles. There are many
> to
> >>> choose from: Ambler, Lea, ESA (yes, the European Space Agency). Given
> no
> >>> one "standard" is without flaws in someone's eyes this is not entirely
> >>> surprising. While I don't like every bit of it, the one benefit of the
> >> Sun
> >>> standard is that it is by far the most widely known and practiced, if
> we
> >>> aren't too strict in interpretation.
> >>>
> >>> I do note one thing clearly expressed on the JSPWikiCodingStandard
> page:
> >> no
> >>> one seemed remotely in agreement about what constitutes "increased
> >>> readability". It seems what one person thought readable others thought
> >> not
> >>> so readable.
> >>>
> >>> A point you made was that once anyone had checked code into the JSPWiki
> >>> project it was no longer the domain of the original programmer but
> became
> >>> "common code". By the same token, code checked into the Apache JSPWiki
> >>> project is now the domain of the ASF. Since historically it seems that
> >> each
> >>> ASF team has chosen its own coding conventions, developers should
> >> therefore
> >>> follow whatever conventions are chosen for the project by the project
> >> team,
> >>> which I guess is the question before us.
> >>>
> >>> That is, unless someone from ASF has some guidance.
> >>>
> >>> Ichiro
> >>>
> >>> On Sat, Jul 20, 2013 at 6:47 PM, Janne Jalkanen <
> >> Janne.Jalkanen@ecyrd.com>wrote:
> >>>
> >>>>
> >>>> Reasoning for style "B", aka K&R is here:
> >>>> http://ecyrd.com/JSPWiki/wiki/JSPWikiCodingStandard
> >>>>
> >>>> I do believe Sun made a mistake going for not aligning the braces -
my
> >>>> experience is that keeping braces on the same line significantly
> >> increases
> >>>> code readability and works better in multi-line conditionals.
> >>>>
> >>>> /Janne
> >>>>
> >>>> On Jul 20, 2013, at 06:26 , Ichiro Furusato <
> ichiro.furusato@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I'd much prefer Style C as that's the "Sun standard", as you note
> used
> >> in
> >>>>> many Apache projects, and the default style of Eclipse's Format
> >> command,
> >>>>> which means that it's easy to auto-format an existing file to match
> the
> >>>> Sun
> >>>>> standard. Style B is IMO a bit ridiculous -- it extends the logic
of
> a
> >>>>> class vertically across so many lines that it becomes actually hard
> to
> >>>> read
> >>>>> and the only benefit seems to be increasing the count of lines for
> >> those
> >>>>> who think that's a benefit. But rather than be ambiguous about it,
> I'd
> >>>>> suggest we simply reference the actual style of "Style B" in
> JSPWiki's
> >>>>> documentation:
> >>>>>
> >>>>>  Code Conventions for the Java Programming Language
> >>>>>  http://www.oracle.com/technetwork/java/codeconv-138413.html (home
> >>>> page)
> >>>>>
> >>>>>
> >>>>
> >>
> http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html(web
> >>>>> TOC)
> >>>>>
> >> http://www.oracle.com/technetwork/java/codeconventions-150003.pdf(PDF)
> >>>>>
> >>>>> I'm not sure where Style B came from in the JSPWiki project, as
the
> Sun
> >>>>> standard has been around for a very long time.
> >>>>>
> >>>>> FWIW, all of the code for the Neocortext project (which uses JSPWiki
> >> as a
> >>>>> component) is roughly in the Sun standard (without being anal about
> >> it),
> >>>>> and I'd much prefer to not have to reformat the code for Style B
in
> >> order
> >>>>> to submit any portions of it, such as plugins, etc.
> >>>>>
> >>>>> So while I don't have a vote, +1 for Style C.
> >>>>>
> >>>>> Ichiro
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sat, Jul 20, 2013 at 9:35 AM, Glen Mazza <glen.mazza@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>>> Hi Team, the next Sonar complaint, and there's a significant
500 of
> >> them
> >>>>>> within JSPWiki, is that we're not using braces for single-line
> >>>> if/while/for
> >>>>>> loops.  I know for CXF braces are always required, and I suspect
the
> >>>>>> majority of Apache projects today also disallow them, so the
> >>>> requirement is
> >>>>>> not unreasonable.  Fixing them is not the problem, what *is*
the
> >>>> problem is
> >>>>>> our older-fashioned bracing system, i.e., instead of switching
from
> >> this
> >>>>>>
> >>>>>> Style A:
> >>>>>>
> >>>>>> if (a > b)
> >>>>>> c = 10;
> >>>>>> else if (d > e)
> >>>>>> f = 20;
> >>>>>>
> >>>>>> to this (the bracing system JSPWiki presently uses):
> >>>>>>
> >>>>>> Style B:
> >>>>>>
> >>>>>> if (a > b)
> >>>>>> {
> >>>>>> c = 10;
> >>>>>> }
> >>>>>> else if (d > e)
> >>>>>> {
> >>>>>> f = 20;
> >>>>>> }
> >>>>>>
> >>>>>> I'd like to be doing this instead:
> >>>>>>
> >>>>>> Style C:
> >>>>>>
> >>>>>> if (a > b) {
> >>>>>> c = 10;
> >>>>>> } else if (d > e) {
> >>>>>> f = 20;
> >>>>>> }
> >>>>>>
> >>>>>> I've checked five major open source projects -- Style C is all
they
> >> use:
> >>>>>>
> >>>>>> CXF -
> http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/http/**
> >>>>>> src/main/java/org/apache/cxf/**transport/https/**
> >>>>>> CertConstraintsFeature.java?**revision=828758&view=markup<
> >>>>
> >>
> http://svn.apache.org/viewvc/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/https/CertConstraintsFeature.java?revision=828758&view=markup
> >>>>>
> >>>>>>
> >>>>>> Camel -
> >> http://svn.apache.org/viewvc/**camel/trunk/components/camel-**
> >>>>>> atom/src/main/java/org/apache/**camel/component/atom/**
> >>>>>> AtomUtils.java?revision=**1190212&view=markup<
> >>>>
> >>
> http://svn.apache.org/viewvc/camel/trunk/components/camel-atom/src/main/java/org/apache/camel/component/atom/AtomUtils.java?revision=1190212&view=markup
> >>>>>
> >>>>>>
> >>>>>> Tomcat -
> >> http://svn.apache.org/viewvc/**tomcat/trunk/java/org/apache/**
> >>>>>> catalina/filters/FilterBase.**java?revision=1189413&view=**markup<
> >>>>
> >>
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java?revision=1189413&view=markup
> >>>>>
> >>>>>>
> >>>>>> Hadoop -
> http://svn.apache.org/viewvc/**hadoop/common/trunk/hadoop-**
> >>>>>> mapreduce-project/hadoop-**mapreduce-client/hadoop-**
> >>>>>>
> mapreduce-client-common/src/**main/java/org/apache/hadoop/**mapred/**
> >>>>>> LocalDistributedCacheManager.**java?revision=1466196&view=**markup<
> >>>>
> >>
> http://svn.apache.org/viewvc/hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-common/src/main/java/org/apache/hadoop/mapred/LocalDistributedCacheManager.java?revision=1466196&view=markup
> >>>>>
> >>>>>>
> >>>>>> Spring Framework:
> >> https://github.com/**SpringSource/spring-framework/**
> >>>>>> blob/master/spring-jdbc/src/**main/java/org/springframework/**
> >>>>>> jdbc/object/SqlFunction.java<
> >>>>
> >>
> https://github.com/SpringSource/spring-framework/blob/master/spring-jdbc/src/main/java/org/springframework/jdbc/object/SqlFunction.java
> >>>>>
> >>>>>>
> >>>>>> Style B might be OK for projects that still allow Style A, but
it
> >> makes
> >>>>>> the code too bloated once Style A is disallowed.  I don't think
> we'll
> >> be
> >>>>>> able to attract many committers sticking with Style B anymore.
> >>>> Basically,
> >>>>>> to avoid the busywork of converting Style B to Style C, we'll
allow
> >>>> either
> >>>>>> in our source code but with the expectation that more and more
code
> >>>> will be
> >>>>>> adopting Style C as time moves on, how does that sound?  (Or,
do we
> >>>> want to
> >>>>>> continue with allowing Style A and Style B?--we're welcome to
ignore
> >>>> Sonar
> >>>>>> on this.)
> >>>>>>
> >>>>>> Regards,
> >>>>>> Glen
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>

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