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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Mon, 13 May 2013 10:23:05 +0200 Organization: Ada @ Home Message-ID: References: <1bfhq7jo34xpi.p8n2vq6yjsea.dlg@40tude.net> <12gn9wvv1gwfk.10ikfju4rzmnj.dlg@40tude.net> <1y21fg5hvajvd.1femngelic1xp.dlg@40tude.net> NNTP-Posting-Host: ll7JxPeHtfBeoFl5nDW1Dg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.15 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:15536 Date: 2013-05-13T10:23:05+02:00 List-Id: Le Mon, 13 May 2013 09:22:24 +0200, Dmitry A. Kazakov = a =C3=A9crit: >> 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 t= hat > 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. 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). Except for the exception which implies a lot of more things, the idea is= = indeed nice, while not universal. To stick with this example, that depen= ds = on the level of the application (it may or may not be aware of possible = = loss of connection), depends on the protocol in use (there may or may no= t = be a way to know if the connection can be restored, if it is loss of if = = the peer closed it), that may be replacing a problem with another (state= = vs delay), and so on. I agree with you (or may not, depending on the concrete case), except wi= th = this: =E2=80=9CThat is not a problem so long this state is not exposed=E2= =80=9D; this = seems to suggest another design is an error and this is an universal = pattern. >> Another limitation in your approach is that the opening and closing o= f >> different files must be strictly nested: if you declare and open file= A, >> then declare and open file B, file B must be closed before file A is >> closed (as long as it all happens in the same task). Such forced >> constraints between the states of different object is often not wante= d. > > You can have a container, e.g. a bag, to handle this. > > Jeffrey's model translates this into the problem of object's scope > (lifetime), which saves time and mental efforts. Each programmer faces= it > on daily basis and has his ready-to-use solutions already. The same: may be an option, however nothing universal with it (ex. may b= e = too much to pull the container concept, or for the second, objects = identities may be important and one object may be opened and closed = multiple times). There is the topic of premature optimizations, there may be as well a = topic about premature decisions (especially an issue if it adds = dependencies or complexity). -- = =E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D [1] =E2=80=9CStructured Programming supports the law of the excluded muddle.= =E2=80=9D [1] [1]: Epigrams on Programming =E2=80=94 Alan J. =E2=80=94 P. Yale Univers= ity