Path: csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: Jan Burse <janburse@fastmail.fm>
Newsgroups: comp.lang.java.programmer
Subject: Re: Good Fowler article on ORM
Date: Sat, 12 May 2012 21:53:37 +0200
Organization: albasani.net
Lines: 78
Message-ID: <jomf41$ef9$1@news.albasani.net>
References: <kDXqr.1107$FL3.615@newsfe11.iad> <vokoq7t9vj5cf68rk9ricd63meejh8r3rk@4ax.com> <joihae$oiv$1@news.albasani.net> <jokg12$jce$1@dont-email.me> <jolcd0$3g7$1@news.albasani.net> <joldlk$gv7$1@dont-email.me> <jolgn9$chj$1@news.albasani.net> <jomcmv$9l6$1@news.albasani.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net nv+RLT5QfRhJJoVGz/Kjx/cYhfubsTNYYrfMjCD9Iib8TqFtvOCZLN2Riqns6LhaTYzJduZMNlK71mNizluDSzxfF4sP3bNiiEZxtufcfj3ebrSSlmz9BIkaDrxGlVGP
NNTP-Posting-Date: Sat, 12 May 2012 19:53:37 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="PsZoomJyTrTIRE9/ixqspnoVBqMeJIw5S2Iwy/FvbePISe8Zw3IezC4S4hgeB8S2WfepAoFrXNWQFCDBwxwDvCdj6lvlHKx6cPT1dVlFl/vBsHshR2Z9EHogyHBj5Otc"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1
In-Reply-To: <jomcmv$9l6$1@news.albasani.net>
Cancel-Lock: sha1:yda4PmG88w3omNUIrCwglo15j18=
Xref: csiph.com comp.lang.java.programmer:14493

Lew schrieb:
> I don't think I get your last paragraph here. What pain? What additional
> classes? Why?

The discussion was about some custom HashMap, call this
class XXX. If one does use inline loops such as:

   for (int i = 0; i<table.length; i++) {
       Entry e = table[i];
       while (e!=null) {
           /* do something */
       }
   }

The one does not need to defined an interator for the
custom HashMap, call this iterator class YYY.

These iterators which implement the interface Iterator
(or Enumerator) are usually not much visible Java collection
classes, since they are realized as inner classes.

But they add to the LOCs and the number of classes:

        With Iterator    Without Iterator
XXX    N + K LOCs       N LOCs
YYY    M LOCs
Total  N + K + M        N

K is for the iterator factories inside the collection
class. Pain = N + K + M - N = K + M.

Since nobody would use class YYY anyway, since XXX
is anyway internal to the whole multi-indexing
framework and not visible by the client of the framework,
its not only a pain but also not a necessity.

 > I'm willing to lay odds that for your use cases
 > the difference made by accessors and mutators is
 > not the low-hanging fruit.

For gambling you can go to Las Vegas, or if you
are up to something more serious, you could educate
yourself.

First of all originally Android didn't have a JIT.
See for example:
http://www.youtube.com/watch?v=ptjedOZEXPM
There might still be devices around without a JIT.

Second for my setter/getter claim you might want
to read this page:
http://developer.android.com/guide/practices/design/performance.html
There is a section about Avoid Internal Getters/Setters.

I copy the essential part for your eyes here:

"In native languages like C++ it's common practice to use getters (e.g. 
i = getCount()) instead of accessing the field directly (i = mCount). 
This is an excellent habit for C++, because the compiler can usually 
inline the access, and if you need to restrict or debug field access you 
can add the code at any time.

On Android, this is a bad idea. Virtual method calls are expensive, much 
more so than instance field lookups. It's reasonable to follow common 
object-oriented programming practices and have getters and setters in 
the public interface, but within a class you should always access fields 
directly.

Without a JIT, direct field access is about 3x faster than invoking a 
trivial getter. With the JIT (where direct field access is as cheap as 
accessing a local), direct field access is about 7x faster than invoking 
a trivial getter. This is true in Froyo, but will improve in the future 
when the JIT inlines getter methods."

Bye