From kato-spec-return-233-apmail-incubator-kato-spec-archive=incubator.apache.org@incubator.apache.org Thu Sep 10 21:16:51 2009 Return-Path: Delivered-To: apmail-incubator-kato-spec-archive@minotaur.apache.org Received: (qmail 41306 invoked from network); 10 Sep 2009 21:16:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Sep 2009 21:16:51 -0000 Received: (qmail 47533 invoked by uid 500); 10 Sep 2009 21:16:51 -0000 Delivered-To: apmail-incubator-kato-spec-archive@incubator.apache.org Received: (qmail 47498 invoked by uid 500); 10 Sep 2009 21:16:51 -0000 Mailing-List: contact kato-spec-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: kato-spec@incubator.apache.org Delivered-To: mailing list kato-spec@incubator.apache.org Received: (qmail 47488 invoked by uid 99); 10 Sep 2009 21:16:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Sep 2009 21:16:51 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of spoole167@googlemail.com designates 209.85.219.210 as permitted sender) Received: from [209.85.219.210] (HELO mail-ew0-f210.google.com) (209.85.219.210) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Sep 2009 21:16:38 +0000 Received: by ewy6 with SMTP id 6so533378ewy.27 for ; Thu, 10 Sep 2009 14:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=0u6IhbPwpERzhXpjpmxIfHsVTCU30Rgx/4m1aSqwMSo=; b=aKiI6B6Aca/YJjjllUhzUS+PDxoErBAB9MUHhlA0M1edD2MlsieeaJgYo9nTDIUeeT AnewW75d+89gRkTiUTYxjT8RLECTWX7X3WCD7CUPpNWSbMcMG3P3kEEWd73+Aif8X9sy hxjq5V0aSqyZS/HWu10fzXped0eQqHZ+WVimc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vK3L1iAwVZDbs1iFmMY0osxnFPjV7J6Q22fuNord/eOM0JXMY0liUK+AGQrc9xxf7c fgF74Mo0/oWEfj9bu2dnV1CVCD1frQlREcQom7psfISj/wkYzb0CbAw1VQ/aLve4WPRn 28pX3AtuAEnwk67LQEArf71FAnmneyvs4DiOo= MIME-Version: 1.0 Received: by 10.211.139.13 with SMTP id r13mr2239211ebn.64.1252617378424; Thu, 10 Sep 2009 14:16:18 -0700 (PDT) In-Reply-To: <986b4acf0909100803q79be0be4n1bc9769275a27ba5@mail.gmail.com> References: <986b4acf0909100803q79be0be4n1bc9769275a27ba5@mail.gmail.com> Date: Thu, 10 Sep 2009 22:16:18 +0100 Message-ID: Subject: Re: Final version of First Early Draft Review document From: Steve Poole To: kato-spec@incubator.apache.org Content-Type: multipart/alternative; boundary=00504502d186e1671204733fb57d X-Virus-Checked: Checked by ClamAV on apache.org --00504502d186e1671204733fb57d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 10, 2009 at 4:03 PM, Adam Pilkington < pilkington.adam@googlemail.com> wrote: > I'm currently reading through the EDR, so I'll post my comments ad-hoc > as I progress. > > I'm looking at the CorruptData interface and wonder if the > getAddress() method should be renamed so that there isn't a clash with > other getAddress() methods. The reason for this is that if you wanted > to use generics at some point, then when an iterator wants to return a > corrupt object it would do so by returning one that additionally > implemented the CorruptData interface. However this could lead to a > clash e.g. ImageSymbol.getAddress() and CorruptData.getAddress() for > an object which was representing a corrupt ImageSymbol, and care would > need to be taken in order to ensure that you are working with the > correct method. > > Given that CorruptData can be implemented by any object, would it be > better to ensure that it uses unique method/field names to prevent > confusion and increase code clarity ? > I don't really like the idea of CorruptData having any methods other than maybe something to help explain what type it corruption it is. I've been thinking that the methods that exist which allow you to potentially access the "internals" of a object (of any part of our API) should be abstracted out into a separate interface. I'm thinking of methods like getBasePointer() or getImageSections() these methods are useful if the underlying dump has data it can and wants to share - but it possible that the internal information promised by these methods is just not there. I think it would be best to extact those methods that allow peeking inside these objects into a new interface. Then if an implementation can provide the data then it only has to return objects which implement this "peek" interface. That removes the need to force dumps that can't respond sensibly to fake stuff and generally makes the API more consistant. Not sure how clear that is , when I get another moment I'll post a code example. Cheers Steve > - > > 2009/8/21 Steve Poole : > > Hi all, I've just posted the final version of the first EDR to the wiki > > here http://cwiki.apache.org/KATO/jsr326specification.html I'm > going to > > just check that I have everything in order process wise and then I'm > going > > to send that doc to the JCP as our first EDR. > > > > If I've got all the JCP process stuff right then it will take a couple of > > days for it to appear on the JCP website here > > http://jcp.org/en/jsr/detail?id=326 > > > > In theory that is the point where the specification becomes public but > since > > we've always had an open approach that's not true for us. I will be > > expecting comments from the public to appear on this mailing list. > > > > I'll point out again that the EDR is not complete - there are quite a few > > places where we need to resolve questions and expand the descriptions. > > > > Please take a look and comment - or even provide some more words :-) > > > > Cheers > > > > Steve > > > > > > -- > Regards > > Adam Pilkington > --00504502d186e1671204733fb57d--