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.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, INVALID_MSGID,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,82b509356384c38b X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,82b509356384c38b X-Google-Attributes: gid103376,public From: mbkennel@yahoo.com (Matt Kennel) Subject: Re: READ 1ST: use eiffel for CAM library development? Date: 1998/01/22 Message-ID: #1/1 X-Deja-AN: 318272777 References: Organization: University of California at San Diego Reply-To: mbkennel@yahoo.com Newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1998-01-22T00:00:00+00:00 List-Id: On Wed, 21 Jan 1998 23:48:00 GMT, Shane Miller wrote: : : Question 1: how do you make each list available to a : client programmer without allowing the client programmer : to change the list or the state of a object in the list? You would pass back a type of READ_ONLY_LIST[ READ_ONLY_T] where READ_ONLY_LIST and READ_ONLY_T were an abstract supertypes above the concrete implementation of the list and list element classes, which did not provide public features which modify their data storage. Remember, that's all that C++ 'const' really is---it's a type modifier which takes an existing type and creates one with some 'writing' features removed. It is way uglier than just explicitly using abstract superclasses which perform the same function. : this is important because changing the list could have : a big impact on the rest of the items in the list (eg. : the list is sorted; the list is spatial). so the only : way a client can alter the list is to make another library : call in which the list is changed as a side effect. : : Question 2: the user for a computation needs to obtain : a copy one of the lists. he needs to do this so he can : change the state of an object or two and then update a : result in some part of his program. how can the client : programmer get a copy of the list with a minimum of a : performance hit? There would be a member function: return_copy_of_list with a return value LIST[ READ_WRITABLE_T] where READ_WRITABLE_T would be a type which allowed mutable access. The function would have to decide whether it wanted to provide a shallow or deep copy. :for question 2, we would implement the object : in the list using reference counting and copy-on-write. : so if the user wanted a copy of the short-list but with : big objects, only the objects he *ACTUALLY CHANGED* got : copied; all the others are still have a reference to the : libraries version. same with the long list but with : small objects. in either case only the energy which is : needed is actually expended). No problem. Do the same thing. The 'return_copy_of_list' function would return a predominantly "shallow copy" of LIST[ COPY_ON_WRITE_T ], where the COPY_ON_WRITE_T class presented a similar public interface as T, but implemented the copy-on-write semantics upon mutation. E.g. it had an internal pointer to the shared 'T', but any mutation causes storage for new data to be allocated, and the pointer set to nil, or if you're willing to use RTTI, altered to point to the data storage class COPIED_ON_WRITE_T so shared vs copied objects could be distinguished. No reference count needed, standard GC works. :-- :-------------------------------------------------------------------- :shanem@netcom.com | Remember: know where you're going and then who's :804.673.4966 | going with you. Never get the order mixed up. :-------------------------------------------------------------------- :Beware of the software trap: because I can do x, I should be doing x :-------------------------------------------------------------------- -- * Matthew B. Kennel/Institute for Nonlinear Science, UCSD * * Quoth the X Consortium: "Mechanism Not Policy" * * Translated: "Once ze windows go up, who cares why push MouseDown. That's * not my department!" says Wehrner von Braun.