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 Path: border1.nntp.dca3.giganews.com!border2.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Tue, 14 May 2013 10:14:44 +0200 Organization: cbb software GmbH Message-ID: <1ogi7nmzybfl2.1lso8msgvxijq.dlg@40tude.net> References: <1bfhq7jo34xpi.p8n2vq6yjsea.dlg@40tude.net> <12gn9wvv1gwfk.10ikfju4rzmnj.dlg@40tude.net> <1y21fg5hvajvd.1femngelic1xp.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Original-Bytes: 5220 Xref: number.nntp.dca.giganews.com comp.lang.ada:181630 Date: 2013-05-14T10:14:44+02:00 List-Id: On Mon, 13 May 2013 22:20:12 +0300, Niklas Holsti wrote: > On 13-05-13 10:22 , Dmitry A. Kazakov wrote: >> On Mon, 13 May 2013 08:21:14 +0300, Niklas Holsti wrote: >> >>> The point of the example was to illustrate typestate analysis. For this >>> example, with only Open - (Read/Write)* - Close, your approach collapses >>> the example into a trivial one, where adherence to the operation >>> protocol is ensured by the necessity to declare a File_Info object >>> before it can be used. So it would no longer be a useful example. >> >> It is still a useful example of a good software component design. > > Hm. In this thread, I think this example is interesting only if it can > show us alternatives to typestate analysis, giving the same verification > power by other means. I don't think this Open-in-declaration approach > (essentially removing the Open and Close operations from the problem) > applies in the general case, so I don't find it interesting in this thread. It does. The idea is not to expose the state or else split object into smaller ones. >>> Your approach works in some cases, but it is problematic if you cannot >>> initialize the object to an "active" state in its declaration, for >>> example because the "activation" is conditional in some way, or must be >>> delayed. >> >> This is rather a language problem. Most of such cases can be attributed to >> the lack or insufficient constructors. The notorious Ada's problem with >> task components is due to the lack of class-wide constructors, when >> Initialize tries to sit on two chairs struggling to be both a specific and >> a class-wide initialization. > > The initialization step, which is just the first state transition of an > object, is only a small part of the problem for typestate analysis. And the point is that this would probably be bad design. >>> The "activation" must then be done in a statement, and the >>> declaration leaves the object in some inactive initial state. >> >> That is not a problem so long this state is not exposed. The idea is that >> when you have an object which may transit from state to state (e.g. a >> connection object, when the connection can be lost), you should not expose >> this state. > > Even if the state is hidden from the clients, it is present internally, > and must be considered in any analysis of correctness. But not at the client side! >> You better make the object to maintain the state (e.g. by >> making the connection restored by the object automatically) and leave its >> interface free of the state (e.g. an operation on unconnected object would >> block or else raise Busy_Error etc). > > Here "unconnected object" is analogous to "closed file". No. Unconnected object can become connected asynchronously to the client. If the state can be controlled by the client, the object should be designed so that its sate were usable. See Jeffrey's design. If the sate cannot be controlled the object should be responsible in each of its states. I.e. the state should be hidden by the object implementation. > The state exists, even if hidden from clients. Right. The design question is who is to control the state. You want clients to do this. Which is distributed design overhead. > In fact, from the point of view of > typestate analysis, the state is or should be visible, since it affects > the availability or success of operations on the object. This is exactly why I consider this paradigm wrong from the design's POV. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de