incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: Final version of First Early Draft Review document
Date Thu, 10 Sep 2009 21:16:18 GMT
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 <spoole167@googlemail.com>:
> > 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message