Mailing-List: contact directmemory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: directmemory-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of simone.tripodi@gmail.com
 designates 209.85.216.47 as permitted sender)
MIME-Version: 1.0
Sender: simone.tripodi@gmail.com
Date: Tue, 14 Feb 2012 22:55:49 +0100
Message-ID: 
 <CAAqLGLM06qb0MtDfJc1h2LCtW92DiusFu2e5cW0W_NXC_hDKnw@mail.gmail.com>
Subject: measures hierarchy
From: Simone Tripodi <simonetripodi@apache.org>
To: directmemory-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8

Hi *,

actually Sizing has the following hierarchy:

 - Sizing
      |
      `- Heap
      |
      `- Memory
      |
      `- Ram
      |
      `- Space

what I see in the current codebase is that extension classes don't add
any semantic, I mean calling {{Ram.inKb( size )}} is exactly the same
of calling {{Space.inKb( size )}}... users can safety exchange them
without any risk to have a compilation failure, so... what is the
advantage of keeping multiple implementations of same methods?

For what I can see, we can happily living with {{Sizing}} - maybe
renaming it to {{Memory}} that sounds more self-explaining...

OTOH, in the case we want to work with more semantic, it would be
different if each method in each class would return a declaring class
object, I mean:

    Ram inKb( size )

instead of

    int inKb( size )

Of course, I assume some methods should be modified to accept the right type...

Thoughts?
Many thanks in advance, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/