Return-Path: 
 <user-return-764-apmail-accumulo-user-archive=accumulo.apache.org@accumulo.apache.org>
X-Original-To: apmail-accumulo-user-archive@www.apache.org
Delivered-To: apmail-accumulo-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id AAD85C63E
	for <apmail-accumulo-user-archive@www.apache.org>;
 Thu, 17 May 2012 14:39:39 +0000 (UTC)
Received: (qmail 69019 invoked by uid 500); 17 May 2012 14:39:39 -0000
Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org
Received: (qmail 68994 invoked by uid 500); 17 May 2012 14:39:39 -0000
Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@accumulo.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@accumulo.apache.org>
List-Post: <mailto:user@accumulo.apache.org>
List-Id: <user.accumulo.apache.org>
Reply-To: user@accumulo.apache.org
Delivered-To: mailing list user@accumulo.apache.org
Received: (qmail 68986 invoked by uid 99); 17 May 2012 14:39:39 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 May 2012 14:39:39 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [206.112.75.239] (HELO iron-u-b-out.osis.gov) (206.112.75.239)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 May 2012 14:39:32 +0000
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: 
 AsQEADoNtU+sEAbx/2dsb2JhbABEsziBD4IVAQEEAX4LCwQHOyITBR0HEogJvA+LE4VXA5V6k0U
X-IronPort-AV: E=Sophos;i="4.75,610,1330923600";
   d="scan'208";a="9097570"
Received: from ghost-a.center.osis.gov (HELO mail-pz0-f41.google.com)
 ([172.16.6.241])
  by iron-u-b-in.osis.gov with ESMTP/TLS/RC4-MD5; 17 May 2012 10:37:39 -0400
Received: by dakp5 with SMTP id p5so2725625dak.0
        for <user@accumulo.apache.org>; Thu, 17 May 2012 07:39:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.222.74 with SMTP id qk10mr14719260pbc.67.1337265548615;
 Thu, 17 May 2012 07:39:08 -0700 (PDT)
Received: by 10.68.44.106 with HTTP; Thu, 17 May 2012 07:39:08 -0700 (PDT)
In-Reply-To: 
 <1168806777.69976.1337264602665.JavaMail.root@linzimmb03o.imo.intelink.gov>
References: 
 <1168806777.69976.1337264602665.JavaMail.root@linzimmb03o.imo.intelink.gov>
Date: Thu, 17 May 2012 10:39:08 -0400
Message-ID: 
 <CAPMpPc5DA2L2rd=t1cwydLP-7d1iPLg8UKhCcjHdnLrzny4T7g@mail.gmail.com>
Subject: Re: Scanner and BatchScanner on equal footing.
From: Adam Fuchs <adam.p.fuchs@ugov.gov>
To: user@accumulo.apache.org, john.armstrong@ccri.com
Content-Type: multipart/alternative; boundary=047d7b2edf07fee04504c03c6567

--047d7b2edf07fee04504c03c6567
Content-Type: text/plain; charset=ISO-8859-1

John,

As of Accumulo 1.4.0, ScannerBase implements Iterable<Entry<Key,Value>>.
1.3.x and earlier did not. However, I'm glad to hear that my java generics
hack worked!

Cheers,
Adam


On Thu, May 17, 2012 at 10:23 AM, John Armstrong <jrja@ccri.com> wrote:

> Hi, everybody!
>
> As I mentioned to a few people at the meeting last Wednesday, I've been
> wondering why Scanner and BatchScanner have no common Iterable parent. The
> use case is one where I have a method that I give a Scanner or a
> BatchScanner, twiddle some of the scan settings, then use in a foreach loop
> or something to get data out.  Sometimes I want to use a Scanner, and
> sometimes I want to use a BatchScanner, depending on the size of the data,
> but I'm writing the exact same code for each.
>
> Adam's suggestion for this use of Java generics does work:
>
> public <SCANNER extends ScannerBase & Iterable<Map.Entry<Key, Value>>>
> ReturnType doStuffWithScanner(SCANNER scanner, OtherArgsType otherArgs)
>
> but it still feels sort of hacky.
>
> A common abstract parent below ScannerBase and above both Scanner and
> BatchScanner which declared itself to implement Iterable<Map.Entry<Key,
> Value>> would fix this without having to write a single line of actual
> code.  Not a big deal, but makes the client code look nicer.
>

--047d7b2edf07fee04504c03c6567
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

John,<div><br></div><div>As of Accumulo 1.4.0, ScannerBase implements Itera=
ble&lt;Entry&lt;Key,Value&gt;&gt;. 1.3.x and earlier did not. However, I&#3=
9;m glad to hear that my java generics hack worked!</div><div><br></div>
<div>Cheers,</div><div>Adam</div><div><br><br><div class=3D"gmail_quote">On=
 Thu, May 17, 2012 at 10:23 AM, John Armstrong <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:jrja@ccri.com" target=3D"_blank">jrja@ccri.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi, everybody!<br>
<br>
As I mentioned to a few people at the meeting last Wednesday, I&#39;ve been=
 wondering why Scanner and BatchScanner have no common Iterable parent. The=
 use case is one where I have a method that I give a Scanner or a BatchScan=
ner, twiddle some of the scan settings, then use in a foreach loop or somet=
hing to get data out. =A0Sometimes I want to use a Scanner, and sometimes I=
 want to use a BatchScanner, depending on the size of the data, but I&#39;m=
 writing the exact same code for each.<br>

<br>
Adam&#39;s suggestion for this use of Java generics does work:<br>
<br>
public &lt;SCANNER extends ScannerBase &amp; Iterable&lt;Map.Entry&lt;Key, =
Value&gt;&gt;&gt; ReturnType doStuffWithScanner(SCANNER scanner, OtherArgsT=
ype otherArgs)<br>
<br>
but it still feels sort of hacky.<br>
<br>
A common abstract parent below ScannerBase and above both Scanner and Batch=
Scanner which declared itself to implement Iterable&lt;Map.Entry&lt;Key, Va=
lue&gt;&gt; would fix this without having to write a single line of actual =
code. =A0Not a big deal, but makes the client code look nicer.<br>

</blockquote></div><br></div>

--047d7b2edf07fee04504c03c6567--