From: "Roger C. Soares" <rogersoares@intelinet.com.br>
To: Robin Rosenberg <robin.rosenberg@dewire.com>
Cc: git@vger.kernel.org
Subject: Re: [EGIT PATCH] Comment private modifier to improve performace.
Date: Sun, 03 Feb 2008 17:46:56 -0200 [thread overview]
Message-ID: <47A61A30.3000904@intelinet.com.br> (raw)
In-Reply-To: <200802030201.10971.robin.rosenberg@dewire.com>
Robin Rosenberg escreveu:
>
> I'm not fully convinced this is the right way after all. Good
> performance is obviously good, but so is good encapsulation.
> I've sometimes tried changing things like this even in pieces
> of code that I really thought it should matter, but not been able
> to measure any real improvemen even with performance measurment tools.
>
> Obviously seeing that warning is annoying so maybe we should just set it to
> ignore or exclude it from the project settings (if that is possible). The
> only project where I think it might make a difference is the jgit part because
> that is where we optimize and that is where I experimented with visibility
> changes. In the Eclipse part we need to encapsulate more, partly because
> Eclipse is less understood by the current authors than Java in general.
> Encapsulation means encapsulating bad coding and bad design that comes
> from lack of understanding of the framework we are working within.
>
>
Ok, so some more points for your consideration:
. I saw this /* private */ notation on eclipse code and found it
interesting.
. I won't bother measuaring any single case to make sure it is not
impacting performance under some circunstance, so resolving those
warnings puts me in the safe area. On the other hand, I think it is a
lot easier to tell if a patch is breaking encapsulation in a bad way
just by reviewing it, which is something that is already done.
Especially if it has the private modifier commented out. Someone can
even do a script to uncomment them and verify that it still builds
without errors.
. The ui part isn't supposed to be reused by other projects, so I think
encapsulation there is less important than for jgit. But even so, the
default modifier (or package-private) is good enough for encapsulation.
Other projects shouldn't write code in the the same packages from jgit,
if they do so they know that they are using internal things and they can
run into problems in the future.
That said, I'm ok with your patch too. I think the important is to
choose one so we stop mixing things, for consistency's sake.
[]s,
Roger.
next prev parent reply other threads:[~2008-02-03 19:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-02 2:23 [EGIT PATCH] Comment private modifier to improve performace Roger C. Soares
2008-02-03 1:01 ` Robin Rosenberg
2008-02-03 2:26 ` Robin Rosenberg
2008-02-03 20:03 ` Roger C. Soares
2008-02-03 22:14 ` Robin Rosenberg
2008-02-03 19:46 ` Roger C. Soares [this message]
2008-02-03 22:25 ` Robin Rosenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47A61A30.3000904@intelinet.com.br \
--to=rogersoares@intelinet.com.br \
--cc=git@vger.kernel.org \
--cc=robin.rosenberg@dewire.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).