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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,36a29c2860aff686 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!z9g2000yqz.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Properties Date: Sun, 28 Nov 2010 13:22:01 -0800 (PST) Organization: http://groups.google.com Message-ID: <3e9dfa01-6975-401d-999d-7cf87e926fb3@z9g2000yqz.googlegroups.com> References: <3b84c8e7-1a51-4a7c-9646-119f1fc51478@s4g2000yql.googlegroups.com> <4cf24d13$0$6985$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: 174.28.198.93 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1290979321 10098 127.0.0.1 (28 Nov 2010 21:22:01 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 28 Nov 2010 21:22:01 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: z9g2000yqz.googlegroups.com; posting-host=174.28.198.93; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:16661 Date: 2010-11-28T13:22:01-08:00 List-Id: On Nov 28, 5:37=A0am, Georg Bauhaus wrote: > On 11/28/10 4:21 AM, Shark8 wrote: > > > I would like to submit a proposal for future Ada development; namely > > "Properties." The purpose of this thread is to: 1) present the ideas > > in general; 2) bounce ideas for the syntax off of fellow Ada users; 3) > > work on presenting ideas to others; and =A04) obtain the information to > > submit the proposal. > > Most of the suggestions seem to be about writing subprograms for > access to a single object component. > Just like @property in Objective-C is a shorthand for subprograms > generated by tools. (Or C#'s or Python's sugar equivalent.) > > As such, an ASIS enabled Ada processor should be able to write > these without too much effort. I've heard mention of ASIS somewhere, but was uninterested at the time; perhaps I should take a look at it. > > 1 - What is the benefit other than not having to write subprograms? > > Big win in standardized access to internal data of composite > types? =A0 I believe so. The example of a Clock {in C/C++} could include validating the input (i.e. only executing the assignment when "((input >=3D 0) || (input < 60))", though this is a poor example on an Ada forum since we can just subtype out something with "Range 0..59") The Delphi variant of Object Pascal allows the 'delegation' of interface-implementation [or components thereof] to properties/fields of some object. While not strictly necessary it does allow you to avoid the clutter of writing numerous usually-one-line wrappers to "redispatch" the incoming calls to that interface. There was a problem I came across several months ago, while writing a PostScript interpreter, where as per the PLRM PostScript's string- objects didn't contain the string data themselves, but pointers to an object that did. (Not just strings, but arrays/procedures as well, this allows a subarray-object [say of the first to second-to-last components] to be a more constricted view of the "superarray" & any changes to its items impacts those of its parent.) I ended up using an access to the 'data-object' in my array-objects which were, in turn, referenced in the data object with the intention of having it so that when the reference-list reached zero [in the data-object] the object could "kill-itself." I don't remember if I got it to work absolutely as intended, it was a side project that has been put on hold while I finish my degree, though I do remember having to use 'Unchecked_Access in the messy construct that I thought at the time may have been alleviated with properties (esp array-properties). It probably would have looked something like this: Type String_Data_Object( String_Data : Access String ) is Limited Tagged; --Forward declared. Type PS_String( Data_Object : Access String_Data_Object ) is New PostScript_Object with record Start, Stop : Positive; -- String'First/'Last equiv. The_String : Separate String; end record; For PS_String.The_String.Read Use Data_Object.String_Data.All( Start..Stop ); For PS_String.The_String.Write Use Data_Object.String_Data.All( Start..Stop ); Type Reference_List is Array(Positive Range <>) of PS_String; Type String_Data_Object( String_Data : Access String ) is Limited Tagged Record References : Access Reference_List; end record; Function Make_String( Input : String_Data_Object; Start_Index, Stop_Index : Positive ) Return PS_String; -- Creates the string and adds its ref to the ref list. Hrm, maybe I didn't choose the design* as well as I could have, though I was trying to follow the PLRM, but I think you can see what I was trying for, no? *What's missing is a vector/list/map that holds String_Data_Object objects and removes the entry when its reference list reaches zero. > 2 - What if a property of an object needs to refer to two or more > of its components? > > Say, a property's public view perhaps being much better presented > as a Point rather than as forcing two Coordinate properties (even > though Coordinates may have been chosen for internal representation > in a record). That's kinda easy: -- for referring to multiple fields. Type Point is Record X, Y : Integer End Record; Type Point_3D is X, Y, Z : Integer; Parallel_Projected : Separate Point; For Parallel_Projected.X'Read Use X; For Parallel_Projected.Y'Read Use Y; For Parallel_Projected.X'Write Use X; For Parallel_Projected.Y'Write Use Y; end record; -- for referring to calculated fields Package Geometry.Point is Type Point is Record X, Y : Integer End Record; Type Angle Measure is mod 360; -- or some other appropriate representation. Type Point_3D is Radius : Positive; Theta, Phi : Angle_Measure; Parallel_Projected : Separate Point; end record; private Function Get_X( Input : Point_3D ) Return Integer; Procedure Set_X( Input : in out Point_3D; Value : Integer ); --same getter/setter for y. For Parallel_Projected.X'Read Use Get_X; For Parallel_Projected.Y'Read Use Get_Y; For Parallel_Projected.X'Write Use Set_X; For Parallel_Projected.Y'Write Use Set_Y; -- OR PERHAPS Function Get_XY( Input : Point_3D ) Return Point; Procedure Set_XY( Input : in out Point_3D; Value : Point ); --same getter/setter for y. For Parallel_Projected'Read Use Get_XY; For Parallel_Projected'Write Use Set_XY; end Geometry.Point; > 3 - Is there anything in properties that helps with order of > component access? =A0(Just an idea.) I'm not sure I know what you mean by this... do you mean the order as in how Ada automatically orders the internals of a record when piping them to a stream? > As an alternative, I'd suggest an option to remove definitions > of full views of types from the specs. Hm, I'm not sure I see what use that would be. I see the usefulness of allowing additions to enumerations, supertypes if you will, but I also see how horrible it would be to implement them (especially while trying to maintain type safety).