From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,bdcca6db8294fb00 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news.glorb.com!news2.glorb.com!news-xfer.nntp.sonic.net!posts.news.sonic.net!nnrp0.nntp.sonic.net!not-for-mail Newsgroups: comp.lang.ada From: R Tyler Croy Subject: Re: Introducing memcache-ada, a memcached client in Ada References: <4d0f1316$0$23759$14726298@news.sunsite.dk> Reply-To: R Tyler Croy User-Agent: slrn/0.9.9p1 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: 20 Dec 2010 20:16:11 GMT Organization: Sonic.Net NNTP-Posting-Date: 20 Dec 2010 20:16:11 GMT NNTP-Posting-Host: 1eb8a5d5.news.sonic.net X-Trace: DXC=mGFIc=A0j]f X-Complaints-To: abuse@sonic.net Xref: g2news2.google.com comp.lang.ada:17046 Date: 2010-12-20T20:16:11+00:00 List-Id: On 2010-12-20, Jeffrey Carter wrote: > On 2010-12-20 01:43, R Tyler Croy wrote: >> >> I look forward to any comments or suggestions as to the code >> quality/structure. > > I have looked only at the specification, since that's the only part a client > should need to look at. Initial impressions: > > I see a number of declarations in the visible part of the specification that are > not referenced in the visible part nor needed for the client to use the package. > Only things needed in the visible part or needed by the client to use the > package should appear in the visible part. > > [In order of preference, things should be declared > > 1. In the body > 2. In the private part (Is Ada the only language with private parts?) > 3. In the visible part] > > Similarly, context clauses should use "private with" for things only referenced > in the private part. > > The type Flags and the Set_Flags parameters of that type are not documented in > the spec; if possible, they should be. In particular, the effect of the default > value for Set_Flags should be described. > > The meaning of the expiration parameters, and especially of their default > values, should be documented. The default of zero would seem to mean immediate > expirations, which doesn't seem very useful. > > The meaning of the Boolean return values from some of the functions (which also > appear as parameters) is unclear and should be documented. > > Some exceptions appear at the end of the visible part. Presumably some of the > operations may raise these exceptions, but which operations raise which > exceptions, and in what circumstances, is not documented. Since declarations > should appear before they are referenced, the exception declarations should > appear before the comments in which they are referenced. > These are some really good suggestions, thank you for taking the time to look over the protocol and my code I look forward to updating some things tonight after work. :) -- - R. Tyler Croy -------------------------------------- Code: http://github.com/rtyler Chatter: http://twitter.com/agentdero http://identi.ca/dero