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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: operation can be dispatching in only one type Date: Wed, 25 Nov 2015 18:38:51 +0100 Organization: cbb software GmbH Message-ID: <1nf8wc05tjtvf$.1ctjb9hsr0qsp.dlg@40tude.net> References: <04eb6626-644b-4b16-a329-c35659a9fbe2@googlegroups.com> <1ephv5ugr5mib$.9ehadf3dddct$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: Sfz0eNwKWh4Uq03iti+GMw.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 Xref: news.eternal-september.org comp.lang.ada:28542 Date: 2015-11-25T18:38:51+01:00 List-Id: On Wed, 25 Nov 2015 03:22:57 -0800 (PST), Serge Robyns wrote: > However, not all types need to be fully ADT's. They are. If you don't define operations, the compiler does anyway. > Like in my example an > account has a set of properties which may be revealed in the public part. > Why hide them? Nobody asked that. What you call "property" is certainly an operation of the ADT generated by the compiler. If you had type T is record X : ... end record; That would implicitly declare among others the operations to access the member X, i.e. a getter T.X and a setter T.X. > Following your logic, we could have "business" objects > with well know properties, then inherit from it to create implementation > variants for persistent access with getters/setters. Alas, you cannot override operations of built-in interfaces. It is an Ada 83 heritage. > Now all business functions have to use the DOA functions (getters/setters) > to retrieve and update objects. Initially I was hoping to hide the DAO > behind the business object. Now I've to do the two actions in the > business logic: first update T_Account object and then call T_Account.DAO > operations to "retrieve" or "store". After giving it some thought I've > accept this as this enable me to have "control" on the moment for the > updates, commits and roll-bacls to the "store". The object is a proxy to a persistent object. It is OK to update the proxy without committing changes to the persistent counterpart. But note that you still want to extend compiler-generated setters. E.g. for marking the proxy object out-of-sync. Thus when a transaction is getting committed the connection handler would store all updated objects. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de