* Properties @ 2010-11-28 3:21 Shark8 2010-11-28 8:15 ` Properties Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 94+ messages in thread From: Shark8 @ 2010-11-28 3:21 UTC (permalink / raw) 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 4) obtain the information to submit the proposal. 1 -- Properties Properties, as used here, are a typed member elements of either an object or an interface displayed publicly which may be read-only, write-only, or read-write and which may rename another member element or a procedure/function. In the case of interfaces they can greatly reduce the number of public entities as all getters and setters may be hidden from the public view and be 'collapsed' into reads and writes [respectively] to the corresponding property. 2 -- Syntax Proposal Part 1 -- Declaring a property I propose reusing the SEPARATE keyword to mark properties. Example: Type Button is tagged record Text : Separate Access String; end record; Part 2 -- Specifying readability and writability For declaring whether a property is read-only, write-only, or read- write {The unreadable/unwritable state is useless and should be excluded.} I propose using read-write as the default and specifying read-only or write only via attributes "Readable" and/or "Writable". Example: For Property_Name'Writable Use False; and For Property_Name'Readable Use False; If we default both Readable and Writable to true and allow only one to be declared to be false then we achieve size-optimization in the code for the common case of read-write and prohibit the unreadable/ unwritable properties. Part 3 -- Specifying procedures or fields I propose expanding/overloading the 'Read and 'Write attributes onto the particular property of some type to specify its Example: Package Time is SubType Hour is Natural Range 0..23; SubType Minute is Natural 0..59; Type Clock is tagged record Internal_Time : record --- Some implementation/OS dependent time Date : Integer; M : Minute; --- For some reason minutes are stored separately on this os. end record; H : Separate Hour; M : Separate Minute; End record; Private Function Get_Hour( Object : In Clock ) Return Hour; Function Get_Minute( Object : In Clock ) Return Minute; Procedure Set_Hour( Object : In Out Clock; Value : In Hour ); Procedure Set_Minute( Object : In Out Clock; Value : In Minute ); For Clock.H'Read use Get_Hour; For Clock.H'Write use Set_Hour; For Clock.M'Read use Internal_Time.M; For Clock.M'Write use Internal_Time.M; End Time; Part 4 -- Arrays I propose that properties of an array-type should, when aliasing a function or procedure, should require the forms of: Function Get_Property_Value( Input : In Array_Type; Index_1 : in Array_Index1_Type ) Return Array_Element_Type; Procedure Set_Property_Value( Input : In Array_Type; Index_1 : in Array_Index1_Type; Value In Array_Element_Type ); In the case of multidimensional arrays we would expand the parameter- list accordingly, i.e. two dimensions, for getting, would yield a function of the form: Function Get_Property_Value( Input : In Array_Type; Index_1 : in Array_Index1_Type; Index_2 : In Array_Index2_Type ) Return Array_Element_Type; Part 5 -- Public properties and private fields Currently it is possible to hide the internals of a publicly used type by forward-declaring the type in the public section of a specification and completing the type in the private section.; in order to maintain this ability, yet allow properties to be publicly accessed I propose the use of the keywords SEPARATE & RECORD to allow the following: Package GUIs is Type Button is tagged separate record Top, Left, Height, Width : Separate Natural; --- Only properties are allowed to be declared here end record; Private Type Button is Tagged record Caption : String; On_Click : Procedure( Item : In Out Button ); -- ... end record; --... End GUIs; ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-28 3:21 Properties Shark8 @ 2010-11-28 8:15 ` Dmitry A. Kazakov 2010-11-28 19:43 ` Properties Shark8 2010-11-28 12:37 ` Properties Georg Bauhaus 2010-11-30 1:49 ` Properties Randy Brukardt 2 siblings, 1 reply; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-11-28 8:15 UTC (permalink / raw) On Sat, 27 Nov 2010 19:21:55 -0800 (PST), Shark8 wrote: > I would like to submit a proposal for future Ada development; namely > "Properties." Instead of properties I would prefer a full abstraction of record, array, access, numeric types. E.g. you declare something as a record of certain members and privately implement it as another record with other members or as anything you like providing operations to read/write the publicly declared members. I think it is a more simple and more natural to Ada model than properties. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-28 8:15 ` Properties Dmitry A. Kazakov @ 2010-11-28 19:43 ` Shark8 2010-11-29 8:34 ` Properties Dmitry A. Kazakov 0 siblings, 1 reply; 94+ messages in thread From: Shark8 @ 2010-11-28 19:43 UTC (permalink / raw) On Nov 28, 1:15 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Sat, 27 Nov 2010 19:21:55 -0800 (PST), Shark8 wrote: > > I would like to submit a proposal for future Ada development; namely > > "Properties." > > Instead of properties I would prefer a full abstraction of record, array, > access, numeric types. E.g. you declare something as a record of certain > members and privately implement it as another record with other members or > as anything you like providing operations to read/write the publicly > declared members. I think it is a more simple and more natural to Ada model > than properties. > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de I'm not sure I see the difference between properties and your "full- abstraction"; that is to say, aren't properties merely a way of implementing that sort of abstraction (though with the additional option of being read-only or write-only)? Couldn't we have something similar to Type Something is record S : String_Property; end record; --private or body Default_State : Constant String:= "ANGRY KITTEN"; Stateful_Data : Not Null Access String:= New String'(Default_State); For Something.S'Read Use Stateful_Data.All; Procedure Set_Data( Input : In String ) is begin if Input = "PLAYFUL KITTEN" OR Input = "RABID KITTEN" OR Input = "ANGRY KITTEN" OR Input = "DEAD KITTEN" then Stateful_Data := New String'( Input ); end if; end Set_Data; For Something.S'Write use Set_Data; Or am I completely misunderstanding your intent? Also, do you have a possible syntax for these abstractions? {it may help me fully-understand your position.} ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-28 19:43 ` Properties Shark8 @ 2010-11-29 8:34 ` Dmitry A. Kazakov 2010-12-01 18:15 ` Properties Shark8 0 siblings, 1 reply; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-11-29 8:34 UTC (permalink / raw) On Sun, 28 Nov 2010 11:43:12 -0800 (PST), Shark8 wrote: > On Nov 28, 1:15�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> On Sat, 27 Nov 2010 19:21:55 -0800 (PST), Shark8 wrote: >>> I would like to submit a proposal for future Ada development; namely >>> "Properties." >> >> Instead of properties I would prefer a full abstraction of record, array, >> access, numeric types. E.g. you declare something as a record of certain >> members and privately implement it as another record with other members or >> as anything you like providing operations to read/write the publicly >> declared members. I think it is a more simple and more natural to Ada model >> than properties. > > I'm not sure I see the difference between properties and your "full- > abstraction"; that is to say, aren't properties merely a way of > implementing that sort of abstraction (though with the additional > option of being read-only or write-only)? You want to expose something as a property, I want to hide the implementation making the clients think of the thing in the terms I defined. > Couldn't we have something similar to > > Type Something is record > S : String_Property; > end record; type Something is private record S : String; end record; or type Properly_Designed_Unbounded_String is private array (Positive range <>) of Character; > Or am I completely misunderstanding your intent? > Also, do you have a possible syntax for these abstractions? {it may > help me fully-understand your position.} I would use the word "private" to indicate that the implementation follows in the private part, e.g. type Impossible_In_Ada is private array (Positive range <>) of T'Class; private type Impossible_In_Ada is record ... -- The type is implemented as a record type end record; ... -- Overriding of the array interface operations required Furthermore, I want record, array, access, number be interfaces. I.e. you should be able to hang, for example, a record view on any type you wanted: type S is new T and record Foo : String end record with ...; Note it is not an extension of S with a new member. It is adding an interface making S appear to have the component Foo. The physical implementation might ibe overriding the primitive operation ".Foo" (getter/setter), or indeed an extension (implementation of a component by a component). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-29 8:34 ` Properties Dmitry A. Kazakov @ 2010-12-01 18:15 ` Shark8 0 siblings, 0 replies; 94+ messages in thread From: Shark8 @ 2010-12-01 18:15 UTC (permalink / raw) On Nov 29, 1:34 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Sun, 28 Nov 2010 11:43:12 -0800 (PST), Shark8 wrote: > > On Nov 28, 1:15 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > > wrote: > >> On Sat, 27 Nov 2010 19:21:55 -0800 (PST), Shark8 wrote: > >>> I would like to submit a proposal for future Ada development; namely > >>> "Properties." > > >> Instead of properties I would prefer a full abstraction of record, array, > >> access, numeric types. E.g. you declare something as a record of certain > >> members and privately implement it as another record with other members or > >> as anything you like providing operations to read/write the publicly > >> declared members. I think it is a more simple and more natural to Ada model > >> than properties. > > > I'm not sure I see the difference between properties and your "full- > > abstraction"; that is to say, aren't properties merely a way of > > implementing that sort of abstraction (though with the additional > > option of being read-only or write-only)? > > You want to expose something as a property, I want to hide the > implementation making the clients think of the thing in the terms I > defined. > > > Couldn't we have something similar to > > > Type Something is record > > S : String_Property; > > end record; > > type Something is private record > S : String; > end record; > > or > > type Properly_Designed_Unbounded_String is > private array (Positive range <>) of Character; > > > Or am I completely misunderstanding your intent? > > Also, do you have a possible syntax for these abstractions? {it may > > help me fully-understand your position.} > > I would use the word "private" to indicate that the implementation follows > in the private part, e.g. > > type Impossible_In_Ada is private array (Positive range <>) of T'Class; > private > type Impossible_In_Ada is record > ... -- The type is implemented as a record type > end record; > ... -- Overriding of the array interface operations required > > Furthermore, I want record, array, access, number be interfaces. I.e. you > should be able to hang, for example, a record view on any type you wanted: > > type S is new T and record Foo : String end record with ...; > > Note it is not an extension of S with a new member. It is adding an > interface making S appear to have the component Foo. The physical > implementation might ibe overriding the primitive operation ".Foo" > (getter/setter), or indeed an extension (implementation of a component by a > component). [I think] I see! (I had to re-read it several times to get what you are saying, and didn't want to post a reply until I did.) It seems to me that your idea and mine are actually quite similar; applying your proposal to internal components of a record virtually yields my idea. (At least to a great degree.) ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-28 3:21 Properties Shark8 2010-11-28 8:15 ` Properties Dmitry A. Kazakov @ 2010-11-28 12:37 ` Georg Bauhaus 2010-11-28 21:22 ` Properties Shark8 2010-12-01 19:52 ` Properties Martin Krischik 2010-11-30 1:49 ` Properties Randy Brukardt 2 siblings, 2 replies; 94+ messages in thread From: Georg Bauhaus @ 2010-11-28 12:37 UTC (permalink / raw) 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 4) 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. 1 - What is the benefit other than not having to write subprograms? Big win in standardized access to internal data of composite types? Or if that is: you can write additional code on assignment to a component, yes, I can do that now, too, with not much more effort. 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). 3 - Is there anything in properties that helps with order of component access? (Just an idea.) If Dmitry prefers giving the programmer control over basic language features such as defining what record and array should mean (within certain linguistic constraints), I'd prefer the removal of get/set centric programming altogether: I'm always the one to clean up after the practicalitists who just read and assign record components all across landscapes of objects, using get/set cotton candy. As an alternative, I'd suggest an option to remove definitions of full views of types from the specs. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-28 12:37 ` Properties Georg Bauhaus @ 2010-11-28 21:22 ` Shark8 2010-11-29 16:54 ` Properties Georg Bauhaus 2010-12-01 19:52 ` Properties Martin Krischik 1 sibling, 1 reply; 94+ messages in thread From: Shark8 @ 2010-11-28 21:22 UTC (permalink / raw) On Nov 28, 5:37 am, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de> 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 4) 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? I believe so. The example of a Clock {in C/C++} could include validating the input (i.e. only executing the assignment when "((input >= 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? (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). ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-28 21:22 ` Properties Shark8 @ 2010-11-29 16:54 ` Georg Bauhaus 0 siblings, 0 replies; 94+ messages in thread From: Georg Bauhaus @ 2010-11-29 16:54 UTC (permalink / raw) On 28.11.10 22:22, Shark8 wrote: > 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 ); To the extend I have understood the approach, you can do this with current Ada. Just make The_String aware of its surroundings (not sure I got the String_Data_Object involved as should): type PS_String; type PostScript_String (Referred : access PS_String; Capacity : Positive) is record Data : String (1 .. Capacity); end record; type PS_String( Data_Object : access String_Data_Object; Capacity : Positive) is limited new PostScript_Object with record Start, Stop : Positive; -- String'First/'Last equiv. The_String : PostScript_String (PS_String'Access, Capacity); end record; Then you can define a user defined 'Write attribute for PostScript_String that does use Start and Stop from PS_String to select a range from the string's data: procedure Write_PostScript_String (Stream : access Ada.Streams.Root_Stream_Type'Class; Object : PostScript_String) is Link : PS_String renames Object.Referred.all; -- the surroundings begin String'Write(Stream, Object.Data (Link.Start .. Link.Stop)); end Write_PostScript_String; >> 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. I think I meant the other way around, as in the Get_XY example: > Type Point is Record > X, Y : Integer > End Record; > > Type Point_3D is > X, Y, Z : Integer; > Parallel_Projected : Separate Point; For Parallel_Projected'Read Use ???; > end record; Suppose clients of your private Point_3D should be able to see a property whose computation (result is Point) involves both components X and Y under the hood. Call it the Shadow property, maybe. More generally, I might have type R is private; function Spatial_Needs (Item : R) return Area_N; private type R is record X1, X2, ..., Xm : Distance; Y1, Y2, ..., Yn : Something; ... end record; Spatial_Needs is computed from X1, X2, X5, X12, and Z3 to Z6. Will standardized properties help provide for this? >> 3 - Is there anything in properties that helps with order of >> component access? (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? Something new, and probably not simple: the type's operations can be called in a specific order only. For example, do not call property p3 before both p1 and p2 have been set. >> 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. Somewhat like the pointer-to-implementation approach. The full type definition is in the body of a package (or in some representation part of a package which is separate from both the spec and the body), for example. Every read/write of one or more components is done through some primitive operation. A user of the type has no idea what the component parts of an object might be. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-28 12:37 ` Properties Georg Bauhaus 2010-11-28 21:22 ` Properties Shark8 @ 2010-12-01 19:52 ` Martin Krischik 2010-12-01 23:24 ` Properties Georg Bauhaus 2010-12-01 23:31 ` Properties Georg Bauhaus 1 sibling, 2 replies; 94+ messages in thread From: Martin Krischik @ 2010-12-01 19:52 UTC (permalink / raw) Am 28.11.2010, 13:37 Uhr, schrieb Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>: > As such, an ASIS enabled Ada processor should be able to write > these without too much effort. Not from a readability point. The argument for properties is that they don't clutter your code. Imagine that when 'Image, 'Value etc. pp where purposed your solution was choosen and code generator would actually add the code for those functions into source. Would that not look hyper ugly. On the other hand that "for Some_Type'Image use" was not added is a real shame. Martin -- Martin Krischik mailto://krischik@users.sourceforge.net https://sourceforge.net/users/krischik ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 19:52 ` Properties Martin Krischik @ 2010-12-01 23:24 ` Georg Bauhaus 2010-12-05 16:15 ` (placepo) Properties Martin Krischik 2010-12-01 23:31 ` Properties Georg Bauhaus 1 sibling, 1 reply; 94+ messages in thread From: Georg Bauhaus @ 2010-12-01 23:24 UTC (permalink / raw) On 12/1/10 8:52 PM, Martin Krischik wrote: > Am 28.11.2010, 13:37 Uhr, schrieb Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>: > >> As such, an ASIS enabled Ada processor should be able to write >> these without too much effort. > > Not from a readability point. The argument for properties is that they don't clutter your code. Imagine that when 'Image, 'Value etc. pp where purposed your solution was choosen and code generator would actually add the code for those functions into source. Would that not look hyper ugly. I don't see how "automatic" get/set subprograms offer software engineering advantage, even when they are terse and semi-implicit and purport to avoid repetitive clutter. It's the desire for the structural clutter that get/set style really is that I find worrisome. I'd like to mention an alternative language design idea by Jeffrey Kingston for contrast with get/set style for record components. Whenever you invoke an operation of an object, you create a new object. Observe the programs resulting from get/set style. If they are working, aren't they typically hiding spaghetti coding, and privacy intrusion? There certainly are ways of justifying programs in spite of these qualities. One is the post hoc fallacy: "The get/set feature works, since this program works. Therefore, to choose the get/set approach was right." If the post hoc fallacy helps you as a person to get along, fine. If the post hoc fallacy helps bring customers to Ada, that's fine for the vendors, I'd say. Is it fine, though, with those companies in industry needing to maintain software in order to stay competitive? There is an everyone-does-it argument in favor of get/set. I list some use cases. Which ones do I miss? - array like access to data structures. The low level style thinking shines through. Sometimes just right. Worth a language change? - GUI field updates Forms have not really become "smarter", though, after 30 years of writing form input logic. (Oh, I see! If we did the software engineering thing and use good algorithms instead of record component assignments bridled by get/set, still à la FORTRAN 66, we will not make any more money by writing the same programs over and over. The old ones still work... O.K., that's a point.) - data base objects For building a layer on top of relational records, OK. For quick and dirty database scripting it might be enough to update some field in some view (or table) through some setter. As a design guide, get/set let me understand the many reports about data bases whose handling requires intimate knowledge of the details of every program and of every table. - ... OK, I'm biased as I'm usually the one who cleans up after those who think that getting and setting is the best software design principle. Anyway, one can always add get/set to Ada since that eases the transition from the other languages who have added get/set in very recent years, too. And exclude get/set from SPARK for the more critical programs. ~ ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: (placepo) Properties 2010-12-01 23:24 ` Properties Georg Bauhaus @ 2010-12-05 16:15 ` Martin Krischik 2010-12-06 23:24 ` Shark8 0 siblings, 1 reply; 94+ messages in thread From: Martin Krischik @ 2010-12-05 16:15 UTC (permalink / raw) Am 02.12.2010, 00:24 Uhr, schrieb Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>: > I don't see how "automatic" get/set subprograms offer > software engineering advantage, even when they are terse > and semi-implicit and purport to avoid repetitive clutter. Actually they don't. Not if you can't replace the automated get/set with a user defined function. Especially for set this is important as set should check the value and notify observers of the change. I see far to many mutators which neglect this. And get should protect the value from outside changes by by either returning the value as constant or by coping the value. But especially in Java I often wonder why accessors and mutators are used at all. For example in Scala where accessors and mutators are automaticly generated (without get and set prefix as Scala is functional [1]) this has come back to haunt the language as it becomes very complicated to create rich accessors and mutators. Ok, one thing is left: properties can be overridden. For example a abstract property can be defined in an interface. Martin [1] Which makes me wonder: The set and get prefix are not needed in Ada or Java - so why not do without them? -- Martin Krischik mailto://krischik@users.sourceforge.net https://sourceforge.net/users/krischik ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: (placepo) Properties 2010-12-05 16:15 ` (placepo) Properties Martin Krischik @ 2010-12-06 23:24 ` Shark8 0 siblings, 0 replies; 94+ messages in thread From: Shark8 @ 2010-12-06 23:24 UTC (permalink / raw) On Dec 5, 9:15 am, "Martin Krischik" <krisc...@users.sourceforge.net> wrote: > Am 02.12.2010, 00:24 Uhr, schrieb Georg Bauhaus > <rm-host.bauh...@maps.futureapps.de>: > > > I don't see how "automatic" get/set subprograms offer > > software engineering advantage, even when they are terse > > and semi-implicit and purport to avoid repetitive clutter. > > Actually they don't. Not if you can't replace the automated get/set with a > user defined function. Especially for set this is important as set should > check the value and notify observers of the change. I see far to many > mutators which neglect this. And get should protect the value from outside > changes by by either returning the value as constant or by coping the > value. But especially in Java I often wonder why accessors and mutators > are used at all. > > For example in Scala where accessors and mutators are automaticly > generated (without get and set prefix as Scala is functional [1]) this has > come back to haunt the language as it becomes very complicated to create > rich accessors and mutators. > > Ok, one thing is left: properties can be overridden. For example a > abstract property can be defined in an interface. > > Martin > > [1] Which makes me wonder: The set and get prefix are not needed in Ada or > Java - so why not do without them? > -- > Martin Krischik > mailto://krisc...@users.sourceforge.nethttps://sourceforge.net/users/krischik I agree that setters SHOULD ensure that the values they change [to] are valid; that was the main purpose of them! ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 19:52 ` Properties Martin Krischik 2010-12-01 23:24 ` Properties Georg Bauhaus @ 2010-12-01 23:31 ` Georg Bauhaus 1 sibling, 0 replies; 94+ messages in thread From: Georg Bauhaus @ 2010-12-01 23:31 UTC (permalink / raw) On 12/1/10 8:52 PM, Martin Krischik wrote: > On the other hand that "for Some_Type'Image use" was not added is a real shame. A type based 'Image is not enough. Different contexts will require different kinds of 'Image. We need a way to pass context to a user defined 'Image in order to adapt the string to where it is shown. A simple procedure bound to the type doesn't seem a sufficiently flexible abstraction. The image of an object is best created from information about the object, not by the object, IMHO. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-28 3:21 Properties Shark8 2010-11-28 8:15 ` Properties Dmitry A. Kazakov 2010-11-28 12:37 ` Properties Georg Bauhaus @ 2010-11-30 1:49 ` Randy Brukardt 2010-11-30 16:58 ` Properties Charmed Snark 2 siblings, 1 reply; 94+ messages in thread From: Randy Brukardt @ 2010-11-30 1:49 UTC (permalink / raw) "Shark8" <onewingedshark@gmail.com> wrote in message news:3b84c8e7-1a51-4a7c-9646-119f1fc51478@s4g2000yql.googlegroups.com... >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 4) obtain the information to > submit the proposal. My initial reaction is that you have a solution in search of a problem. That always happens when someone presents their whiz-bang new feature first instead of explaining in detail what the problem with current Ada is. (Don't worry, it's happened to all of us at some point or another.) So, if you want this to be taken seriously, you need to explain the problem in detail and then show how your proposal fixes/improves the problem. Note that the ARG in general is looking for problems that are occurring in real code, and much less for solutions to those problems -- we're plenty creative in that regard! We've occassionally talked about the need to have more flexibility for components (the missing "constant" components come up once in a while), but I think it would be helpful to have more compelling examples of problems with the current facilities. Randy. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-30 1:49 ` Properties Randy Brukardt @ 2010-11-30 16:58 ` Charmed Snark 2010-11-30 17:22 ` Properties Dmitry A. Kazakov 0 siblings, 1 reply; 94+ messages in thread From: Charmed Snark @ 2010-11-30 16:58 UTC (permalink / raw) Randy Brukardt expounded in news:id1l6f$2v8$1@munin.nbi.dk: .. > Note that the ARG in general is looking for problems that > are occurring in real code, and much less for solutions to > those problems -- we're plenty creative in that regard! > We've occassionally talked about the need to have more > flexibility for components (the missing "constant" > components come up once in a while), but I think it would > be helpful to have more compelling examples of problems > with the current facilities. > > Randy. It always worries me a bit to see so many requests for new features. I am sure the ARG is doing a good job safe guarding against feature creep, but it always worries me to see so much pressure in that direction. IMO, the language is complex enough without introducing new features. My own personal preference is to simply perfect what Ada is now, rather than adding blocks of new functionality. Of course, that "line" between "feature" and "fix" is not always black and white. Just my $0.02 worth Canadian. Snark. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-30 16:58 ` Properties Charmed Snark @ 2010-11-30 17:22 ` Dmitry A. Kazakov 2010-11-30 20:27 ` Properties Warren 0 siblings, 1 reply; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-11-30 17:22 UTC (permalink / raw) On Tue, 30 Nov 2010 16:58:03 +0000 (UTC), Charmed Snark wrote: > It always worries me a bit to see so many requests for new > features. I am sure the ARG is doing a good job safe guarding > against feature creep, but it always worries me to see so much > pressure in that direction. Yes, because there are serious problems with using Ada. The wider Ada use is, more requests come. > IMO, the language is complex > enough without introducing new features. It became complex because wrong features were adopted without reviewing the language core for real problems. Ada could be much more simpler if it stopped its drift in a wrong direction (actually multiple wrong directions at once). The main problem is that ARG considers individual features having no strategic plan of Ada evolution. Only Ada 95 had a recognizable plan behind it. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-30 17:22 ` Properties Dmitry A. Kazakov @ 2010-11-30 20:27 ` Warren 2010-12-01 8:39 ` Properties Dmitry A. Kazakov 0 siblings, 1 reply; 94+ messages in thread From: Warren @ 2010-11-30 20:27 UTC (permalink / raw) Dmitry A. Kazakov expounded in news:vkz3nbgxubt1$.11vfo4rwuzegd.dlg@40tude.net: > On Tue, 30 Nov 2010 16:58:03 +0000 (UTC), Warren > wrote: >> IMO, the language is complex >> enough without introducing new features. > > It became complex because wrong features were adopted > without reviewing the language core for real problems. In fairness to those who participated, it is not trivial to forsee all of those "real problems". There was no doubt, no total agreement either for each standard. > Ada > could be much more simpler if it stopped its drift in a > wrong direction (actually multiple wrong directions at > once). That was my thinking with the "new features" (multiple new directions). Many new features seem to be addressing conveniences or to include something from other languages, but in an Ada sense. > The main problem is that ARG considers individual features > having no strategic plan of Ada evolution. Only Ada 95 had > a recognizable plan behind it. That is probably not totally fair. It is very good that they continually evaluate for improvements, rather than just allow the language to become stale. I just hope that they don't get too liberal in the new language features department. Where I do like seeing "new features" is in the standard library support. Whatever you can leverage in std libraries, shortens your routine development time and testing. It also makes Ada more out-of-the-box friendly for routine applications. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-11-30 20:27 ` Properties Warren @ 2010-12-01 8:39 ` Dmitry A. Kazakov 2010-12-01 15:21 ` Properties Warren 0 siblings, 1 reply; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-01 8:39 UTC (permalink / raw) On Tue, 30 Nov 2010 20:27:12 +0000 (UTC), Warren wrote: > Dmitry A. Kazakov expounded in > news:vkz3nbgxubt1$.11vfo4rwuzegd.dlg@40tude.net: > >> On Tue, 30 Nov 2010 16:58:03 +0000 (UTC), Warren >> wrote: > >>> IMO, the language is complex >>> enough without introducing new features. >> >> It became complex because wrong features were adopted >> without reviewing the language core for real problems. > > In fairness to those who participated, it is not trivial to > forsee all of those "real problems". There was no doubt, no > total agreement either for each standard. Yes, but when faced a "real problem," people usually agree. Many features introduced in recent times address rather virtual problems. >> The main problem is that ARG considers individual features >> having no strategic plan of Ada evolution. Only Ada 95 had >> a recognizable plan behind it. > > That is probably not totally fair. It is very good that they > continually evaluate for improvements, rather than just allow > the language to become stale. I don't object that. The point is that the criterion for adopting a feature should not have been "it is too difficult," or "nobody asked for this." There should be a master plan of what language we want Ada to become. Ada 95 had a clear idea of bringing in OO in a safe, properly typed way, not compromising performance. That was a great success, IMO. > I just hope that they don't get > too liberal in the new language features department. Absolutely. My dream were for them to review the existing features and rework the language core in order to unify them, making the language more regular. > Where I do like seeing "new features" is in the standard > library support. Whatever you can leverage in std libraries, > shortens your routine development time and testing. It also > makes Ada more out-of-the-box friendly for routine > applications. That is true, but there is a danger that the language deficiencies would influence the library design. We have an awful string processing library because there is no class of string types. The container library based on generics does not support array views. We will never be able to create a standard GUI library (on the Ada level of safety and usability, I mean), because types, tasks, protected objects don't play good with each other, etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 8:39 ` Properties Dmitry A. Kazakov @ 2010-12-01 15:21 ` Warren 2010-12-01 15:59 ` Properties Dmitry A. Kazakov 0 siblings, 1 reply; 94+ messages in thread From: Warren @ 2010-12-01 15:21 UTC (permalink / raw) Dmitry A. Kazakov expounded in news:4pnv7nl4cdui$.1n28i7lqk4mek$.dlg@40tude.net: > On Tue, 30 Nov 2010 20:27:12 +0000 (UTC), Warren wrote: > We have an > awful string processing library because there is no class > of string types. I think I have to agree there. It just seems like a heavy interface with this emphasis on character maps. > The container library based on generics > does not support array views. There are definitely some challenges there. Some perhaps worth pursuing more. > We will never be able to > create a standard GUI library (on the Ada level of safety > and usability, I mean), because types, tasks, protected > objects don't play good with each other, etc. That would seem to be the acid test. I haven't looked at GtkAda in years, but my early version opinion of it was that it seemed too much like bending a C library into Ada terms. A library designed in Ada from the ground up, would be better. Part of the difficulty is that something like a GUI takes so much effort to develop. To get one developed to a "standard level" would likely require some level of sponsorship. Especially if you want to also attempt to make it platform neutral. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 15:21 ` Properties Warren @ 2010-12-01 15:59 ` Dmitry A. Kazakov 2010-12-01 16:20 ` Properties Warren 2010-12-03 5:53 ` Properties Shark8 0 siblings, 2 replies; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-01 15:59 UTC (permalink / raw) On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote: > I haven't looked at > GtkAda in years, but my early version opinion of it was that > it seemed too much like bending a C library into Ada terms. Yes it is. > A library designed in Ada from the ground up, would be better. But we cannot, think about a type- and task-safe notification mechanism. I have no idea how to do it without tagged tasks and protected objects. And I don't want to instantiate a generic each time I need an event handler. And I do want the compiler to check that all events are handled. > Part of the difficulty is that something like a GUI takes so > much effort to develop. To get one developed to a "standard > level" would likely require some level of sponsorship. > Especially if you want to also attempt to make it platform > neutral. The main problem is the interface of such a library. There are multiple parallel hierarchies need to be handled: a hierarchy of widget types, a hierarchy of widget containers, a hierarchy of event handlers (events are filtered, propagated, swallowed, re-generated). At least the first and the third must be statically checked, if we really want it be Ada. Very likely that some composite widgets (the second hierarchy) should also be static. Then there is a fourth hierarchy of widget properties. Some of the properties are inherited from parent types, some are from parent containers. All these hierarchies must play with each other. Ada's type system is not mature for this. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 15:59 ` Properties Dmitry A. Kazakov @ 2010-12-01 16:20 ` Warren 2010-12-01 18:22 ` Properties Dmitry A. Kazakov 2010-12-01 19:48 ` Properties Randy Brukardt 2010-12-03 5:53 ` Properties Shark8 1 sibling, 2 replies; 94+ messages in thread From: Warren @ 2010-12-01 16:20 UTC (permalink / raw) Dmitry A. Kazakov expounded in news:1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net: > On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote: >> A library designed in Ada from the ground up, would be >> better. > > But we cannot, think about a type- and task-safe > notification mechanism. I have no idea how to do it without > tagged tasks and protected objects. Perhaps the scope you have in mind is too large. Is it really necessary to have the GUI operate outside of one task? Leave the task handling to the application designer. > And I don't want to > instantiate a generic each time I need an event handler. Agreed, but I don't believe we're stuck with that solution. All you need is procedure'Access for the callback. > And I do want the compiler to check that all events are > handled. Hmmm, more of a scope problem, I think. Your requirements may be part of the problem. >> Part of the difficulty is that something like a GUI takes >> so much effort to develop. To get one developed to a >> "standard level" would likely require some level of >> sponsorship. Especially if you want to also attempt to >> make it platform neutral. > > The main problem is the interface of such a library. There > are multiple parallel hierarchies need to be handled: a > hierarchy of widget types, a hierarchy of widget > containers, There are some challenges there, but I don't believe the fact that you need widget containers is a show stopper. > a hierarchy of event handlers (events are > filtered, propagated, swallowed, re-generated). Not a problem with the callback approach, AFAICS. > At least > the first and the third must be statically checked, if we > really want it be Ada. Callbacks (events) are dynamic by nature. I think the best you can hope for is that your event handler is the correct kind (of callback) and that any parameters match are of the correct type. Both areas that Ada excells at. Asking for more than that, is perhaps a requirements problem. > Very likely that some composite > widgets (the second hierarchy) should also be static. I think tagged records are going to be the only real solution here, which is going to forgo static analysis. I think a tagged solution is at least as good as a C++ solution, but better due to Ada strengths. I think many folks could live with the dynamic nature of an Ada GUI library. > Then > there is a fourth hierarchy of widget properties. Some of > the properties are inherited from parent types, some are > from parent containers. > > All these hierarchies must play with each other. Ada's type > system is not mature for this. Perhaps not mature enough for your requirements. It really comes down to what is "good enough" for a standard GUI library. Your requirements are desirable, but with existing software technologies, it doesn't appear practical AFAICS. Are there any GUI systems implemented that are fully static checked? Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 16:20 ` Properties Warren @ 2010-12-01 18:22 ` Dmitry A. Kazakov 2010-12-01 19:36 ` Properties Shark8 2010-12-01 21:35 ` Properties Maciej Sobczak 2010-12-01 19:48 ` Properties Randy Brukardt 1 sibling, 2 replies; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-01 18:22 UTC (permalink / raw) On Wed, 1 Dec 2010 16:20:44 +0000 (UTC), Warren wrote: > Dmitry A. Kazakov expounded in > news:1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net: > >> On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote: >>> A library designed in Ada from the ground up, would be >>> better. >> >> But we cannot, think about a type- and task-safe >> notification mechanism. I have no idea how to do it without >> tagged tasks and protected objects. > > Perhaps the scope you have in mind is too large. Is it really > necessary to have the GUI operate outside of one task? Affirmative. Consider an oscilloscope widget indicating real-time data. Consider a debug window showing log messages from different tasks. The worst thing of GTK is that it is not task-safe. > Leave the task handling to the application designer. Obtrusive and inefficient. I did it for GtkAda. It is quite uncomfortable to use, and if you forget to route GTK requests to the main task, you get sporadic crashes difficult to trace down, quite nasty. >> And I don't want to >> instantiate a generic each time I need an event handler. > > Agreed, but I don't believe we're stuck with that solution. > All you need is procedure'Access for the callback. No, because events have parameters and those must be typed. The standard solution is that you instantiate a generic (and there is one for each number of parameters and the results). That is extremely boring. >> And I do want the compiler to check that all events are >> handled. > > Hmmm, more of a scope problem, I think. Your requirements may > be part of the problem. But otherwise you would have to frantically search for the handler that caught the event you expected the widget to propagate, just to learn that the widget does not propagate it at all. Even better if you create an events generator that covers all desktop with multiplying pop-up windows. I hate this stuff. >> At least >> the first and the third must be statically checked, if we >> really want it be Ada. > > Callbacks (events) are dynamic by nature. I think the best you > can hope for is that your event handler is the correct kind > (of callback) and that any parameters match are of the correct > type. Both areas that Ada excells at. > > Asking for more than that, is perhaps a requirements problem. Maybe, but I expect excellence from a standard library. >> Very likely that some composite >> widgets (the second hierarchy) should also be static. > > I think tagged records are going to be the only real solution > here, which is going to forgo static analysis. Yes, this is my impression too. > I think a tagged solution is at least as good as a C++ > solution, but better due to Ada strengths. I think many folks > could live with the dynamic nature of an Ada GUI library. BTW, most likely multiple inheritance will be needed. There is a huge resistance to MI in Ada. I have no idea why, nobody managed to articulate anything but prejudices and urban legends. > It really comes down to what is "good enough" for a standard > GUI library. Your requirements are desirable, but with > existing software technologies, it doesn't appear practical > AFAICS. They are practical at least in pushing Ada into a right direction. (I guess, the reason why I agree with Randy most of the time is because he maintains CLAW and I do the GtkAda contributions. This keeps us on the same page.) > Are there any GUI systems implemented that are fully static > checked? I guess no. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 18:22 ` Properties Dmitry A. Kazakov @ 2010-12-01 19:36 ` Shark8 2010-12-01 21:13 ` Properties Dmitry A. Kazakov 2010-12-01 21:35 ` Properties Maciej Sobczak 1 sibling, 1 reply; 94+ messages in thread From: Shark8 @ 2010-12-01 19:36 UTC (permalink / raw) >> Agreed, but I don't believe we're stuck with that solution. >> All you need is procedure'Access for the callback. > >No, because events have parameters and those must be typed. >The standard solution is that you instantiate a generic (and >there is one for each number of parameters and the results). >That is extremely boring. Er, why not use OO/tagged-records for the events themselves and let the base-handler have that as a parameter? i.e. the handler would be an access to something like this: Procedure On_Event( Object : in out : GUI_Object; --'Class? Event : In Base_Event'Class ); The Root for GUI-objects can say "On_Event(...) is null*" and allow overriding for the components that DO use it. *A Null-body, not null- access. Further some mouse-event can extend the base-record with items such as the position of the mouse. Or is there something I'm missing? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 19:36 ` Properties Shark8 @ 2010-12-01 21:13 ` Dmitry A. Kazakov 0 siblings, 0 replies; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-01 21:13 UTC (permalink / raw) On Wed, 1 Dec 2010 11:36:57 -0800 (PST), Shark8 wrote: >>> Agreed, but I don't believe we're stuck with that solution. >>> All you need is procedure'Access for the callback. >> >>No, because events have parameters and those must be typed. >>The standard solution is that you instantiate a generic (and >>there is one for each number of parameters and the results). >>That is extremely boring. > > Er, why not use OO/tagged-records for the events themselves and let > the base-handler have that as a parameter? > > i.e. the handler would be an access to something like this: > Procedure On_Event( Object : in out : GUI_Object; --'Class? > Event : In Base_Event'Class ); Yes, event handlers are naturally doubly dispatching, this is why you were not sure if On_Event should be a primitive operation of GUI_Object. It should and it also should be one of the Base_Event. Unless you downcast in the handler body. Another issue with the above is that you will have to derive from Base_Event somewhere this might be actually forbidden. On_Event is a closure, which is tend to be a subprogram rather than a primitive operation. Event parameters usually marshaled, which might be difficult. Yet another issue. Handlers actually connect the GUI object and the context of the handler. The context, if not of a closure, then another GUI object. E.g. normally one object catches events of another. In a GUI objects are usually collected. So you need a mechanism which disconnects the handler if any of the objects get destroyed. In any case it is probably triply dispatching: procedure On_Event (Emitter, Observer : in out : GUI_Object; Event : In Base_Event); -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 18:22 ` Properties Dmitry A. Kazakov 2010-12-01 19:36 ` Properties Shark8 @ 2010-12-01 21:35 ` Maciej Sobczak 2010-12-01 21:45 ` Properties Dmitry A. Kazakov 1 sibling, 1 reply; 94+ messages in thread From: Maciej Sobczak @ 2010-12-01 21:35 UTC (permalink / raw) On Dec 1, 7:22 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > > Perhaps the scope you have in mind is too large. Is it really > > necessary to have the GUI operate outside of one task? > > Affirmative. Consider an oscilloscope widget indicating real-time data. > Consider a debug window showing log messages from different tasks. And how is this any different from, say, printing exactly the same log messages on standard output? You do not expect different tasks to spit their stuff directly to Ada.Text_IO and have it working properly, right? How do you solve this problem with Ada.Text_IO? Why the same solution cannot apply to GUI? I don't see any problem with single-threaded GUI, as long as there are ways to communicate with it. It is the communication part that has to be task-safe, not the GUI as a whole. > > Leave the task handling to the application designer. > > Obtrusive and inefficient. I did it for GtkAda. It is quite uncomfortable > to use, and if you forget to route GTK requests to the main task, you get > sporadic crashes difficult to trace down, quite nasty. I thought that Ada has enough tools to support arbitrary visibility and access strategies. If you can "forget to route GTK requests to the main task", then there is some package/typing problem in the code. Is GUI to be blamed for this? -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 21:35 ` Properties Maciej Sobczak @ 2010-12-01 21:45 ` Dmitry A. Kazakov 2010-12-02 9:57 ` Properties Maciej Sobczak 0 siblings, 1 reply; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-01 21:45 UTC (permalink / raw) On Wed, 1 Dec 2010 13:35:32 -0800 (PST), Maciej Sobczak wrote: > On Dec 1, 7:22�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >>> Perhaps the scope you have in mind is too large. Is it really >>> necessary to have the GUI operate outside of one task? >> >> Affirmative. Consider an oscilloscope widget indicating real-time data. >> Consider a debug window showing log messages from different tasks. > > And how is this any different from, say, printing exactly the same log > messages on standard output? It is just same. You can safely call Put_Line from any task. But if you do Set_Text in GTK, that will crash your program. > How do you solve this problem with Ada.Text_IO? Why the same solution > cannot apply to GUI? I would like to have a similar solution, i.e. GUI things working without switching the contexts. >>> Leave the task handling to the application designer. >> >> Obtrusive and inefficient. I did it for GtkAda. It is quite uncomfortable >> to use, and if you forget to route GTK requests to the main task, you get >> sporadic crashes difficult to trace down, quite nasty. > > I thought that Ada has enough tools to support arbitrary visibility > and access strategies. If you can "forget to route GTK requests to the > main task", then there is some package/typing problem in the code. Is > GUI to be blamed for this? On the context of the main GTK task you just call Set_Text. From an alien task you need to instantiate a generic, or pass a closure, or override a primitive operation of a query object and from the callback call to Set_Text. The router calls the callback on the context of the main task. You would not do this for each graphic operations. Instead you have a sort of transactions, sets of operations executed in a group. This makes the code look very different. As I said it is obtrusive. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 21:45 ` Properties Dmitry A. Kazakov @ 2010-12-02 9:57 ` Maciej Sobczak 2010-12-02 10:26 ` Properties Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 94+ messages in thread From: Maciej Sobczak @ 2010-12-02 9:57 UTC (permalink / raw) On Dec 1, 10:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > > And how is this any different from, say, printing exactly the same log > > messages on standard output? > > It is just same. You can safely call Put_Line from any task. Wrong (AARM Annex A, 3.a): "simultaneous calls to Text_IO.Put will work properly, so long as they are going to two different files. On the other hand, simultaneous output to the same file constitutes erroneous use of shared variables." You might argue that by analogy two tasks should be able to modify the content of two distinct widgets, but that would be stretching definitions, as the agreement of what is "distinct" in GUI is quite arbitrary (ultimately, everything is a "child" of some uber-container, like a display and shares, so nothing is really distinct). > But if you do > Set_Text in GTK, that will crash your program. You mean - that will lead to erroneous execution? So it is exactly the same as with printing on standard output. Why do you expect to get better guarantees from GUI than from stdout? > > How do you solve this problem with Ada.Text_IO? Why the same solution > > cannot apply to GUI? > > I would like to have a similar solution, i.e. GUI things working without > switching the contexts. "Switching the contexts" is a technical term that relates to some platform implementation details. I don't see why this is relevant to GUIs, certainly not for performance reasons. And again, this is the same as with standard output. > On the context of the main GTK task you just call Set_Text. From an alien > task you need to instantiate a generic, or pass a closure, or override a > primitive operation of a query object and from the callback call to > Set_Text. The router calls the callback on the context of the main task. > You would not do this for each graphic operations. Instead you have a sort > of transactions, sets of operations executed in a group. This makes the > code look very different. As I said it is obtrusive. Is this a GUI problem or a general language problem? And is this really a proper design? I have implemented a GUI application recently. Not in Ada, but the general concepts are transferrable, as the tasking constraints were the same. The design involved a separate encapsulating "gui" package that exposed subprograms for *logical* (ie. domain-level) manipulations of the displayed content. The actual domain-oriented tasks of the application were not concerned with "setting a new text value of some widget", but rather with updating the domain-level information, whatever it was. By doing this, I have achieved not only the physical encapsulation of the display part and loose coupling between functional modules (heck, I could change that to a web service without touching anything else), which solved the tasking constraints, but also raised the level of operation for the rest of the program. And I don't consider it to be "obtrusive". With this experience in mind, if you insist on GUI to be task-safe, I think it is because you want the GUI library to support poor design practices. Having arbitrary application tasks calling Set_Text directly on some widget sounds like spaghetti. And that's why I'm not convinced. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 9:57 ` Properties Maciej Sobczak @ 2010-12-02 10:26 ` Dmitry A. Kazakov 2010-12-02 15:25 ` Properties Maciej Sobczak 2010-12-04 17:43 ` Properties Simon Wright 2010-12-03 4:24 ` Properties Randy Brukardt 2010-12-03 5:00 ` Properties Shark8 2 siblings, 2 replies; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-02 10:26 UTC (permalink / raw) On Thu, 2 Dec 2010 01:57:49 -0800 (PST), Maciej Sobczak wrote: > On Dec 1, 10:45�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >>> And how is this any different from, say, printing exactly the same log >>> messages on standard output? >> >> It is just same. You can safely call Put_Line from any task. > > Wrong (AARM Annex A, 3.a): > > "simultaneous calls to Text_IO.Put will work properly, so long as they > are going to two different files. On the other hand, simultaneous > output to the same file constitutes erroneous use of shared > variables." OK, I let us consider only "reasonable" implementations of Put. >> But if you do >> Set_Text in GTK, that will crash your program. > > You mean - that will lead to erroneous execution? So it is exactly the > same as with printing on standard output. I don't know if there is an Ada implementation working this way. > Why do you expect to get better guarantees from GUI than from stdout? Because in all Ada compilers I used so far this was safe. >>> How do you solve this problem with Ada.Text_IO? Why the same solution >>> cannot apply to GUI? >> >> I would like to have a similar solution, i.e. GUI things working without >> switching the contexts. > > "Switching the contexts" is a technical term that relates to some > platform implementation details. I don't see why this is relevant to > GUIs, certainly not for performance reasons. A "reasonable" implementation of Text_IO queues I/O requests to some internal or external task/driver. I want same sort of design for graphical requests. >> On the context of the main GTK task you just call Set_Text. From an alien >> task you need to instantiate a generic, or pass a closure, or override a >> primitive operation of a query object and from the callback call to >> Set_Text. The router calls the callback on the context of the main task. >> You would not do this for each graphic operations. Instead you have a sort >> of transactions, sets of operations executed in a group. This makes the >> code look very different. As I said it is obtrusive. > > Is this a GUI problem or a general language problem? It is a problem of the GTK library design. > And is this really a proper design? No. > With this experience in mind, if you insist on GUI to be task-safe, I > think it is because you want the GUI library to support poor design > practices. No, single thread GUI is bad design practice, that is when you block the GUI when your dialog has a progress bar. A good design practice is that the application does nothing functional on the context of the message loop. Any action on this context must be a subject of design rules similar to ones for the protected actions: non-blocking, atomic, short, semantically instant. > Having arbitrary application tasks calling Set_Text > directly on some widget sounds like spaghetti. On the contrary, spaghetti is poor man's multitasking implemented by callbacks from timer messages on the context of the messages loop. GUI is natively multitasking: 1. actions invoked by its controls are not instant: progress bar 2. some controls are active objects: animation widgets, visual effects, tooltips, hovering etc 3. indication of asynchronous events and data: oscilloscope -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 10:26 ` Properties Dmitry A. Kazakov @ 2010-12-02 15:25 ` Maciej Sobczak 2010-12-02 15:46 ` Properties Dmitry A. Kazakov 2010-12-04 17:43 ` Properties Simon Wright 1 sibling, 1 reply; 94+ messages in thread From: Maciej Sobczak @ 2010-12-02 15:25 UTC (permalink / raw) On Dec 2, 11:26 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > > Why do you expect to get better guarantees from GUI than from stdout? > > Because in all Ada compilers I used so far this was safe. Safe? What is the benefit of safe if at the same time it's pointless? Put ("My "); Put ("name "); Put ("is "); Put_Line ("Maciej"); I have multiple tasks doing it. What is safe for you? For me "safe" means "not corrupting the information" and the above sequence produces a single piece of information. There is no point in Text_IO to be internally synchronized, because the granularity of synchronization can be defined only at the application level. And once this is done, it is also sufficient and then any internal synchronization is a waste. Similar reasoning applies to GUIs. Imagine a graphical display of multi-line log messages. There is no point for such GUI to be task safe, because GUI has no understanding of the logical granularity of what is being displayed. > A "reasonable" implementation of Text_IO queues I/O requests to some > internal or external task/driver. I want same sort of design for graphical > requests. Not necessarily. And there are lots of data structures that have to be acted upon until you come close to the driver. These data structures are vulnerable to corruption. > GUI is natively multitasking: > > 1. actions invoked by its controls are not instant: progress bar > 2. some controls are active objects: animation widgets, visual effects, > tooltips, hovering etc > 3. indication of asynchronous events and data: oscilloscope How is that any different from standard output? How is your oscilloscope any different from the "top" utility that displays the state of many processes on the text terminal? It is not different and therefore does not need any additional guarantees. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 15:25 ` Properties Maciej Sobczak @ 2010-12-02 15:46 ` Dmitry A. Kazakov 2010-12-02 21:11 ` Properties Maciej Sobczak 0 siblings, 1 reply; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-02 15:46 UTC (permalink / raw) On Thu, 2 Dec 2010 07:25:20 -0800 (PST), Maciej Sobczak wrote: > On Dec 2, 11:26�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: > >>> Why do you expect to get better guarantees from GUI than from stdout? >> >> Because in all Ada compilers I used so far this was safe. > > Safe? What is the benefit of safe if at the same time it's pointless? > > Put ("My "); > Put ("name "); > Put ("is "); > Put_Line ("Maciej"); > > I have multiple tasks doing it. What is safe for you? 1. It does not crash, the effect is defined 2. Put is atomic > Imagine a graphical display of > multi-line log messages. There is no point for such GUI to be task > safe, because GUI has no understanding of the logical granularity of > what is being displayed. The point is that tasks putting messages into the trace widget should have an ability to do this atomically independently on each other and the interface should be a procedure call. This is how the trace dialog window is implemented in the GtkAda contributions. Its interface procedure Trace can be called from any Ada task. >> A "reasonable" implementation of Text_IO queues I/O requests to some >> internal or external task/driver. I want same sort of design for graphical >> requests. > > Not necessarily. And there are lots of data structures that have to be > acted upon until you come close to the driver. These data structures > are vulnerable to corruption. Only if designed poorly. The requirement to be task-safe means that internally managed structures do not get corrupt when public interfaces are used. >> GUI is natively multitasking: >> >> 1. actions invoked by its controls are not instant: progress bar >> 2. some controls are active objects: animation widgets, visual effects, >> tooltips, hovering etc >> 3. indication of asynchronous events and data: oscilloscope > > How is that any different from standard output? What is different/same from what? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 15:46 ` Properties Dmitry A. Kazakov @ 2010-12-02 21:11 ` Maciej Sobczak 2010-12-02 22:19 ` Properties Dmitry A. Kazakov 2010-12-03 4:43 ` Properties Randy Brukardt 0 siblings, 2 replies; 94+ messages in thread From: Maciej Sobczak @ 2010-12-02 21:11 UTC (permalink / raw) On Dec 2, 4:46 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > > Safe? What is the benefit of safe if at the same time it's pointless? > > > Put ("My "); > > Put ("name "); > > Put ("is "); > > Put_Line ("Maciej"); > > > I have multiple tasks doing it. What is safe for you? > > 1. It does not crash, the effect is defined > 2. Put is atomic These are very weak requirements. The information was scrambled - the mail packages arrived at the wrong address, the missile attacked the wrong country and the doctor removed the liver of the wrong patient. But nothing crashed. :-) The reasons why it's pointless to internally synchronize GUI (or Text_IO) are exactly the same as why it's pointless to synchronize standard containers. It's the wrong level of granularity. You might steer away from erroneous execution, but that does not in itself make the program correct. > >> GUI is natively multitasking: > > >> 1. actions invoked by its controls are not instant: progress bar > >> 2. some controls are active objects: animation widgets, visual effects, > >> tooltips, hovering etc > >> 3. indication of asynchronous events and data: oscilloscope > > > How is that any different from standard output? > > What is different/same from what? GUI from Text_IO. I will try to answer myself: the difference is that Text_IO, as an abstract stream, "feels" sequential by nature, whereas GUI, with its 2D layout (+ time dimension for content changes), makes concurrency more appealing. Still, good design principles call for decoupling of application logic and display (maybe with some intermediate "data model" module?) and this decoupling blurs that distinction significantly. I'm not convinced that GUI should be task-safe. Supporting bad application designs would be a wrong justification. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 21:11 ` Properties Maciej Sobczak @ 2010-12-02 22:19 ` Dmitry A. Kazakov 2010-12-03 4:43 ` Properties Randy Brukardt 1 sibling, 0 replies; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-02 22:19 UTC (permalink / raw) On Thu, 2 Dec 2010 13:11:58 -0800 (PST), Maciej Sobczak wrote: > I'm not convinced that GUI should be task-safe. Supporting bad > application designs would be a wrong justification. Well, if enjoy design a UI from single thread, that is your choice. But count me out. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 21:11 ` Properties Maciej Sobczak 2010-12-02 22:19 ` Properties Dmitry A. Kazakov @ 2010-12-03 4:43 ` Randy Brukardt 2010-12-03 13:53 ` Properties Maciej Sobczak 1 sibling, 1 reply; 94+ messages in thread From: Randy Brukardt @ 2010-12-03 4:43 UTC (permalink / raw) "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message news:2a3219cb-5793-4e5b-97aa-036da124ccba@y31g2000vbt.googlegroups.com... ... >Still, good design principles call for decoupling of >application logic and display (maybe with some intermediate "data >model" module?) and this decoupling blurs that distinction >significantly. When it comes to GUI programming, this supposedly "good design principle" often doesn't make any sense. For example, consider the series of SLED (Simple Little EDitor) examples in Claw. These show how a Notepad-like editor could be constructed using Claw. In this case, the "application logic" is editing of text (that is, handling insertions, deletions, cut, paste, etc.) If you strictly decouple that from the GUI, you then cannot use the prexisting controls that automatically provide that editing functionality. Several of the SLED versions show how that can be done, but the versions using the Rich_Edit control are a lot shorter and also a lot more powerful. You will have that problem with any GUI program that manages text. And there are lots of other similar sorts of examples out there as well. The problem, of course is that there is no such thing as a clear boundary between "application logic" and "display". The application logic has a strong effect on what can be displayed and how; similarly, what the user does with the GUI has a strong effect on what application logic is invoked. They can't be completely independent. Randy. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 4:43 ` Properties Randy Brukardt @ 2010-12-03 13:53 ` Maciej Sobczak 2010-12-03 21:32 ` Properties Randy Brukardt 0 siblings, 1 reply; 94+ messages in thread From: Maciej Sobczak @ 2010-12-03 13:53 UTC (permalink / raw) On Dec 3, 5:43 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > When it comes to GUI programming, this supposedly "good design principle" > often doesn't make any sense. > > For example, consider the series of SLED (Simple Little EDitor) examples in > Claw. These show how a Notepad-like editor could be constructed using Claw. Yes. There are two points, however: 1. Text editors (in particular text widgets) are both sources and destinations of data. That is, they not only display something, they also control the content by allowing the user to interact with it and modify it. Thanks to this coupling of functionality (content control and rendering) it makes sense to delegate the data structure management to the same component as well. In this regard text widgets are self-contained. Unfortunately this reasoning has no applicability in a real-time oscilloscope display, where such coupling does not occur - data source is definitely separate from the rendering component so there is no justification for coupling data model with widgets. On the contrary, it makes perfect sense to decouple them - for starters, did I mention several displays showing the same signal, but with different filtering settings? 2. Your text-editing example has little relation to multitasking as a general GUI feature. Of course one can imagine, for example, a background spellchecker task or something in this area, but this is so particular to the text editing domain that is hardly a justification for requiring that the whole GUI framework must be task-safe. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 13:53 ` Properties Maciej Sobczak @ 2010-12-03 21:32 ` Randy Brukardt 2010-12-04 22:13 ` Properties Maciej Sobczak 0 siblings, 1 reply; 94+ messages in thread From: Randy Brukardt @ 2010-12-03 21:32 UTC (permalink / raw) "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message news:0c899bff-c580-4b9f-9c94-b9226c089cde@j29g2000yqm.googlegroups.com... On Dec 3, 5:43 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote: >> When it comes to GUI programming, this supposedly "good design principle" >> often doesn't make any sense. >> >> For example, consider the series of SLED (Simple Little EDitor) examples >> in >> Claw. These show how a Notepad-like editor could be constructed using >> Claw. > >Yes. There are two points, however: > >1. Text editors (in particular text widgets) are both sources and >destinations of data. That is, they not only display something, they >also control the content by allowing the user to interact with it and >modify it. Thanks to this coupling of functionality (content control >and rendering) it makes sense to delegate the data structure >management to the same component as well. In this regard text widgets >are self-contained. Right. My point is that is the quite natural to have widgets like that. Text processing surely is not the only example. >Unfortunately this reasoning has no applicability in a real-time >oscilloscope display, where such coupling does not occur - data source >is definitely separate from the rendering component so there is no >justification for coupling data model with widgets. On the contrary, >it makes perfect sense to decouple them - for starters, did I mention >several displays showing the same signal, but with different filtering >settings? Possibly, but irrelevant. My point was that the "good design principle" is nowhere near absolute when it comes to GUIs. It makes just as much sense for some applications to have a control (widget) that does everything. I never claimed that you should *never* separate these things, only that claiming that a design that does not do so is somehow wrong is simplistic. >2. Your text-editing example has little relation to multitasking as a >general GUI feature. Of course one can imagine, for example, a >background spellchecker task or something in this area, but this is so >particular to the text editing domain that is hardly a justification >for requiring that the whole GUI framework must be task-safe. I don't believe that a general-purpose library should be telling people how to design their software. (This is very similar to the issue of almost never using access types in the interface -- the library should not be telling people how to do memory management.) Indeed, I think that *any* library intended for general Ada usage ought to be task-safe to the extent that Ada.Text_IO and Ada.Containers are (access to different objects of the library by different tasks always work). That surely includes GUI libraries. That's all that Claw guarantees (that two tasks can access different controls/windows without interference). Libraries that don't meet those basic Ada requirements are very constraining, lead to the sort of problems that Dmitry mentioned (accidental use from the wrong task causes crashes and no clear indication of the mistake). Sometimes you have to use such things, but they then require wrapping in the Ada environment (unless you like debugging!). Randy. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 21:32 ` Properties Randy Brukardt @ 2010-12-04 22:13 ` Maciej Sobczak 2010-12-06 23:30 ` Properties Shark8 2010-12-06 23:33 ` Properties Randy Brukardt 0 siblings, 2 replies; 94+ messages in thread From: Maciej Sobczak @ 2010-12-04 22:13 UTC (permalink / raw) On Dec 3, 10:32 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > Indeed, I think that *any* library intended for general Ada usage ought to > be task-safe to the extent that Ada.Text_IO and Ada.Containers are (access > to different objects of the library by different tasks always work). What are different objects? Certainly, AARM does not allow several tasks to access distinct elements of the same container - because, well, even though the elements are different, they belong to the same container. > That > surely includes GUI libraries. ...where almost everything is a child of some bigger container. I understand what you try to convey (and to a large extent I agree with it), but the analogy with containers does not work. By that analogy it should be forbidden to access two controls of the same window from different tasks without additional synchronization. > That's all that Claw guarantees I can imagine that it was very expensive to achieve. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-04 22:13 ` Properties Maciej Sobczak @ 2010-12-06 23:30 ` Shark8 2010-12-06 23:33 ` Properties Randy Brukardt 1 sibling, 0 replies; 94+ messages in thread From: Shark8 @ 2010-12-06 23:30 UTC (permalink / raw) On Dec 4, 3:13 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote: > ...where almost everything is a child of some bigger container. > > I understand what you try to convey (and to a large extent I agree > with it), but the analogy with containers does not work. By that > analogy it should be forbidden to access two controls of the same > window from different tasks without additional synchronization. Hm, wouldn't that be achievable by having each program/application have its own Task for its GUI-handling? (Then, conceptually, all the GUI components are owned by the single-container that is owned-by/ contained-within the Task, no?) ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-04 22:13 ` Properties Maciej Sobczak 2010-12-06 23:30 ` Properties Shark8 @ 2010-12-06 23:33 ` Randy Brukardt 1 sibling, 0 replies; 94+ messages in thread From: Randy Brukardt @ 2010-12-06 23:33 UTC (permalink / raw) "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message news:acc754a9-4861-401a-a904-5f22efe852ac@z26g2000prf.googlegroups.com... >On Dec 3, 10:32 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > >> Indeed, I think that *any* library intended for general Ada usage ought >> to >> be task-safe to the extent that Ada.Text_IO and Ada.Containers are >> (access >> to different objects of the library by different tasks always work). > >What are different objects? The definition I use is the RM one: "non-overlapping" objects. Informally, these occur anytime you have parameters that are all distinct (none denoting parts of any of the others, taking into account renames and components, but generally not access values). Practically, if the implementation is a bunch of objects interconnected by access types, the individual objects should be task-safe; if the objects are components of a larger object, then task safety is probably a mistake. But that's too implementation-oriented a definition to use. There really can't a formal definition, unfortunately, because of the need to support portions of objects that aren't components but are managed as if they were. So we could argue about the exact definition all day. > Certainly, AARM does not allow several tasks to access distinct > elements of the same container - because, well, even though the > elements are different, they belong to the same container. In this case, the container is implicitly part of the cursor parameters. Note that I believe this is a design bug in the Ada.Containers; the container parameter ought to be explicit in all of these operations, including the reading ones. As they are defined currently, you would expect tasking to work on reading of different elements (and like Text_IO, it probably will work in practice). >> That >> surely includes GUI libraries. > >...where almost everything is a child of some bigger container. Here I disagree. A GUI is a bunch of cooperating objects; the organization is a loosely coupled. Just because a button has a parent window doesn't mean that the button isn't an independent object (it could be moved to a different parent, for instance). >I understand what you try to convey (and to a large extent I agree >with it), but the analogy with containers does not work. By that >analogy it should be forbidden to access two controls of the same >window from different tasks without additional synchronization. The problem here is that the containers specification is incorrect -- it doesn't properly expose the relationship with the container objects. Thus you are making the wrong analogy. (Given the specification given for reading container objects, task safety ought to be required. We didn't do that because we really meant it to work as if the container was explicitly given. This is also a problem in defining the behavior of the operations formally, and it prevents using prefix notation with these calls.) If your hypothetical GUI never allowed accessing the controls of a window without mentioning the name of the parent window, then I would in fact agree with your implementation. But I'd still want task-safety between windows. >> That's all that Claw guarantees >I can imagine that it was very expensive to achieve. It's not that hard to achieve, the problem is avoiding deadlock (since you have to be able to do operations in action routines). We would have had to do it in any case, given that we set up a separate task to handle messages. And, as noted above, the problems only really show up when you modify the "shape" of the GUI, adding or removing windows/controls. (Just directly reading or writing a control is not a problem.) Randy. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 10:26 ` Properties Dmitry A. Kazakov 2010-12-02 15:25 ` Properties Maciej Sobczak @ 2010-12-04 17:43 ` Simon Wright 2010-12-04 20:48 ` Properties Dmitry A. Kazakov 1 sibling, 1 reply; 94+ messages in thread From: Simon Wright @ 2010-12-04 17:43 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Thu, 2 Dec 2010 01:57:49 -0800 (PST), Maciej Sobczak wrote: > >> On Dec 1, 10:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> >> wrote: >> >>>> And how is this any different from, say, printing exactly the same log >>>> messages on standard output? >>> >>> It is just same. You can safely call Put_Line from any task. >> >> Wrong (AARM Annex A, 3.a): >> >> "simultaneous calls to Text_IO.Put will work properly, so long as they >> are going to two different files. On the other hand, simultaneous >> output to the same file constitutes erroneous use of shared >> variables." > > OK, I let us consider only "reasonable" implementations of Put. > >>> But if you do >>> Set_Text in GTK, that will crash your program. >> >> You mean - that will lead to erroneous execution? So it is exactly the >> same as with printing on standard output. > > I don't know if there is an Ada implementation working this way. > >> Why do you expect to get better guarantees from GUI than from stdout? > > Because in all Ada compilers I used so far this was safe. Then I don't think you can have used GNAT on VxWorks! ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-04 17:43 ` Properties Simon Wright @ 2010-12-04 20:48 ` Dmitry A. Kazakov 2010-12-04 22:27 ` Properties Simon Wright 0 siblings, 1 reply; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-04 20:48 UTC (permalink / raw) On Sat, 04 Dec 2010 17:43:30 +0000, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> Because in all Ada compilers I used so far this was safe. > > Then I don't think you can have used GNAT on VxWorks! Hmm, I did and do GNAT Pro under VxWorks and noticed no problems. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-04 20:48 ` Properties Dmitry A. Kazakov @ 2010-12-04 22:27 ` Simon Wright 2010-12-04 22:31 ` Properties Vinzent Hoefler 0 siblings, 1 reply; 94+ messages in thread From: Simon Wright @ 2010-12-04 22:27 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Sat, 04 Dec 2010 17:43:30 +0000, Simon Wright wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >> >>> Because in all Ada compilers I used so far this was safe. >> >> Then I don't think you can have used GNAT on VxWorks! > > Hmm, I did and do GNAT Pro under VxWorks and noticed no problems. Perhaps it's that we were using serial output? We typically saw, with two tasks one outputting "aaaaaaa" and the other "bbbbbbb" aaabababababbbaa ... etc Simple enough to fix, of course. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-04 22:27 ` Properties Simon Wright @ 2010-12-04 22:31 ` Vinzent Hoefler 0 siblings, 0 replies; 94+ messages in thread From: Vinzent Hoefler @ 2010-12-04 22:31 UTC (permalink / raw) Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Sat, 04 Dec 2010 17:43:30 +0000, Simon Wright wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>> >>>> Because in all Ada compilers I used so far this was safe. >>> >>> Then I don't think you can have used GNAT on VxWorks! >> >> Hmm, I did and do GNAT Pro under VxWorks and noticed no problems. > > Perhaps it's that we were using serial output? Yes. That's it. :) Vinzent. -- Beaten by the odds since 1974. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 9:57 ` Properties Maciej Sobczak 2010-12-02 10:26 ` Properties Dmitry A. Kazakov @ 2010-12-03 4:24 ` Randy Brukardt 2010-12-03 5:00 ` Properties Shark8 2 siblings, 0 replies; 94+ messages in thread From: Randy Brukardt @ 2010-12-03 4:24 UTC (permalink / raw) "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message news:18768dde-5817-40b9-aaa1-03c620ad7187@i32g2000pri.googlegroups.com... ... >You might argue that by analogy two tasks should be able to modify the >content of two distinct widgets, but that would be stretching >definitions, as the agreement of what is "distinct" in GUI is quite >arbitrary (ultimately, everything is a "child" of some uber-container, >like a display and shares, so nothing is really distinct). I wouldn't *argue* that, I'd say it ought to be a fact. And it is in Claw... I'd also suggest that the Standard screwed up with Text_IO. It should have some guarantee of sanity for writing to Standard_Output (no erroneous execution, but no requirements of ordering, either). In practice, this is the case; I'm not aware of any Windows hosted compiler that really does anything weird with these Put_Lines. Robert Dewar has noted in the past that there are two kinds of erroreous execution: those where truely bad things will happen, and those that are erroneous in name, but in practice will work fine. Put_Line is a clear case of the latter. (Almost every Ada program is full of such cases, at least in the runtime.) ... >I have implemented a GUI application recently. Not in Ada, but the >general concepts are transferrable, as the tasking constraints were >the same. >The design involved a separate encapsulating "gui" package that >exposed subprograms for *logical* (ie. domain-level) manipulations of >the displayed content. The actual domain-oriented tasks of the >application were not concerned with "setting a new text value of some >widget", but rather with updating the domain-level information, >whatever it was. By doing this, I have achieved not only the physical >encapsulation of the display part and loose coupling between >functional modules (heck, I could change that to a web service without >touching anything else), which solved the tasking constraints, but >also raised the level of operation for the rest of the program. And I >don't consider it to be "obtrusive". It's not "obtrusive", but what it is is serializing. Essentially, all of your tasks have to line up to get their data updated. Depending on how much data they need to display, that can effectively block them from getting anything significant done. (I've had problems like this with logging facilities in our web server.) The result is that gauges don't update when input is being solicited, and sometimes the tasks themselves have to be blocked. It's usually better to push the serialization to the lowest level (with the shortest execution times), and that is deep within the GUI, not at the top level. Now, I agree that most GUIs simply don't work with tasking; to get Claw to work with it requires lots of locks internally, since Windows doesn't like multiple threads doing I/O. > With this experience in mind, if you insist on GUI to be task-safe, I > think it is because you want the GUI library to support poor design > practices. Having arbitrary application tasks calling Set_Text > directly on some widget sounds like spaghetti. > And that's why I'm not convinced. Fair enough, although I don't really agree. First off all, all GUI code is spaghetti (it's the nature of event-driven programming); it doesn't really matter how you do it. (If there was a better alternative to using event-driven systems, I'd suggest using it, but it doesn't exist so far as I can tell.) Second of all, one design does not fit all. Sometimes you can use a central data repository as you previously suggested, but it doesn't work very well if there is a lot of data (because of the need to provide mutual exclusion on the data, along with the need to give the GUI priority access to that data) or if the processing time is short compared to the time to display the data. I prefer that my GUI framework allow *any* reasonable design, rather than forcing one into abstractions that may very well just bloat up the code. In Claw, the usual approach for simple widgets is to put all of the functionality directly into the widget itself (including any tasking needed), rather than artifically separating the data creation from the display. (Most of the GUI programs I've worked on have had very little data processing associated with them; indeed, most of them have had completely separate GUI management programs from the actual server simply because automatically running programs have to run headless.) In any case, tasking is a critical functionality for Ada, and one of the most important differences between it and most other languages. Deciding to prevent the use of that functionality for one sort of programming is like cutting off a foot... Randy. Randy. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 9:57 ` Properties Maciej Sobczak 2010-12-02 10:26 ` Properties Dmitry A. Kazakov 2010-12-03 4:24 ` Properties Randy Brukardt @ 2010-12-03 5:00 ` Shark8 2010-12-03 21:10 ` Properties Randy Brukardt 2010-12-03 23:34 ` Properties Jeffrey Carter 2 siblings, 2 replies; 94+ messages in thread From: Shark8 @ 2010-12-03 5:00 UTC (permalink / raw) On Dec 2, 2:57 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote: > >Wrong (AARM Annex A, 3.a): > >"simultaneous calls to Text_IO.Put will work properly, so long >as they are going to two different files. On the other hand, >simultaneous output to the same file constitutes erroneous use >of shared variables." > -- > Maciej Sobczak *http://www.inspirel.com Er, then does that mean that the following is wrong? Procedure Top is F : Ada.Text_IO.File_Type; I : Integer:= Positive'First; Task Type Writer(ID : Integer) is end Writer; Task Body Writer is begin -- Write the ID to the file. Ada.Text_IO.Put( Integer'Image(ID) ); end Writer; Function Make_Task Return Writer is begin -- Make unique ID tasks. Return Result : Writer(ID => I) do I:= I + 1; end return; end Make_Task; Type Task_Array is Array (1..20) of Access Writer; Tasks : Task_Array:= ( 1..20 => New Writer'(Make_Task) ); begin Null; -- Everything happens by MAGIC! end top; ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 5:00 ` Properties Shark8 @ 2010-12-03 21:10 ` Randy Brukardt 2010-12-03 23:34 ` Properties Jeffrey Carter 1 sibling, 0 replies; 94+ messages in thread From: Randy Brukardt @ 2010-12-03 21:10 UTC (permalink / raw) "Shark8" <onewingedshark@gmail.com> wrote in message news:18f98563-340c-4bc2-83e5-8d1187f92165@j19g2000prh.googlegroups.com... On Dec 2, 2:57 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote: >> >>Wrong (AARM Annex A, 3.a): >> >>"simultaneous calls to Text_IO.Put will work properly, so long >>as they are going to two different files. On the other hand, >>simultaneous output to the same file constitutes erroneous use >>of shared variables." >Er, then does that mean that the following is wrong? Formally, yes. Practically, no. The underlying OS does not have problems with this sort of construct, nor do any Ada implementations that I am aware of. But of course there is no guarantee as to how the output will be presented. Randy. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 5:00 ` Properties Shark8 2010-12-03 21:10 ` Properties Randy Brukardt @ 2010-12-03 23:34 ` Jeffrey Carter 2010-12-06 6:02 ` Properties Brad Moore 1 sibling, 1 reply; 94+ messages in thread From: Jeffrey Carter @ 2010-12-03 23:34 UTC (permalink / raw) On 12/02/2010 10:00 PM, Shark8 wrote: > > Type Task_Array is Array (1..20) of Access Writer; > Tasks : Task_Array:= ( 1..20 => New Writer'(Make_Task) ); Access is not needed here. You can (and probably should) do something like type Writer_List is array (Positive range <>) of Writer; Writers : constant Writer_List := (1 .. 20 => Make_Writer); -- Jeff Carter "Gentlemen, you can't fight in here. This is the War Room!" Dr. Strangelove 30 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 23:34 ` Properties Jeffrey Carter @ 2010-12-06 6:02 ` Brad Moore 2010-12-06 23:25 ` Properties Shark8 0 siblings, 1 reply; 94+ messages in thread From: Brad Moore @ 2010-12-06 6:02 UTC (permalink / raw) On 03/12/2010 4:34 PM, Jeffrey Carter wrote: > On 12/02/2010 10:00 PM, Shark8 wrote: >> >> Type Task_Array is Array (1..20) of Access Writer; >> Tasks : Task_Array:= ( 1..20 => New Writer'(Make_Task) ); > > Access is not needed here. You can (and probably should) do something like > > type Writer_List is array (Positive range <>) of Writer; > > Writers : constant Writer_List := (1 .. 20 => Make_Writer); > Note that for this to compile, you end up needing to make the task discriminant mutable, since the task type in the array type declaration need to be constrained. Sonmething like; task type Writer (ID : Integer := 0) is end Writer; ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-06 6:02 ` Properties Brad Moore @ 2010-12-06 23:25 ` Shark8 0 siblings, 0 replies; 94+ messages in thread From: Shark8 @ 2010-12-06 23:25 UTC (permalink / raw) On Dec 5, 11:02 pm, Brad Moore <brad.mo...@shaw.ca> wrote: > On 03/12/2010 4:34 PM, Jeffrey Carter wrote: > > > On 12/02/2010 10:00 PM, Shark8 wrote: > > >> Type Task_Array is Array (1..20) of Access Writer; > >> Tasks : Task_Array:= ( 1..20 => New Writer'(Make_Task) ); > > > Access is not needed here. You can (and probably should) do something like > > > type Writer_List is array (Positive range <>) of Writer; > > > Writers : constant Writer_List := (1 .. 20 => Make_Writer); > > Note that for this to compile, you end up needing to make the task > discriminant mutable, since the task type in the array type declaration > need to be constrained. > > Sonmething like; > > task type Writer (ID : Integer := 0) is > end Writer; Ah, Thanks! ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 16:20 ` Properties Warren 2010-12-01 18:22 ` Properties Dmitry A. Kazakov @ 2010-12-01 19:48 ` Randy Brukardt 2010-12-01 21:10 ` Properties Warren 1 sibling, 1 reply; 94+ messages in thread From: Randy Brukardt @ 2010-12-01 19:48 UTC (permalink / raw) "Warren" <ve3wwg@gmail.com> wrote in message news:Xns9E417369AD1F4WarrensBlatherings@81.169.183.62... > Dmitry A. Kazakov expounded in > news:1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net: > >> On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote: >>> A library designed in Ada from the ground up, would be >>> better. >> >> But we cannot, think about a type- and task-safe >> notification mechanism. I have no idea how to do it without >> tagged tasks and protected objects. > > Perhaps the scope you have in mind is too large. Is it really > necessary to have the GUI operate outside of one task? Leave > the task handling to the application designer. We did this with Claw (Dmitry's argument that it is impossible doesn't hold water, since we tried to do all of the things that he suggests with Claw. Perhaps not in the way that he would like...) There definitely are problems where supporting tasking in the GUI is a significant help. For instance, a background task can update part of a window (say for a speed gauge); the main interface does not need to concern itself with keeping "background" information current. OTOH, supporting tasking in the GUI constrains what can be done in an event handler (Claw calls them "When_" routines), as it is quite easy to deadlock the system by having a handler do something that requires a lock that some other task is holding. It's not hard to avoid such situations, but we couldn't find any way to statically or dynamically check that the "rules" aren't violated. >> And I don't want to >> instantiate a generic each time I need an event handler. > > Agreed, but I don't believe we're stuck with that solution. > All you need is procedure'Access for the callback. Claw solely uses OOP to support event handlers. There are no explicit callbacks, and there are no generics to instantiate. (But instantiating a generic probably involves less typing than deriving an OOP type). IMHO, events cannot and should not be separated from the associated objects. >> And I do want the compiler to check that all events are handled. > > Hmmm, more of a scope problem, I think. Your requirements may > be part of the problem. This is not a problem in Claw, as all relevant events are always handled by every object. It's only necessary to write new handlers if you need additional actions on an event, and that could never be checked statically (or even dynamically), as it is specific to the problem being solved. >>> Part of the difficulty is that something like a GUI takes >>> so much effort to develop. To get one developed to a >>> "standard level" would likely require some level of >>> sponsorship. Especially if you want to also attempt to >>> make it platform neutral. >> >> The main problem is the interface of such a library. There >> are multiple parallel hierarchies need to be handled: a >> hierarchy of widget types, a hierarchy of widget >> containers, > > There are some challenges there, but I don't believe the fact > that you need widget containers is a show stopper. I don't see it as a problem at all. The standard Ada containers will handle Claw objects just fine (that's one of the reasons that I was very interested in the indefinite containers). [Note: Almost all Claw objects -- including all types of windows -- are non-limited with cloning semantics.] >> a hierarchy of event handlers (events are >> filtered, propagated, swallowed, re-generated). > > Not a problem with the callback approach, AFAICS. Callbacks are unstructured and lead to unmanagable spaggeti code. The same is true in any case if events are separated from the associated objects; so none of the things Dmitry talks about make sense for sane event handling. It's the objects that cooperate, not the events. ... > It really comes down to what is "good enough" for a standard > GUI library. Your requirements are desirable, but with > existing software technologies, it doesn't appear practical > AFAICS. > > Are there any GUI systems implemented that are fully static > checked? I don't think that even makes sense. The overriding property of a GUI is that objects are being created and destroyed under control of the user of the application, *not* under the control of the application or its programmer. We treated the user of the application as a "virtual" task, with the application itself being a different task that cooperates with the first. There is little there that can be determined statically (even if we hadn't used dispatching to deliver events to objects). Randy. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 19:48 ` Properties Randy Brukardt @ 2010-12-01 21:10 ` Warren 2010-12-02 0:03 ` Properties Shark8 0 siblings, 1 reply; 94+ messages in thread From: Warren @ 2010-12-01 21:10 UTC (permalink / raw) Randy Brukardt expounded in news:id68q7$d66$1@munin.nbi.dk: > "Warren" <ve3wwg@gmail.com> wrote in message > news:Xns9E417369AD1F4WarrensBlatherings@81.169.183.62... >> Dmitry A. Kazakov expounded in >> news:1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net: >> >>> On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote: >>>> A library designed in Ada from the ground up, would be >>>> better. .. >>> And I don't want to >>> instantiate a generic each time I need an event handler. >> >> Agreed, but I don't believe we're stuck with that >> solution. All you need is procedure'Access for the >> callback. > > Claw solely uses OOP to support event handlers. There are > no explicit callbacks, and there are no generics to > instantiate. (But instantiating a generic probably involves > less typing than deriving an OOP type). IMHO, events cannot > and should not be separated from the associated objects. .. > Randy. Ya, that seems to be a sensible approach. It's hard for me to forget a lifetime of C-based brainwashing. ;-) Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 21:10 ` Properties Warren @ 2010-12-02 0:03 ` Shark8 2010-12-02 16:45 ` Properties Warren 0 siblings, 1 reply; 94+ messages in thread From: Shark8 @ 2010-12-02 0:03 UTC (permalink / raw) > Ya, that seems to be a sensible approach. It's hard for me to > forget a lifetime of C-based brainwashing. ;-) > > Warren The Unix-hater's Handbook has a nice chapter on C-based programming... I found the explanation of what C's "arrays" are to be most helpful in a [required] C class I took later. It's freely downloadable here: http://simson.net/ref/ugh.pdf ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 0:03 ` Properties Shark8 @ 2010-12-02 16:45 ` Warren 2010-12-02 17:32 ` Properties Dmitry A. Kazakov ` (3 more replies) 0 siblings, 4 replies; 94+ messages in thread From: Warren @ 2010-12-02 16:45 UTC (permalink / raw) Shark8 expounded in news:618677c8-a44f-443e-9052-a94fb48c999a@s4g2000yql.googlegro ups.com: >> Ya, that seems to be a sensible approach. It's hard for me >> to forget a lifetime of C-based brainwashing. ;-) >> >> Warren > > The Unix-hater's Handbook has a nice chapter on C-based > programming... I found the explanation of what C's "arrays" > are to be most helpful in a [required] C class I took > later. It's freely downloadable here: > http://simson.net/ref/ugh.pdf I am actually a fan of Unix/Linux. And C arrays/pointers must be groked early, if you want to survive the art of any serious C programming! But the text looks like an amusing read, so I'll read it on my commute home. It'll be interesting to see what some folks find to hate about Unix. The only detracting thing I find about it, is simply the fact that it is well steeped in C. But then, prior to Unix, O/S's were usually steeped in assembler language (like OS/2 for a modern example). C has been a big improvement in that regard. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 16:45 ` Properties Warren @ 2010-12-02 17:32 ` Dmitry A. Kazakov 2010-12-02 20:45 ` Properties Warren 2010-12-02 20:52 ` Properties Pascal Obry 2010-12-02 19:46 ` Properties Adam Beneschan ` (2 subsequent siblings) 3 siblings, 2 replies; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-02 17:32 UTC (permalink / raw) On Thu, 2 Dec 2010 16:45:16 +0000 (UTC), Warren wrote: > It'll be interesting to see what some folks find > to hate about Unix. Everything! I cannot figure out anything I didn't hate there. Hmm, maybe Open Look? Which is dead anyway. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 17:32 ` Properties Dmitry A. Kazakov @ 2010-12-02 20:45 ` Warren 2010-12-02 21:17 ` Properties Adam Beneschan 2010-12-03 3:34 ` Properties Shark8 2010-12-02 20:52 ` Properties Pascal Obry 1 sibling, 2 replies; 94+ messages in thread From: Warren @ 2010-12-02 20:45 UTC (permalink / raw) Dmitry A. Kazakov expounded in news:kr1k3b117xny$.1f3qb64m5z824$.dlg@40tude.net: > On Thu, 2 Dec 2010 16:45:16 +0000 (UTC), Warren wrote: > >> It'll be interesting to see what some folks find >> to hate about Unix. > > Everything! I cannot figure out anything I didn't hate > there. Hmm, maybe Open Look? Which is dead anyway. In my own experience, those who hate Unix generally are usually those from a non-Unix background who are in too big of a hurry to know it. It's like the pianist who hates guitar- now instead of playing a certain pitched G note in one place on the keyboard, he hates the fact that there is now multiple choice on the guitar. But those who've taken the time to learn guitar, see this as a feature. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 20:45 ` Properties Warren @ 2010-12-02 21:17 ` Adam Beneschan 2010-12-02 21:40 ` Properties Warren 2010-12-03 3:34 ` Properties Shark8 1 sibling, 1 reply; 94+ messages in thread From: Adam Beneschan @ 2010-12-02 21:17 UTC (permalink / raw) On Dec 2, 12:45 pm, Warren <ve3...@gmail.com> wrote: > It's like the pianist who hates guitar- now instead of playing > a certain pitched G note in one place on the keyboard, he > hates the fact that there is now multiple choice on the > guitar. But those who've taken the time to learn guitar, see > this as a feature. I understand what you're trying to get at, but the analogy seems really strained. As someone who started on piano and then took up cello later, I don't think that the "problem" you describe is really a problem at all. When you first learn, they just don't teach you that there is more than one way to play a note. There's one way to play a low G, and that's the open G string. By the time you're taught that you can also play it on the C string, you have enough experience that you know how to make use of the information. I'm sure it's pretty much the same way on guitar. It would strike me as odd for a pianist to "hate" guitar because of that, and it would be really bizarre for a beginning teacher to tell his students "There are two ways to play a G, and you have to guess which one whenever you see it". Now, the fact that the note you're actually playing is an octave lower than what you see on the page---*that's* a reason to hate it. :) -- Adam ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 21:17 ` Properties Adam Beneschan @ 2010-12-02 21:40 ` Warren 0 siblings, 0 replies; 94+ messages in thread From: Warren @ 2010-12-02 21:40 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2221 bytes --] Adam Beneschan expounded in news:a66255f6-d39b-4017-b89a-5bbc901649ec@m20g2000prc.googlegr oups.com: > On Dec 2, 12:45�pm, Warren <ve3...@gmail.com> wrote: > >> It's like the pianist who hates guitar- now instead of >> playing a certain pitched G note in one place on the >> keyboard, he hates the fact that there is now multiple >> choice on the guitar. But those who've taken the time to >> learn guitar, see this as a feature. > > I understand what you're trying to get at, but the analogy > seems really strained. As someone who started on piano and > then took up cello later, The cello is a somewhat different. You're not playing more than one or two strings at a time. On a 6-string, you may be playing all 6, though 3-4 are often enough for many chords. > ... I'm sure it's pretty much the same way on > guitar. It would strike me as odd for a pianist to "hate" > guitar because of that, It's not when you're playing guitar from "standard notation" (aka "piano notation"). The particular fret and string you choose for that higher G, depends a lot on the context of what is currently being played and where on the neck your hand is. On a keyboard, that G note (of a particular) pitch is only played from one key, ever. This is much simpler than the split second thinking about (as you play): - Is that string I normally play it on, already fretted for another simultaneous note? - Is that alternative practical for the fretting hand given the other notes that must be fretted (i.e. can I reach it)? Sure, with experience it starts to become second nature, but this is one of the main reasons that guitarists hate "standard notation". Many (most?), never learn to play from it (they use TAB instead). TAB is another matter entirely-- it is the compiled machine language to guitar performance by comparison. The fretting has already been worked out for you in TAB. TAB is to guitar, what standard notation is to keyboards. Agreed, the analogy is perhaps strained. The thrust of my point is simply that under Unix, it is often said that there are "several ways to skin a cat". -- No offense to cat lovers, which include my wife. A plethora of choice, complicates. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 20:45 ` Properties Warren 2010-12-02 21:17 ` Properties Adam Beneschan @ 2010-12-03 3:34 ` Shark8 2010-12-03 8:16 ` Properties Thomas Løcke 1 sibling, 1 reply; 94+ messages in thread From: Shark8 @ 2010-12-03 3:34 UTC (permalink / raw) On Dec 2, 1:45 pm, Warren <ve3...@gmail.com> wrote: > Dmitry A. Kazakov expounded innews:kr1k3b117xny$.1f3qb64m5z824$.dlg@40tude.net: > > > On Thu, 2 Dec 2010 16:45:16 +0000 (UTC), Warren wrote: > > >> It'll be interesting to see what some folks find > >> to hate about Unix. > > > Everything! I cannot figure out anything I didn't hate > > there. Hmm, maybe Open Look? Which is dead anyway. > > In my own experience, those who hate Unix generally are > usually those from a non-Unix background who are in too big of > a hurry to know it. Perhaps this is true in some degree; there are, however, some rather serious design flaws and deficiencies. One deficiency is/was the absence of a 'rename' command for files & directories; renaming is a VERY common procedure for anyone managing their files; instead of 'rename' one is to use 'move' to achieve similar effect... there is one HUGE problem with using move [because * expansion is required in all *nix shells] you cannot rename groups of files. ex: DOS -> Ren *.p *.pas -- Renaming all .p files to .pas *nix -> mv *.p *.pas -- becomes expanded... -> mv 1.p 2.p 3.p test.pas -- test.pas from the dir In my experience *nix OSes make doing something harder, not easier... somewhat like that person on your team who dragged their feet every step of the way. That is to say, the OS is not helpful in providing access to the resources of the computer. Shell-scripting is loads of fun* too. {*And by 'fun' I mean irritating, irregular, and surprisingly non-portable between different 'flavors'.} The following two-line script shows the POWER of *nix shell-scripts: #/bin/sh $0 & > It's like the pianist who hates guitar- now instead of playing > a certain pitched G note in one place on the keyboard, he > hates the fact that there is now multiple choice on the > guitar. But those who've taken the time to learn guitar, see > this as a feature. I beg to differ. There are plenty of reasons that *nix is horrid. {And I'm not saying this because "windows is better" or anything, windows has a hell-of-a- lot of faults...} The shell-scripting is one reason; why in the name of Chaos would someone want to use them [CSH or KSH or BASH]? In terms of power/ flexibility a LISP-based shell would be TONS more useful/managable... though, admitidly it would require that one thinks in recursion. The lack of types on files is another; old Macs had file-types down, but *nix has nothing like that (nor does it have even the capability for it, kernel-wise). {Windows has a [barely] workable file-extension/ association scheme -- analogous to an Ada map of (Key => File_Extention, Element => Application_Info).} Lack of file versioning.* {Unix, Mac, and Win => Lose. VMS => Win.} *File-versioning could save the arses of 90% of the lost/corrupted file problems that I've encountered with MS Word users. i.e. the "my kid selected the first twelve pages of my document and replaced it with 'gsosdpofij' and I saved over it!" instantly becomes recoverable. The FS as a "big bag-o-bytes" and the "EVERYTHING *IS* a file" mentalities of *nix are, in a single word, wrong. My display is NOT a file, nor should it be treated as such! {No, I would *not* like to "rm" my display!} One single hyphenated-word: man-pages. The old DOS hypertext help was superior to man=pages, windows .HLP file help was/is superior to man-pages, the OpenVMS help-system is FAR, FAR more usable than man-pages. Error codes? In *nix programs may or may not use them... (some programs return 0/success when errors were encountered) which makes them less than useless. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 3:34 ` Properties Shark8 @ 2010-12-03 8:16 ` Thomas Løcke 0 siblings, 0 replies; 94+ messages in thread From: Thomas Løcke @ 2010-12-03 8:16 UTC (permalink / raw) On 2010-12-03 04:34, Shark8 wrote: > Perhaps this is true in some degree; there are, however, some rather > serious design flaws and deficiencies. One deficiency is/was the > absence of a 'rename' command for files& directories; renaming is a > VERY common procedure for anyone managing their files; instead of > 'rename' one is to use 'move' to achieve similar effect... there is > one HUGE problem with using move [because * expansion is required in > all *nix shells] you cannot rename groups of files. > > ex: > DOS -> Ren *.p *.pas -- Renaming all .p files to .pas > *nix -> mv *.p *.pas -- becomes expanded... > -> mv 1.p 2.p 3.p test.pas -- test.pas from the dir Or you can use rename: $ rename .bak .txt *.bak That renames all your .bak files to .txt. The rename command has been part of the standard Linux tools for many years. It's also readily available for FreeBSD and I suspect other *BSD's as well. You're not forced to use mv to rename files. > Shell-scripting is loads of fun* too. {*And by 'fun' I mean > irritating, irregular, and surprisingly non-portable between different > 'flavors'.} The following two-line script shows the POWER of *nix > shell-scripts: > #/bin/sh > $0& A /bin/sh script is perfectly portable, if you intend to use it with the Bourne Shell. It's of course less portable if you try to use it with the C shell. > The shell-scripting is one reason; why in the name of Chaos would > someone want to use them [CSH or KSH or BASH]? In terms of power/ > flexibility a LISP-based shell would be TONS more useful/managable... > though, admitidly it would require that one thinks in recursion. If you don't like BASH, csh, zsh or Korn, then why not try something like BUSH: http://www.pegasoft.ca/bush.html It has a very Ada-like approach to shell scripting. > The lack of types on files is another; old Macs had file-types down, > but *nix has nothing like that (nor does it have even the capability > for it, kernel-wise). {Windows has a [barely] workable file-extension/ > association scheme -- analogous to an Ada map of (Key => > File_Extention, Element => Application_Info).} The "file" command is your friend. It just works, and it doesn't depend on some shaky dot extension scheme. Simple file->program association is handled well in both KDE and Gnome. I suspect other desktop environments have similar systems in place. I don't think this is a job for the kernel. > Lack of file versioning.* {Unix, Mac, and Win => Lose. VMS => Win.} > *File-versioning could save the arses of 90% of the lost/corrupted > file problems that I've encountered with MS Word users. i.e. the "my > kid selected the first twelve pages of my document and replaced it > with 'gsosdpofij' and I saved over it!" instantly becomes recoverable. Hardly the fault of *nix, but of the file system you're using. Or you could just use a VCS to track the directories and files that needs versioning. > One single hyphenated-word: man-pages. > The old DOS hypertext help was superior to man=pages, windows .HLP > file help was/is superior to man-pages, the OpenVMS help-system is > FAR, FAR more usable than man-pages. man rename man file What's wrong with that? It could not be any easier. Do you want to search for a specific word? man -K word or a phrase? man -K "my phrase" Or using apropos: man -k "determine file type" and you get: file [] (1) - determine file type It's easy, flexible and it works. > Error codes? In *nix programs may or may not use them... (some > programs return 0/success when errors were encountered) which makes > them less than useless. Hardly the fault of *nix, just as the abundance of horrible software for Windows cannot be blamed on Windows itself. -- Regards, Thomas L�cke Email: tl at ada-dk.org Web: http:ada-dk.org IRC nick: ThomasLocke ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 17:32 ` Properties Dmitry A. Kazakov 2010-12-02 20:45 ` Properties Warren @ 2010-12-02 20:52 ` Pascal Obry 1 sibling, 0 replies; 94+ messages in thread From: Pascal Obry @ 2010-12-02 20:52 UTC (permalink / raw) To: mailbox Le 02/12/2010 18:32, Dmitry A. Kazakov a �crit : > Everything! I cannot figure out anything I didn't hate there. Hmm, maybe > Open Look? Which is dead anyway. You are missing something then. Too bad! -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 16:45 ` Properties Warren 2010-12-02 17:32 ` Properties Dmitry A. Kazakov @ 2010-12-02 19:46 ` Adam Beneschan 2010-12-02 20:38 ` Properties Warren 2010-12-03 3:47 ` Properties Shark8 2010-12-03 0:09 ` Properties Robert A Duff 2010-12-03 15:40 ` Properties Warren 3 siblings, 2 replies; 94+ messages in thread From: Adam Beneschan @ 2010-12-02 19:46 UTC (permalink / raw) On Dec 2, 8:45 am, Warren <ve3...@gmail.com> wrote: > Shark8 expounded innews:618677c8-a44f-443e-9052-a94fb48c999a@s4g2000yql.googlegro > ups.com: > > >> Ya, that seems to be a sensible approach. It's hard for me > >> to forget a lifetime of C-based brainwashing. ;-) > > >> Warren > > > The Unix-hater's Handbook has a nice chapter on C-based > > programming... I found the explanation of what C's "arrays" > > are to be most helpful in a [required] C class I took > > later. It's freely downloadable here: > >http://simson.net/ref/ugh.pdf > > I am actually a fan of Unix/Linux. And C arrays/pointers must > be groked early, if you want to survive the art of any serious > C programming! > > But the text looks like an amusing read, so I'll read it on my > commute home. It'll be interesting to see what some folks find > to hate about Unix. The only detracting thing I find about it, > is simply the fact that it is well steeped in C. I couldn't actually find the part about arrays that Shark8 alluded to (although I didn't look very hard). However, I did find the section "Creators Admit C, Unix Were Hoax". > But then, prior to Unix, O/S's were usually steeped in > assembler language (like OS/2 for a modern example). C has > been a big improvement in that regard. Yes, the big disadvantage that assembler had over C was that, despite the fact that its mnemonics can be cryptic, they are actually based on English words and use real letters, which meant that there was a real possibility that the rookie programmer in the next cubicle might actually be able to understand and fix your program, leading to loss of job security. I think that was one of the problems C was designed to address. :) :) :) Just kidding! -- Adam ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 19:46 ` Properties Adam Beneschan @ 2010-12-02 20:38 ` Warren 2010-12-02 21:39 ` Properties Jeffrey Carter 2010-12-03 3:47 ` Properties Shark8 1 sibling, 1 reply; 94+ messages in thread From: Warren @ 2010-12-02 20:38 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1162 bytes --] Adam Beneschan expounded in news:4287748c-0962-4cd2-a36b-9dd7113267a6@21g2000prv.googlegro ups.com: > On Dec 2, 8:45�am, Warren <ve3...@gmail.com> wrote: >> Shark8 expounded >> But then, prior to Unix, O/S's were usually steeped in >> assembler language (like OS/2 for a modern example). �C >> has been a big improvement in that regard. > > Yes, the big disadvantage that assembler had over C was > that, despite the fact that its mnemonics can be cryptic, > they are actually based on English words and use real > letters, which meant that there was a real possibility that > the rookie programmer in the next cubicle might actually be > able to understand and fix your program, leading to loss > of job security. I think that was one of the problems C > was designed to address. > >:) :) :) Just kidding! > > -- Adam Joking aside, C allowed the compiler to work on behalf of a programmer's higher level intentions, without making assembler level errors. Ada could be said that it allows the [Ada] compiler to work on behalf of the programmer's higher level intentions, without making C level errors. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 20:38 ` Properties Warren @ 2010-12-02 21:39 ` Jeffrey Carter 2010-12-02 21:55 ` Properties Warren 2010-12-03 9:33 ` Properties Anonymous 0 siblings, 2 replies; 94+ messages in thread From: Jeffrey Carter @ 2010-12-02 21:39 UTC (permalink / raw) Shark8 wrote: > > But then, prior to Unix, O/S's were usually steeped in > assembler language (like OS/2 for a modern example). C > has been a big improvement in that regard. OS/2 "prior to Unix"? Unix dates from ~1970, OS/2 the 1980s. What I find funny is that the alternatives to Windows are all versions of Unix. Unix is hardly perfect; you'd think we'd have come up with something better by now. -- Jeff Carter "Well, a gala day is enough for me. I don't think I can handle any more." Duck Soup 93 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 21:39 ` Properties Jeffrey Carter @ 2010-12-02 21:55 ` Warren 2010-12-03 9:33 ` Properties Anonymous 1 sibling, 0 replies; 94+ messages in thread From: Warren @ 2010-12-02 21:55 UTC (permalink / raw) Jeffrey Carter expounded in news:id93pc$qf9$1@tornado.tornevall.net: > Shark8 wrote: >> >> But then, prior to Unix, O/S's were usually steeped in >> assembler language (like OS/2 for a modern example). C >> has been a big improvement in that regard. > > OS/2 "prior to Unix"? Unix dates from ~1970, OS/2 the > 1980s. Yes. I never said _anything_ about OS/2 predating Unix. What I did say was that OS/2 was as a modern example of an asm version of an O/S. Sheesh. Didn't you read the word "modern"? > What I find funny is that the alternatives to Windows are > all versions of Unix. Unix is hardly perfect; you'd think > we'd have come up with something better by now. Agreed that Unix has imprefections but at least it was "designed" with some peer review. MS stuff just gets "marketing review" and pushed out the door with a "look what we can do?" approach. Everyone told them ActiveX over the internet was a bad idea. It tooks years for that lesson to sink in. It would be interesting to know more about what NT was designed like, before MS bastardized it, to make it compatible with prior Windows APIs. I've never worked with VMS, but folks that have seem to have really liked it. More recently, I've personally liked the idea of an Ada mach kernel myself, and even did some work on one once (RTMK I think it was). But I'm too old to follow through on something that huge. That is a Linux type of project in need of a young university grad with energy and enthusiasm. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 21:39 ` Properties Jeffrey Carter 2010-12-02 21:55 ` Properties Warren @ 2010-12-03 9:33 ` Anonymous 1 sibling, 0 replies; 94+ messages in thread From: Anonymous @ 2010-12-03 9:33 UTC (permalink / raw) > Jeff Carter You're someone worth listening to so I was surprised to read your comment. What's wrong with UNIX for PC use? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 19:46 ` Properties Adam Beneschan 2010-12-02 20:38 ` Properties Warren @ 2010-12-03 3:47 ` Shark8 1 sibling, 0 replies; 94+ messages in thread From: Shark8 @ 2010-12-03 3:47 UTC (permalink / raw) On Dec 2, 12:46 pm, Adam Beneschan <a...@irvine.com> wrote: > On Dec 2, 8:45 am, Warren <ve3...@gmail.com> wrote: > > > > > Shark8 expounded innews:618677c8-a44f-443e-9052-a94fb48c999a@s4g2000yql.googlegro > > ups.com: > > > >> Ya, that seems to be a sensible approach. It's hard for me > > >> to forget a lifetime of C-based brainwashing. ;-) > > > >> Warren > > > > The Unix-hater's Handbook has a nice chapter on C-based > > > programming... I found the explanation of what C's "arrays" > > > are to be most helpful in a [required] C class I took > > > later. It's freely downloadable here: > > >http://simson.net/ref/ugh.pdf > > > I am actually a fan of Unix/Linux. And C arrays/pointers must > > be groked early, if you want to survive the art of any serious > > C programming! > > > But the text looks like an amusing read, so I'll read it on my > > commute home. It'll be interesting to see what some folks find > > to hate about Unix. The only detracting thing I find about it, > > is simply the fact that it is well steeped in C. > > I couldn't actually find the part about arrays that Shark8 alluded to > (although I didn't look very hard). However, I did find the section > "Creators Admit C, Unix Were Hoax". > > > But then, prior to Unix, O/S's were usually steeped in > > assembler language (like OS/2 for a modern example). C has > > been a big improvement in that regard. > > Yes, the big disadvantage that assembler had over C was that, despite > the fact that its mnemonics can be cryptic, they are actually based on > English words and use real letters, which meant that there was a real > possibility that the rookie programmer in the next cubicle might > actually be able to understand and fix your program, leading to loss > of job security. I think that was one of the problems C was designed > to address. > > :) :) :) Just kidding! > > -- Adam Interesting you should mention that; I got into a discussion elsewhere about OSes and the influence of the programming languages they're developed in. One of the people in the discussion did an analysis/ recommendation for Microsoft right after windows came out... their recommendation was to re-encoded in Ada. ...and on the note of 'job security,' on that same discussion was posted this link: http://www-users.cs.york.ac.uk/~susan/joke/cpp.htm ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 16:45 ` Properties Warren 2010-12-02 17:32 ` Properties Dmitry A. Kazakov 2010-12-02 19:46 ` Properties Adam Beneschan @ 2010-12-03 0:09 ` Robert A Duff 2010-12-03 15:49 ` Properties Warren 2010-12-03 15:40 ` Properties Warren 3 siblings, 1 reply; 94+ messages in thread From: Robert A Duff @ 2010-12-03 0:09 UTC (permalink / raw) Warren <ve3wwg@gmail.com> writes: > But the text looks like an amusing read, so I'll read it on my > commute home. It is amusing, both the parts I agree with and the parts I disagree with. >...It'll be interesting to see what some folks find > to hate about Unix. There's lots to hate about Unix. There's lots to hate about other operating systems, too. I switch back&forth between Linux and Windows all the time, and I definitely prefer Linux. But I still hate it. >...The only detracting thing I find about it, > is simply the fact that it is well steeped in C. Well, that's sort of like saying "The only thing to dislike about the Atlantic Ocean is that it's got seawater in it". ;-) I don't think C would have gone anywhere without riding on the back of Unix. An operating system shouldn't be heavily biased toward writing user-mode programs in the same language as the OS. Unix is. Some others are better in that regard. VMS, for example. (But there's a lot about VMS I don't like.) I mean, defining system call interfaces as .h files is just a bad way to do things. VMS is better in that regard. - Bob ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 0:09 ` Properties Robert A Duff @ 2010-12-03 15:49 ` Warren 2010-12-03 20:07 ` Properties Shark8 0 siblings, 1 reply; 94+ messages in thread From: Warren @ 2010-12-03 15:49 UTC (permalink / raw) Robert A Duff expounded in news:wccvd3bu37w.fsf@shell01.TheWorld.com: > Warren <ve3wwg@gmail.com> writes: > >> But the text looks like an amusing read, so I'll read it >> on my commute home. > > It is amusing, both the parts I agree with and the parts > I disagree with. It was an amusing walk down memory lane. I remember many of the struggles mentioned there. > There's lots to hate about Unix. There's lots to hate > about other operating systems, too. I switch back&forth > between Linux and Windows all the time, and I definitely > prefer Linux. But I still hate it. I guess I hate Windows so much, that I love Unix by comparison. I really hate MS software design. Every API item is shoe horned into a WORD, DWORD or some basterized pointer to some such. Why couldn't they take the time to put some real C++ types (if they're going to use C++) around these things? Cheeze Louise! And drop that Hungarian notation, for crying out loud. > Well, that's sort of like saying "The only thing to > dislike about the Atlantic Ocean is that it's got > seawater in it". ;-) Sharks. If only if it didn't have Sharks. ;-) > I mean, defining system call interfaces as .h files > is just a bad way to do things. VMS is better in that > regard. > > - Bob I really like the Ada package approach. I was never really fond of that whole .h shuffle, and cpp macros. I was ok with my own macros but working with other ppl's macros isn't so fun. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 15:49 ` Properties Warren @ 2010-12-03 20:07 ` Shark8 2010-12-06 21:01 ` Properties Warren 0 siblings, 1 reply; 94+ messages in thread From: Shark8 @ 2010-12-03 20:07 UTC (permalink / raw) On Dec 3, 8:49 am, Warren <ve3...@gmail.com> wrote: > Robert A Duff expounded innews:wccvd3bu37w.fsf@shell01.TheWorld.com: > > I really hate MS software design. Every API item is shoe > horned into a WORD, DWORD or some basterized pointer to some > such. Why couldn't they take the time to put some real C++ > types (if they're going to use C++) around these things? > Cheeze Louise! And drop that Hungarian notation, for crying > out loud. > > Warren I defiantly agree with the Hungarian notation. The argument could be made that if they were going to spend the time/ energy to use "real C++ types" they would have been better off doing it in Ada where the strong typing would help; IMO, C++ encourages the disuse/misuse of types. I agree with you about the WORD, DWORD, pointer thing. It would be better to have actual types with actual parameters/fields... but then the same could be said about the 'typless' FSes for *nix and windows; instead of treating every file as a bag-o-bytes it would be better to have the files-themselves store that information -- yes, the latter method makes it 'harder' for you to open that midi file with notepad so you can do a quick "hex"-edit... but it also means that users can't screw up your system by forgetting the extension in a rename [win] or forcing the OS to run some file-checker on the file to determine its type. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 20:07 ` Properties Shark8 @ 2010-12-06 21:01 ` Warren 2010-12-06 23:22 ` Properties Shark8 2010-12-06 23:43 ` Properties Randy Brukardt 0 siblings, 2 replies; 94+ messages in thread From: Warren @ 2010-12-06 21:01 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2538 bytes --] Shark8 expounded in news:066181c0-9b80-4c17-a7b4-7ef28a297ea4@e16g2000pri.googlegr oups.com: > On Dec 3, 8:49�am, Warren <ve3...@gmail.com> wrote: >> I really hate MS software design. �Every API item is shoe >> horned into a WORD, DWORD or some basterized pointer to >> some such. �Why couldn't they take the time to put some >> real C++ types (if they're going to use C++) around these >> things? � Cheeze Louise! �And drop that Hungarian >> notation, for crying out loud. >> >> Warren > > I defiantly agree with the Hungarian notation. <tossed cookies> followed by <dry heaves> The type declaration carrys the type information. It does NOT belong in the name (of the variable). It creates a maintenance nightmare also -- change the type and all instances of the name must be changed. BLECH. > The argument could be made that if they were going to spend > the time/ energy to use "real C++ types" they would have > been better off doing it in Ada where the strong typing > would help; That's academic- but they did use C++. > IMO, C++ encourages the disuse/misuse of types. If you're going to use C++, then don't dumb it down to dumbest unspecified types. That's like taking a sports car and using those dumb little spare tires that limp you home. > I agree with you about the WORD, DWORD, pointer thing. It > would be better to have actual types with actual > parameters/fields... Yes. Every event and API is usually specific enough for real type definitions. > but then the same could be said about > the 'typless' FSes for *nix and windows That is something different. A "file" is a perfectly generic container of information. Do you want to allow your software to decide the format? Or would you prefer the OS to do it instead? Something must decide. Prior to Unix, everything was a unit record of some sort. It still is on the non-UNIX (non-hierarchical) parts of a mainframe: //DATAOUT DD DSN=M0DXYZ.DATA, // DISP=(NEW,CATLG,DELETE), // SPACE=(TRK,(10,10),RLSE), // DCB=(RECFM=FB,LRECL=23,BUFNO=10,OPTCD=C) Do you want to go back to specifying all these file attributes? RECFM=? LRECL=? BLKSIZE=? bLECH. Not to mention it complicates ftp transfers etc. : LOCSITE LRECL=80 RECFM=FB BLOCKSIZE=320 CYLINDERS \ PRIMARY=2 SECONDARY=2 Blexhch. One of the best things about Unix is that it finally tossed aside all of these silly hinderances. Everything since has copied this thinking. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-06 21:01 ` Properties Warren @ 2010-12-06 23:22 ` Shark8 2010-12-07 14:37 ` Properties Warren 2010-12-08 21:13 ` Properties Simon Wright 2010-12-06 23:43 ` Properties Randy Brukardt 1 sibling, 2 replies; 94+ messages in thread From: Shark8 @ 2010-12-06 23:22 UTC (permalink / raw) > > I defiantly agree with the Hungarian notation. > > <tossed cookies> followed by <dry heaves> > > The type declaration carrys the type information. It does NOT > belong in the name (of the variable). It creates a > maintenance nightmare also -- change the type and all > instances of the name must be changed. > > BLECH. Eh, my mistake, I meant to say "I defiantly agree with you on the Hungarian notation." > > I agree with you about the WORD, DWORD, pointer thing. It > > would be better to have actual types with actual > > parameters/fields... > > Yes. Every event and API is usually specific enough for real > type definitions. > > > but then the same could be said about > > the 'typless' FSes for *nix and windows > > That is something different. A "file" is a perfectly generic > container of information. Do you want to allow your software > to decide the format? Or would you prefer the OS to do it > instead? Something must decide. Er, I think you misunderstand what I mean by "typed files" very often "the software" does NOT & should NOT decide the format; if that were the case then "the software" could say "my HTML file writer doesn't need ending tags!" or "I don't need to write the header for an .ICO file!" which misses the whole point of having a specified standard. IOW, the type of a file, having some definition, SHOULD ensure that the file has the correct layout... like Access ensures that our "pointer" *IS* to a variable of the specified type. > Prior to Unix, everything was a unit record of some sort. It > still is on the non-UNIX (non-hierarchical) parts of a > mainframe: > > //DATAOUT DD DSN=M0DXYZ.DATA, > // DISP=(NEW,CATLG,DELETE), > // SPACE=(TRK,(10,10),RLSE), > // DCB=(RECFM=FB,LRECL=23,BUFNO=10,OPTCD=C) > > Do you want to go back to specifying all these file > attributes? RECFM=? LRECL=? BLKSIZE=? bLECH. Not to > mention it complicates ftp transfers etc. : > > LOCSITE LRECL=80 RECFM=FB BLOCKSIZE=320 CYLINDERS \ > PRIMARY=2 SECONDARY=2 > > Blexhch. It actually makes a lot of sense to be able to have some sort of "unit record" in files, especially if you are dealing with databases and, in that case, units should be able to be individually locked. As for specifying all the little attributes of some file, why not treat it the same way I do in Ada: unless there is some specific reason to do otherwise [like hardware interfacing] let the compiler choose the attributes of the type like 'Size, 'Bit_Order? > > One of the best things about Unix is that it finally tossed > aside all of these silly hinderances. Everything since has > copied this thinking. Just because everything copies the thinking neither means that the thinking is correct or useful. (Though it doesn't mean that it's wrong or useless either.) ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-06 23:22 ` Properties Shark8 @ 2010-12-07 14:37 ` Warren 2010-12-08 21:13 ` Properties Simon Wright 1 sibling, 0 replies; 94+ messages in thread From: Warren @ 2010-12-07 14:37 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1849 bytes --] Shark8 expounded in news:923f0664-890d-4ca9-9b34-2da64067b068@21g2000prv.googlegro ups.com: >> > I defiantly agree with the Hungarian notation. >> >> <tossed cookies> followed by <dry heaves> >> >> The type declaration carrys the type information. It does >> NOT belong in the name (of the variable). �It creates a � >> maintenance nightmare also -- change the type and all >> instances of the name must be changed. � >> >> BLECH. > > Eh, my mistake, I meant to say "I defiantly agree with you > on the Hungarian notation." Ah, ok... you're forgiven. ;-) >> That is something different. A "file" is a perfectly >> generic container of information. Do you want to allow >> your software to decide the format? Or would you prefer >> the OS to do it instead? �Something must decide. > > Er, I think you misunderstand what I mean by "typed files" > very often "the software" does NOT & should NOT decide the > format; if that were the case then "the software" could say > "my HTML file writer doesn't need ending tags!" or "I don't > need to write the header for an .ICO file!" which misses > the whole point of having a specified standard. > > IOW, the type of a file, having some definition, SHOULD > ensure that the file has the correct layout... like Access > ensures that our "pointer" *IS* to a variable of the > specified type. I guess, I don't understand your point. The software creating the "content" is doing it in a format, which often varies record by record, even in binary (yours is a text example). > Just because everything copies the thinking neither means > that the thinking is correct or useful. (Though it doesn't > mean that it's wrong or useless either.) Agreed, but you have ask why this is "successful". Usually, there are good reasons for it. Then again, C/C++ is a bad counter example. ;-) Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-06 23:22 ` Properties Shark8 2010-12-07 14:37 ` Properties Warren @ 2010-12-08 21:13 ` Simon Wright 2010-12-09 1:21 ` Properties Shark8 1 sibling, 1 reply; 94+ messages in thread From: Simon Wright @ 2010-12-08 21:13 UTC (permalink / raw) Shark8 <onewingedshark@gmail.com> writes: > Eh, my mistake, I meant to say "I defiantly agree with you on the > Hungarian notation." Do you actually mean 'defiantly'? or perhaps 'definitely'? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-08 21:13 ` Properties Simon Wright @ 2010-12-09 1:21 ` Shark8 0 siblings, 0 replies; 94+ messages in thread From: Shark8 @ 2010-12-09 1:21 UTC (permalink / raw) On Dec 8, 2:13 pm, Simon Wright <si...@pushface.org> wrote: > Shark8 <onewingedsh...@gmail.com> writes: > > Eh, my mistake, I meant to say "I defiantly agree with you on the > > Hungarian notation." > > Do you actually mean 'defiantly'? or perhaps 'definitely'? The latter. {Spell-checker is not always your friend.} ;) ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-06 21:01 ` Properties Warren 2010-12-06 23:22 ` Properties Shark8 @ 2010-12-06 23:43 ` Randy Brukardt 2010-12-07 0:56 ` Properties Jeffrey Carter ` (2 more replies) 1 sibling, 3 replies; 94+ messages in thread From: Randy Brukardt @ 2010-12-06 23:43 UTC (permalink / raw) "Warren" <ve3wwg@gmail.com> wrote in message news:Xns9E46A316BB94AWarrensBlatherings@81.169.183.62... > Shark8 expounded in > news:066181c0-9b80-4c17-a7b4-7ef28a297ea4@e16g2000pri.googlegr > oups.com: ... >> The argument could be made that if they were going to spend >> the time/ energy to use "real C++ types" they would have >> been better off doing it in Ada where the strong typing >> would help; > > That's academic- but they did use C++. So far as I know, Win32 is written in C. I'm pretty sure about that, since Claw interfaces only using C (Stdcall) interfaces. There are a few recent parts of Win32 that have C++ counterparts, but the majority of it was designed before there was any such thing as C++ (most of it is a copy of Win16, after all). Thus the bizarre notations. Randy. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-06 23:43 ` Properties Randy Brukardt @ 2010-12-07 0:56 ` Jeffrey Carter 2010-12-07 11:23 ` Properties Maciej Sobczak 2010-12-07 14:39 ` Properties Warren 2 siblings, 0 replies; 94+ messages in thread From: Jeffrey Carter @ 2010-12-07 0:56 UTC (permalink / raw) On 12/06/2010 04:43 PM, Randy Brukardt wrote: > > So far as I know, Win32 is written in C. I'm pretty sure about that, since > Claw interfaces only using C (Stdcall) interfaces. There are a few recent > parts of Win32 that have C++ counterparts, but the majority of it was > designed before there was any such thing as C++ (most of it is a copy of > Win16, after all). Thus the bizarre notations. I'm not sure you can make that claim ("the majority of it was designed before there was any such thing as C++"). C++ dates from 1982; Windows came later. -- Jeff Carter "This scene's supposed to be in a saloon, but the censor cut it out. It'll play just as well this way." [in a soda fountain] Never Give a Sucker an Even Break 113 ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-06 23:43 ` Properties Randy Brukardt 2010-12-07 0:56 ` Properties Jeffrey Carter @ 2010-12-07 11:23 ` Maciej Sobczak 2010-12-07 11:51 ` Properties Georg Bauhaus 2010-12-07 14:39 ` Properties Warren 2 siblings, 1 reply; 94+ messages in thread From: Maciej Sobczak @ 2010-12-07 11:23 UTC (permalink / raw) On Dec 7, 12:43 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > > That's academic- but they did use C++. > > So far as I know, Win32 is written in C. I'm pretty sure about that, since > Claw interfaces only using C (Stdcall) interfaces. That doesn't mean anything. It might as well be written in Ada and pragma Export everything to meet the "lowest denominator" at the C level. It might as well be written in assembler. And so on. As a demonstration that this can be a reasonable approach, the YAMI4 core library was written in C++ (to benefit from namespaces, encapsulation, and access control), but exports its interface in terms of extern "C". This interface is used as a basis for the Ada part. Technically, exactly the same approach might have been used in the Win32-Claw stack. Without you knowing about it. ;-) I don't claim that this is actually the case, but this is a) demonstrably possible and b) it even makes perfect sense from the engineering perspective. And in fact, the following might be an answer: http://www2.research.att.com/~bs/applications.html (scroll down to the bullet devoted to Microsoft) -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-07 11:23 ` Properties Maciej Sobczak @ 2010-12-07 11:51 ` Georg Bauhaus 2010-12-07 15:35 ` Properties Maciej Sobczak 0 siblings, 1 reply; 94+ messages in thread From: Georg Bauhaus @ 2010-12-07 11:51 UTC (permalink / raw) On 07.12.10 12:23, Maciej Sobczak wrote: > As a demonstration that this can be a reasonable approach, the YAMI4 > core library was written in C++ (to benefit from namespaces, > encapsulation, and access control), but exports its interface in terms > of extern "C". This interface is used as a basis for the Ada part. > Technically, exactly the same approach might have been used in the > Win32-Claw stack. Without you knowing about it. ;-) > > I don't claim that this is actually the case, but this is a) > demonstrably possible and b) it even makes perfect sense from the > engineering perspective. I'm curious about the engineering perspective, the one that prefers a "lowest denominator" in the style of extern "C". To me this seems like the prime example of effective software management: Attract more people by requiring a seemingly minimal programming approach. Will it help them, in the long run, to become attracted to more modern concepts like explicit modules (packages, classes, ADTs)? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-07 11:51 ` Properties Georg Bauhaus @ 2010-12-07 15:35 ` Maciej Sobczak 2010-12-07 17:02 ` Properties Georg Bauhaus 0 siblings, 1 reply; 94+ messages in thread From: Maciej Sobczak @ 2010-12-07 15:35 UTC (permalink / raw) On Dec 7, 12:51 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote: > > I don't claim that this is actually the case, but this is a) > > demonstrably possible and b) it even makes perfect sense from the > > engineering perspective. > > I'm curious about the engineering perspective, the > one that prefers a "lowest denominator" in the > style of extern "C". The "lowest denominator" is not just preferred, it is actually imposed by market forces. Imagine, for example, that Win32 exposed its interfaces as C++. Or C#. Would you be able to use it from Ada? No. Would you be able to use it from Java? No. The other way round: imagine a general-purpose operating system written in Ada that did not bother to export its interfaces as C. Would it become an attractive and popular development platform? No. These are the forces that make the "lowest denominator" not just preferred, but obligatory. Ignore this fact and you will be... ignored. > To me this seems like the prime example of effective > software management: Attract more people by requiring > a seemingly minimal programming approach. I don't claim that this "lowest denominator" is good. I only claim that there is no alternative. The only improvement that I'm aware of involves traveling back in time and reinventing the IT industry. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-07 15:35 ` Properties Maciej Sobczak @ 2010-12-07 17:02 ` Georg Bauhaus 0 siblings, 0 replies; 94+ messages in thread From: Georg Bauhaus @ 2010-12-07 17:02 UTC (permalink / raw) On 07.12.10 16:35, Maciej Sobczak wrote: > I don't claim that this "lowest denominator" is good. > I only claim that there is no alternative. > > The only improvement that I'm aware of involves traveling back in time > and reinventing the IT industry. I see; yet Microsoft seems to have moved its software towards objects. If .NET is a sign of objects and if .NET, Java and iOS shape future programmers, maybe IT can travel forwards. There is a gap between modeling tools' presentation of the world (using objects' interfaces) and the way they appear in extern "C" style programs (implicit, mostly). This is contradictory, I think, but then contradictions impose no strain on a programmer's mind when he can switch world views by switching tools. Odd it is, though. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-06 23:43 ` Properties Randy Brukardt 2010-12-07 0:56 ` Properties Jeffrey Carter 2010-12-07 11:23 ` Properties Maciej Sobczak @ 2010-12-07 14:39 ` Warren 2 siblings, 0 replies; 94+ messages in thread From: Warren @ 2010-12-07 14:39 UTC (permalink / raw) Randy Brukardt expounded in news:idjsen$hg9$1@munin.nbi.dk: > "Warren" <ve3wwg@gmail.com> wrote in message > news:Xns9E46A316BB94AWarrensBlatherings@81.169.183.62... >> Shark8 expounded in >> news:066181c0-9b80-4c17-a7b4-7ef28a297ea4@e16g2000pri.googl >> egr oups.com: > ... >>> The argument could be made that if they were going to >>> spend the time/ energy to use "real C++ types" they would >>> have been better off doing it in Ada where the strong >>> typing would help; >> >> That's academic- but they did use C++. > > So far as I know, Win32 is written in C. I'm pretty sure > about that, since Claw interfaces only using C (Stdcall) > interfaces. There are a few recent parts of Win32 that have > C++ counterparts, but the majority of it was designed > before there was any such thing as C++ (most of it is a > copy of Win16, after all). Thus the bizarre notations. > > Randy. I was thinking about the MFC classes, which are C++. IIRC, there were still WORD and DWORD components within that. But its been years since I've looked. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-02 16:45 ` Properties Warren ` (2 preceding siblings ...) 2010-12-03 0:09 ` Properties Robert A Duff @ 2010-12-03 15:40 ` Warren 2010-12-03 19:56 ` Properties Shark8 3 siblings, 1 reply; 94+ messages in thread From: Warren @ 2010-12-03 15:40 UTC (permalink / raw) Warren expounded in news:Xns9E4277935FF91WarrensBlatherings@85.214.73.210: > Shark8 expounded in > news:618677c8-a44f-443e-9052-a94fb48c999a@s4g2000yql.googleg > ro ups.com: .. >> The Unix-hater's Handbook has a nice chapter on C-based >> programming... I found the explanation of what C's >> "arrays" are to be most helpful in a [required] C class I >> took later. It's freely downloadable here: >> http://simson.net/ref/ugh.pdf > > I am actually a fan of Unix/Linux. And C arrays/pointers > must be groked early, if you want to survive the art of any > serious C programming! > > But the text looks like an amusing read, so I'll read it on > my commute home. ... I got through about half of it last night. It took me down memory lane with some snickers. Ya, there are some justifiable rants about warts etc. But Unix still appears king of the hill. At least until something better comes along. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 15:40 ` Properties Warren @ 2010-12-03 19:56 ` Shark8 2010-12-03 20:12 ` Properties Warren 0 siblings, 1 reply; 94+ messages in thread From: Shark8 @ 2010-12-03 19:56 UTC (permalink / raw) On Dec 3, 8:40 am, Warren <ve3...@gmail.com> wrote: > Warren expounded innews:Xns9E4277935FF91WarrensBlatherings@85.214.73.210: > > But Unix still appears king of the hill. At least until > something better comes along. > > Warren And I'd love to be able to produce that "something better"... bonus "satisfaction points" if it uses Ada exclusively (partially to show up the CS dept of my university where everyone seems to think "You can't make a [good] OS without C/C++"). ;) ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 19:56 ` Properties Shark8 @ 2010-12-03 20:12 ` Warren 0 siblings, 0 replies; 94+ messages in thread From: Warren @ 2010-12-03 20:12 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1131 bytes --] Shark8 expounded in news:f2d78fc4-9918-4df3-8771-45e7f7fd8f67@p11g2000vbn.googlegr oups.com: > On Dec 3, 8:40�am, Warren <ve3...@gmail.com> wrote: >> Warren expounded >> innews:Xns9E4277935FF91WarrensBlatherings@85.214.73.210: >> >> But Unix still appears king of the hill. At least until >> something better comes along. >> >> Warren > > And I'd love to be able to produce that "something > better"... bonus "satisfaction points" if it uses Ada > exclusively (partially to show up the CS dept of my > university where everyone seems to think "You can't make a > [good] OS without C/C++"). > > ;) Start on your proof of concept, get a following of loyal "I can't wait to contribute to your OS" volunteers, get some sort of industry buy in and then Bob's your uncle. But the challenge this time around is that there are not enough people who are hungry for a free O/S, since Linux is already there and "good enough". Then they need to use Ada, and then you need OS specific device drivers etc..... That it why it needs someone with a LOT of energy and drive! And someone young enough to endure it all. Warren ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-01 15:59 ` Properties Dmitry A. Kazakov 2010-12-01 16:20 ` Properties Warren @ 2010-12-03 5:53 ` Shark8 2010-12-03 9:05 ` Properties Dmitry A. Kazakov 1 sibling, 1 reply; 94+ messages in thread From: Shark8 @ 2010-12-03 5:53 UTC (permalink / raw) On Dec 1, 8:59 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: >The main problem is the interface of such a library. There are >multiple parallel hierarchies need to be handled: a hierarchy >of widget types, a hierarchy of widget containers, a hierarchy >of event handlers (events are filtered, propagated, swallowed, >re-generated). > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de Why not have an INTERFACE hierarchy in addition to the GUI_Object hierarchy? This would allow for an easy way for foreign-language objects to be incorporated, to some extent, into applications which use this hypothetical library.... with only the added encumberment of forcing more up-front design. (Usu. a good thing.) Additionally, it could help with keeping the GUI_Object hierarchy smaller as there are many GUI items which are themselves composed of other GUI items. A scroll-bar, for example, has two distinct interfaces: the Button[s] and the slider-bar. The event-handler hierarchy seems to be the most 'interesting', not because of the events themselves, but because of the problem of how best to hook them; as you said they can be consumed, passed-through, emitted, and so-forth. They should, therefore be lightweight (as we don't want to transmit unnecessary information), quick in construction (this will impact the GUIs responsiveness) and clean in destruction (no memory leaks, please). By "widget containers" do you mean something like Ada.Containers.Vectors initialized to the classwide-type of the root of the GUI_Object hierarchy, OR do you mean some component which contains other components (like a panel, perhaps)? {I'm inclined to believe you meant the latter.} Finally, I've been quite impressed with Delphi's Visual Component Library (VCL). Microsoft's MFC and Java's JFC seem to have been 'inspired' [or copied] from the VCL, but neither presents itself as uniform & usable/mature [if you will] as the VCL. While the VCL doesn't use interfaces it does make nice use of properties; event handlers are get/set w/ properties and handlers are not required to be installed for every object like they are in Java; I believe that internally Delphi uses something like this: If Assigned(Handler) Then Handler^(Sender); {Assigned tests for null.} ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 5:53 ` Properties Shark8 @ 2010-12-03 9:05 ` Dmitry A. Kazakov 2010-12-03 19:52 ` Properties Shark8 0 siblings, 1 reply; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-03 9:05 UTC (permalink / raw) On Thu, 2 Dec 2010 21:53:13 -0800 (PST), Shark8 wrote: > On Dec 1, 8:59�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >>The main problem is the interface of such a library. There are >>multiple parallel hierarchies need to be handled: a hierarchy >>of widget types, a hierarchy of widget containers, a hierarchy >>of event handlers (events are filtered, propagated, swallowed, >>re-generated). >> > Why not have an INTERFACE hierarchy in addition to the GUI_Object > hierarchy? Hmm, isn't it same? To me interface = abstract type. > Additionally, it could help with keeping the GUI_Object hierarchy > smaller as there are many GUI items which are themselves composed of > other GUI items. A scroll-bar, for example, has two distinct > interfaces: the Button[s] and the slider-bar. Ada should have had proper multiple inheritance 15 years ago. > By "widget containers" do you mean something like > Ada.Containers.Vectors initialized to the classwide-type of the root > of the GUI_Object hierarchy, OR do you mean some component which > contains other components (like a panel, perhaps)? {I'm inclined to > believe you meant the latter.} Yes, the latter, but the former is also required, you frequently need lists of widgets (of referential semantics). This raises another question. Ada does not support abstract access types. You want a reference to the widget be a fat pointer transparent to all widget operations with automatic collection of widget objects. This almost works in Ada, but it is extremely boring to do. The scheme is as follows: 1. You declare a separate interface type for each widget 2. You implement the interface by the widget object 3. You implement the interface by the handle to the widget (a controlled type). It is nightmare to do, I know it. I did so in one project (not for the widgets), and I don't want this adventure anymore. The bottom line, interfaces must be removed from Ada. Instead of that an interface must be made inheritable from any concrete type. This is the same idea as with abstract record, array etc types. Any type has interface, which is inheritable without the implementation: type Widget_Handle is private Widget; -- Like the widget, but isn't private type Widget_Handle is new Ada.Limited_Controlled with record Ptr : access Widget; end record; For access types there must be delegation support, which should eliminate need in wrappers. There are other issues as well, like that "access Widget" is purposely not "access Widget'Class." > Finally, I've been quite impressed with Delphi's Visual Component > Library (VCL). That's interesting, because we are using the VCL quite heavily. One of our customers explicitly ordered that. Now, my impression is opposite to yours: it is safer, *quicker*, cleaner, an far more maintainable to develop GUI in *raw* Windows API than in VCL. As a bonus, you can get rid of that awful Borland C++, use VC++ or gcc instead. > Microsoft's MFC and Java's JFC seem to have been > 'inspired' [or copied] from the VCL, but neither presents itself as > uniform & usable/mature [if you will] as the VCL. We dropped MFC long ago and never returned to it. We didn't use JFC, so I cannot say anything about it. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 9:05 ` Properties Dmitry A. Kazakov @ 2010-12-03 19:52 ` Shark8 2010-12-03 21:14 ` Properties Randy Brukardt ` (2 more replies) 0 siblings, 3 replies; 94+ messages in thread From: Shark8 @ 2010-12-03 19:52 UTC (permalink / raw) On Dec 3, 2:05 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > > Why not have an INTERFACE hierarchy in addition to the GUI_Object > > hierarchy? > > Hmm, isn't it same? To me interface = abstract type. Usually they are interchangeable, but INTERFACES are the only way in Ada to do something akin to multiple inheritance: i.e. it is the only way that we can synthesize a spin-box {an increase value button, a decrease value button, and a numeric-value edit-box} from the leaves of our elemental-GUI-component hierarchy w/o encapsulating the items within an otherwise useless 'container' object. Type GUI_Base is interface; Procedure On_Basic_Event(Object : In Out GUI_Base'Class; Event : In Basic_Event'Class ); Type Button is interface and GUI_base; Procedure On_Click( Object : In Out Button'Class; Click : In Click_Event'Class ); Type Edit_Box is interface and GUI_Base; Procedure On_Change( Object : In Out Edit_Box'Class; Change : In Change_Event'Class ); -- ... Type Spin_Box_Object is New GUI_Base_Object and Button and Edit_box with record --... end record; > > Additionally, it could help with keeping the GUI_Object hierarchy > > smaller as there are many GUI items which are themselves composed of > > other GUI items. A scroll-bar, for example, has two distinct > > interfaces: the Button[s] and the slider-bar. > > Ada should have had proper multiple inheritance 15 years ago. Mayhaps; but that would be irrelevant to actual task. (i.e. where someone plops down and says to your boss "We're using Ada 2005 and we want a GUI library fully and seamlessly portable across X, Y, and Z OSes." who then turns to you and me and says "Make it!") > > By "widget containers" do you mean something like > > Ada.Containers.Vectors initialized to the classwide-type of the root > > of the GUI_Object hierarchy, OR do you mean some component which > > contains other components (like a panel, perhaps)? {I'm inclined to > > believe you meant the latter.} > > Yes, the latter, but the former is also required, you frequently need lists > of widgets (of referential semantics). It is somewhat irritating that you cannot initialize element to GUI_Base'Class directly. Attempting the following Package GUI_Vector is New Ada.Containers.Vectors ( Element_Type => GUI_Base'Class, Index_Type => Positive ); yields instantiation error at a-convec.ads:321 "unconstrained element type in array declaration actual for "Element_Type" must be a definite subtype" What's wrong with say initializing Ada.Containers.Vector with Positive => Index and Element => Access_GUI_Base_Class*? *Type Access_GUI_Base_Class is Access GUI_Base'Class; It would be nice to throw a "Not null" in because storing a 'pointer' to "not an object" is pretty dumb... but that gives this error-set: warning: in instantiation at a-convec.adb:1196 warning: (Ada 2005) null-excluding objects must be initialized warning: "Constraint_Error" will be raised at run time warning: in instantiation at a-convec.adb:1209 warning: (Ada 2005) null-excluding objects must be initialized warning: "Constraint_Error" will be raised at run time It's almost as if it's saying that we couldn't ever use the container exclusively like this: Vector : GUI_Vector.Vector:= GUI_Vector.Empty_Vector; Component_1 : Aliased GUI_Base'Class:= Make_Component( ... ); --... Component_n : Aliased GUI_Base'Class:= Make_Component( ... ); begin Vector.Add( Component_1'Access ); --... Vector.Add( Component_n'Access ); --the work end; >This raises another question. Ada > does not support abstract access types. You want a reference to the widget > be a fat pointer transparent to all widget operations with automatic > collection of widget objects. This almost works in Ada, but it is extremely > boring to do. [snip] > The bottom line, interfaces must be removed from Ada. > Instead of that an interface must be made inheritable > from any concrete type. This is the same idea as with > abstract record, array etc types. Wouldn't this be alleviated by two things: Allowing INTERFACE [keyword] objects to have fields (properties as I've described, or somesuch)? Allowing objects some sort of self/this/me attribute where the result is a Not Null Access to its classwide-type*? (Or am I misunderstanding what you mean by the need for "a fat pointer transparent to all widget operations"?) *Or is this the equivalent of requiring all such variables to be Aliased? > > type Widget_Handle is private Widget; -- Like the widget, but isn't > private > type Widget_Handle is new Ada.Limited_Controlled with record > Ptr : access Widget; > end record; > > For access types there must be delegation support, which should eliminate > need in wrappers. There are other issues as well, like that "access Widget" > is purposely not "access Widget'Class." > > > Finally, I've been quite impressed with Delphi's Visual Component > > Library (VCL). > > That's interesting, because we are using the VCL quite heavily. One of our > customers explicitly ordered that. Now, my impression is opposite to yours: > it is safer, *quicker*, cleaner, an far more maintainable to develop GUI in > *raw* Windows API than in VCL. As a bonus, you can get rid of that awful > Borland C++, use VC++ or gcc instead. Oh, right, the VCL *WAS* ported-over-to/interfaced-with Borland's C Builder. I'm utterly unfamiliar with that incarnation of the VCL as my experience with it has been on the Delphi (Object Pascal) side. But the problem is that wrapping the API calls, and management of the returned references, in objects yields something similar-in-structure to the VCL, no? I'm not saying that things couldn't have been done better; they could have. But for being a useful object-oriented GUI library tied to a singular API (Windows) I think it's done pretty well. The idea we've been kicking around about a truly portable GUI library with attention to type-safety and [hopefully] prevention of Bad Things (insofar as they can be prevented, thus your desire for a statically- checked GUI library) is an order of magnitude more complex. -- Though I myself would like to see just such a portable GUI library done in Ada. > > > Microsoft's MFC and Java's JFC seem to have been > > 'inspired' [or copied] from the VCL, but neither presents itself as > > uniform & usable/mature [if you will] as the VCL. > > We dropped MFC long ago and never returned to it. We didn't use JFC, so I cannot say anything about it. Imagine the VCL, then take away all the inherited handling of events and make them all purely java-interfaces (so in order to handle events you have to create some class which implements the interface; this is usually cone in-line/via-anonymous-class), and you basically have something similar to the JFC. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 19:52 ` Properties Shark8 @ 2010-12-03 21:14 ` Randy Brukardt 2010-12-04 5:35 ` Properties Shark8 2010-12-13 15:10 ` Properties Brian Drummond 2010-12-03 22:38 ` Properties Dmitry A. Kazakov 2010-12-04 13:19 ` Properties Georg Bauhaus 2 siblings, 2 replies; 94+ messages in thread From: Randy Brukardt @ 2010-12-03 21:14 UTC (permalink / raw) "Shark8" <onewingedshark@gmail.com> wrote in message news:75475874-cd6c-4e75-8a2f-7675ecf0864a@f20g2000vbc.googlegroups.com... ... >It is somewhat irritating that you cannot initialize element to >GUI_Base'Class directly. You can do this with the Ada containers. >Attempting the following > Package GUI_Vector is New Ada.Containers.Vectors >( Element_Type => GUI_Base'Class, Index_Type => Positive ); >yields >instantiation error at a-convec.ads:321 >"unconstrained element type in array declaration actual for >"Element_Type" must be a definite subtype" Right, but you are using the wrong container for this. Try the indefinite containers (designed specifically for this purpose): Package GUI_Vector is New Ada.Containers.Indefinite_Vectors ( Element_Type => GUI_Base'Class, Index_Type => Positive ); This will work fine. Randy. What's wrong with say initializing Ada.Containers.Vector with Positive => Index and Element => Access_GUI_Base_Class*? *Type Access_GUI_Base_Class is Access GUI_Base'Class; It would be nice to throw a "Not null" in because storing a 'pointer' to "not an object" is pretty dumb... but that gives this error-set: warning: in instantiation at a-convec.adb:1196 warning: (Ada 2005) null-excluding objects must be initialized warning: "Constraint_Error" will be raised at run time warning: in instantiation at a-convec.adb:1209 warning: (Ada 2005) null-excluding objects must be initialized warning: "Constraint_Error" will be raised at run time It's almost as if it's saying that we couldn't ever use the container exclusively like this: Vector : GUI_Vector.Vector:= GUI_Vector.Empty_Vector; Component_1 : Aliased GUI_Base'Class:= Make_Component( ... ); --... Component_n : Aliased GUI_Base'Class:= Make_Component( ... ); begin Vector.Add( Component_1'Access ); --... Vector.Add( Component_n'Access ); --the work end; >This raises another question. Ada > does not support abstract access types. You want a reference to the widget > be a fat pointer transparent to all widget operations with automatic > collection of widget objects. This almost works in Ada, but it is > extremely > boring to do. [snip] > The bottom line, interfaces must be removed from Ada. > Instead of that an interface must be made inheritable > from any concrete type. This is the same idea as with > abstract record, array etc types. Wouldn't this be alleviated by two things: Allowing INTERFACE [keyword] objects to have fields (properties as I've described, or somesuch)? Allowing objects some sort of self/this/me attribute where the result is a Not Null Access to its classwide-type*? (Or am I misunderstanding what you mean by the need for "a fat pointer transparent to all widget operations"?) *Or is this the equivalent of requiring all such variables to be Aliased? > > type Widget_Handle is private Widget; -- Like the widget, but isn't > private > type Widget_Handle is new Ada.Limited_Controlled with record > Ptr : access Widget; > end record; > > For access types there must be delegation support, which should eliminate > need in wrappers. There are other issues as well, like that "access > Widget" > is purposely not "access Widget'Class." > > > Finally, I've been quite impressed with Delphi's Visual Component > > Library (VCL). > > That's interesting, because we are using the VCL quite heavily. One of our > customers explicitly ordered that. Now, my impression is opposite to > yours: > it is safer, *quicker*, cleaner, an far more maintainable to develop GUI > in > *raw* Windows API than in VCL. As a bonus, you can get rid of that awful > Borland C++, use VC++ or gcc instead. Oh, right, the VCL *WAS* ported-over-to/interfaced-with Borland's C Builder. I'm utterly unfamiliar with that incarnation of the VCL as my experience with it has been on the Delphi (Object Pascal) side. But the problem is that wrapping the API calls, and management of the returned references, in objects yields something similar-in-structure to the VCL, no? I'm not saying that things couldn't have been done better; they could have. But for being a useful object-oriented GUI library tied to a singular API (Windows) I think it's done pretty well. The idea we've been kicking around about a truly portable GUI library with attention to type-safety and [hopefully] prevention of Bad Things (insofar as they can be prevented, thus your desire for a statically- checked GUI library) is an order of magnitude more complex. -- Though I myself would like to see just such a portable GUI library done in Ada. > > > Microsoft's MFC and Java's JFC seem to have been > > 'inspired' [or copied] from the VCL, but neither presents itself as > > uniform & usable/mature [if you will] as the VCL. > > We dropped MFC long ago and never returned to it. We didn't use JFC, so I > cannot say anything about it. Imagine the VCL, then take away all the inherited handling of events and make them all purely java-interfaces (so in order to handle events you have to create some class which implements the interface; this is usually cone in-line/via-anonymous-class), and you basically have something similar to the JFC. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 21:14 ` Properties Randy Brukardt @ 2010-12-04 5:35 ` Shark8 2010-12-04 14:23 ` Properties Peter C. Chapin 2010-12-13 15:10 ` Properties Brian Drummond 1 sibling, 1 reply; 94+ messages in thread From: Shark8 @ 2010-12-04 5:35 UTC (permalink / raw) On Dec 3, 2:14 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > Right, but you are using the wrong container for this. > Try the indefinite containers (designed specifically for > this purpose): > > Package GUI_Vector is New Ada.Containers.Indefinite_Vectors > ( Element_Type => GUI_Base'Class, Index_Type => Positive ); > > This will work fine. > > Randy. Oh wow! / Nice... As I've admitted I'm a newcomer to Ada, so there's a lot to [still] learn. I kept thinking "there's GOT to be some reason that it won't let me do that... maybe I'm just not understanding something here..." Just a quick question, but why was it necessary to have two sets of containers, one for the indefinates and one for the definites? ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-04 5:35 ` Properties Shark8 @ 2010-12-04 14:23 ` Peter C. Chapin 2010-12-04 18:53 ` Properties Shark8 0 siblings, 1 reply; 94+ messages in thread From: Peter C. Chapin @ 2010-12-04 14:23 UTC (permalink / raw) On 2010-12-04 00:35, Shark8 wrote: > Just a quick question, but why was it necessary to have two sets of > containers, one for the indefinates and one for the definites? Each instance of an indefinite type can have different sizes. For example procedure Example is S1 : String(1 .. 10); S2 : String(1 .. 100); begin null; end Example; S1 and S2 occupy different amounts of memory. The indefinite containers deal with this by using access values internally. That is an indefinite vector of strings actually stores String access values (pointers) and manages that extra indirection internally so you aren't exposed to it. This allows strings of different sizes to be stored in the vector in a uniform way. The price is extra overhead and slightly less efficiency. Class wide types are also indefinite because an instance of a class wide type can be one of several different types in the class (all with potentially different sizes). Peter ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-04 14:23 ` Properties Peter C. Chapin @ 2010-12-04 18:53 ` Shark8 0 siblings, 0 replies; 94+ messages in thread From: Shark8 @ 2010-12-04 18:53 UTC (permalink / raw) On Dec 4, 7:23 am, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote: > On 2010-12-04 00:35, Shark8 wrote: > > > Just a quick question, but why was it necessary to have two sets of > > containers, one for the indefinates and one for the definites? > > Each instance of an indefinite type can have different sizes. For example > > procedure Example is > S1 : String(1 .. 10); > S2 : String(1 .. 100); > begin > null; > end Example; > > S1 and S2 occupy different amounts of memory. The indefinite containers > deal with this by using access values internally. That is an indefinite > vector of strings actually stores String access values (pointers) and > manages that extra indirection internally so you aren't exposed to it. > This allows strings of different sizes to be stored in the vector in a > uniform way. The price is extra overhead and slightly less efficiency. > > Class wide types are also indefinite because an instance of a class wide > type can be one of several different types in the class (all with > potentially different sizes). > > Peter Ok, I suspected this was the answer but wanted to make sure. Thank you for verifying it. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 21:14 ` Properties Randy Brukardt 2010-12-04 5:35 ` Properties Shark8 @ 2010-12-13 15:10 ` Brian Drummond 1 sibling, 0 replies; 94+ messages in thread From: Brian Drummond @ 2010-12-13 15:10 UTC (permalink / raw) On Fri, 3 Dec 2010 15:14:09 -0600, "Randy Brukardt" <randy@rrsoftware.com> wrote: >"Shark8" <onewingedshark@gmail.com> wrote in message >news:75475874-cd6c-4e75-8a2f-7675ecf0864a@f20g2000vbc.googlegroups.com... >... >>It is somewhat irritating that you cannot initialize element to >>GUI_Base'Class directly. ... >>instantiation error at a-convec.ads:321 >>"unconstrained element type in array declaration actual for >>"Element_Type" must be a definite subtype" > >Right, but you are using the wrong container for this. Try the indefinite >containers (designed specifically for this purpose): > >Package GUI_Vector is New Ada.Containers.Indefinite_Vectors > ( Element_Type => GUI_Base'Class, Index_Type => Positive ); > >This will work fine. Excellent! But perhaps the error message could be improved to suggest this, e.g. >>"unconstrained element type in array declaration actual for >>"Element_Type" must be a definite subtype, or container must be indefinite" - Brian ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 19:52 ` Properties Shark8 2010-12-03 21:14 ` Properties Randy Brukardt @ 2010-12-03 22:38 ` Dmitry A. Kazakov 2010-12-04 3:12 ` Properties Shark8 2010-12-04 13:19 ` Properties Georg Bauhaus 2 siblings, 1 reply; 94+ messages in thread From: Dmitry A. Kazakov @ 2010-12-03 22:38 UTC (permalink / raw) On Fri, 3 Dec 2010 11:52:22 -0800 (PST), Shark8 wrote: > On Dec 3, 2:05�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> The bottom line, interfaces must be removed from Ada. >> Instead of that an interface must be made inheritable >> from any concrete type. This is the same idea as with >> abstract record, array etc types. > > Wouldn't this be alleviated by two things: > Allowing INTERFACE [keyword] objects to have fields (properties as > I've described, or somesuch)? These are different problems: 1. Record interface, this is in effect what you proposed: type Members is interface record A : Integer; -- Not a physical member only an interface "Object.A" end record; [I want other interfaces too, like array interface, access interface etc.] 2. Interface inheritance. Let you have some type: type T is tagged ... procedure Foo (X : T); You have to replace it to type Interface_of_T is interface; procedure Foo (X : Interface_T) is abstract; type T is ... and Interface_of_T ... overriding procedure Foo (X : T); In order to be able to say: type S is ... and Interface_of_T ... overriding procedure Foo (X : S); It is boring. Each type obviously has an interface, which must be inheritable from. > Allowing objects some sort of self/this/me attribute where the result > is a Not Null Access to its classwide-type*? (Or am I misunderstanding > what you mean by the need for "a fat pointer transparent to all widget > operations"?) I mean this: -- Anything you can do with a widget type Widget_Interface is limited interface; procedure Draw (Object : in out Widget_Interface) is abstract; ... -- Implementation of a widget type Widget_Object is new Widget_Interface with ...; overriding procedure Draw (Object : in out Widget_Object); type Widget_Object_Ptr is access all Widget_Object; -- Public interface of a widget, a reference type Widget is new Ada.Finalization.Controlled and Widget_Interface with record Ptr : Widget_Object_Ptr; end record; overriding procedure Draw (Object : in out Widget); procedure Draw (Object : in out Widget) is begin Draw (Object.Ptr.all); end Draw; Widget_Object is private, publicly accessible is its fat pointer/handle Widget. Both implement the same interface Widget_Interface. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 22:38 ` Properties Dmitry A. Kazakov @ 2010-12-04 3:12 ` Shark8 0 siblings, 0 replies; 94+ messages in thread From: Shark8 @ 2010-12-04 3:12 UTC (permalink / raw) On Dec 3, 3:38 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Fri, 3 Dec 2010 11:52:22 -0800 (PST), Shark8 wrote: > > On Dec 3, 2:05 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > > wrote: > >> The bottom line, interfaces must be removed from Ada. > >> Instead of that an interface must be made inheritable > >> from any concrete type. This is the same idea as with > >> abstract record, array etc types. > > > Wouldn't this be alleviated by two things: > > Allowing INTERFACE [keyword] objects to have fields (properties as > > I've described, or somesuch)? > > These are different problems: > > 1. Record interface, this is in effect what you proposed: > > type Members is interface record > A : Integer; -- Not a physical member only an interface "Object.A" > end record; > > [I want other interfaces too, like array interface, access interface etc.] > > 2. Interface inheritance. Let you have some type: > > type T is tagged ... > procedure Foo (X : T); > > You have to replace it to > > type Interface_of_T is interface; > procedure Foo (X : Interface_T) is abstract; > > type T is ... and Interface_of_T ... > overriding procedure Foo (X : T); > > In order to be able to say: > > type S is ... and Interface_of_T ... > overriding procedure Foo (X : S); > > It is boring. Each type obviously has an interface, which must be > inheritable from. > > > Allowing objects some sort of self/this/me attribute where the result > > is a Not Null Access to its classwide-type*? (Or am I misunderstanding > > what you mean by the need for "a fat pointer transparent to all widget > > operations"?) > > I mean this: > > -- Anything you can do with a widget > type Widget_Interface is limited interface; > procedure Draw (Object : in out Widget_Interface) is abstract; > ... > > -- Implementation of a widget > type Widget_Object is new Widget_Interface with ...; > overriding procedure Draw (Object : in out Widget_Object); > > type Widget_Object_Ptr is access all Widget_Object; > > -- Public interface of a widget, a reference > type Widget is new Ada.Finalization.Controlled and Widget_Interface with > record > Ptr : Widget_Object_Ptr; > end record; > overriding procedure Draw (Object : in out Widget); > > procedure Draw (Object : in out Widget) is > begin > Draw (Object.Ptr.all); > end Draw; > > Widget_Object is private, publicly accessible is its fat pointer/handle > Widget. Both implement the same interface Widget_Interface. > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de Ah, I see! Delphi has the nice ability to delegate the implementation for an interface... so the analog to your type widget would be: Type {TObject is the root-object in Delphi} TWidget = Class( TObject, Widget_Interface ) public Object : ^Widget_Object implements Widget_Interface; end; {Class TWidget} And then all calls to objects of TWidget via Widget_Interface are automatically routed to the Object field. ^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: Properties 2010-12-03 19:52 ` Properties Shark8 2010-12-03 21:14 ` Properties Randy Brukardt 2010-12-03 22:38 ` Properties Dmitry A. Kazakov @ 2010-12-04 13:19 ` Georg Bauhaus 2 siblings, 0 replies; 94+ messages in thread From: Georg Bauhaus @ 2010-12-04 13:19 UTC (permalink / raw) On 12/3/10 8:52 PM, Shark8 wrote: > On Dec 3, 2:05 am, "Dmitry A. Kazakov"<mail...@dmitry-kazakov.de> > wrote: >>> Why not have an INTERFACE hierarchy in addition to the GUI_Object >>> hierarchy? >> >> Hmm, isn't it same? To me interface = abstract type. > > Usually they are interchangeable, but INTERFACES are the only way in > Ada to do something akin to multiple inheritance: One of the three ways to do something akin to multiple inheritance is mixin generics. ^ permalink raw reply [flat|nested] 94+ messages in thread
end of thread, other threads:[~2010-12-13 15:10 UTC | newest] Thread overview: 94+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-11-28 3:21 Properties Shark8 2010-11-28 8:15 ` Properties Dmitry A. Kazakov 2010-11-28 19:43 ` Properties Shark8 2010-11-29 8:34 ` Properties Dmitry A. Kazakov 2010-12-01 18:15 ` Properties Shark8 2010-11-28 12:37 ` Properties Georg Bauhaus 2010-11-28 21:22 ` Properties Shark8 2010-11-29 16:54 ` Properties Georg Bauhaus 2010-12-01 19:52 ` Properties Martin Krischik 2010-12-01 23:24 ` Properties Georg Bauhaus 2010-12-05 16:15 ` (placepo) Properties Martin Krischik 2010-12-06 23:24 ` Shark8 2010-12-01 23:31 ` Properties Georg Bauhaus 2010-11-30 1:49 ` Properties Randy Brukardt 2010-11-30 16:58 ` Properties Charmed Snark 2010-11-30 17:22 ` Properties Dmitry A. Kazakov 2010-11-30 20:27 ` Properties Warren 2010-12-01 8:39 ` Properties Dmitry A. Kazakov 2010-12-01 15:21 ` Properties Warren 2010-12-01 15:59 ` Properties Dmitry A. Kazakov 2010-12-01 16:20 ` Properties Warren 2010-12-01 18:22 ` Properties Dmitry A. Kazakov 2010-12-01 19:36 ` Properties Shark8 2010-12-01 21:13 ` Properties Dmitry A. Kazakov 2010-12-01 21:35 ` Properties Maciej Sobczak 2010-12-01 21:45 ` Properties Dmitry A. Kazakov 2010-12-02 9:57 ` Properties Maciej Sobczak 2010-12-02 10:26 ` Properties Dmitry A. Kazakov 2010-12-02 15:25 ` Properties Maciej Sobczak 2010-12-02 15:46 ` Properties Dmitry A. Kazakov 2010-12-02 21:11 ` Properties Maciej Sobczak 2010-12-02 22:19 ` Properties Dmitry A. Kazakov 2010-12-03 4:43 ` Properties Randy Brukardt 2010-12-03 13:53 ` Properties Maciej Sobczak 2010-12-03 21:32 ` Properties Randy Brukardt 2010-12-04 22:13 ` Properties Maciej Sobczak 2010-12-06 23:30 ` Properties Shark8 2010-12-06 23:33 ` Properties Randy Brukardt 2010-12-04 17:43 ` Properties Simon Wright 2010-12-04 20:48 ` Properties Dmitry A. Kazakov 2010-12-04 22:27 ` Properties Simon Wright 2010-12-04 22:31 ` Properties Vinzent Hoefler 2010-12-03 4:24 ` Properties Randy Brukardt 2010-12-03 5:00 ` Properties Shark8 2010-12-03 21:10 ` Properties Randy Brukardt 2010-12-03 23:34 ` Properties Jeffrey Carter 2010-12-06 6:02 ` Properties Brad Moore 2010-12-06 23:25 ` Properties Shark8 2010-12-01 19:48 ` Properties Randy Brukardt 2010-12-01 21:10 ` Properties Warren 2010-12-02 0:03 ` Properties Shark8 2010-12-02 16:45 ` Properties Warren 2010-12-02 17:32 ` Properties Dmitry A. Kazakov 2010-12-02 20:45 ` Properties Warren 2010-12-02 21:17 ` Properties Adam Beneschan 2010-12-02 21:40 ` Properties Warren 2010-12-03 3:34 ` Properties Shark8 2010-12-03 8:16 ` Properties Thomas Løcke 2010-12-02 20:52 ` Properties Pascal Obry 2010-12-02 19:46 ` Properties Adam Beneschan 2010-12-02 20:38 ` Properties Warren 2010-12-02 21:39 ` Properties Jeffrey Carter 2010-12-02 21:55 ` Properties Warren 2010-12-03 9:33 ` Properties Anonymous 2010-12-03 3:47 ` Properties Shark8 2010-12-03 0:09 ` Properties Robert A Duff 2010-12-03 15:49 ` Properties Warren 2010-12-03 20:07 ` Properties Shark8 2010-12-06 21:01 ` Properties Warren 2010-12-06 23:22 ` Properties Shark8 2010-12-07 14:37 ` Properties Warren 2010-12-08 21:13 ` Properties Simon Wright 2010-12-09 1:21 ` Properties Shark8 2010-12-06 23:43 ` Properties Randy Brukardt 2010-12-07 0:56 ` Properties Jeffrey Carter 2010-12-07 11:23 ` Properties Maciej Sobczak 2010-12-07 11:51 ` Properties Georg Bauhaus 2010-12-07 15:35 ` Properties Maciej Sobczak 2010-12-07 17:02 ` Properties Georg Bauhaus 2010-12-07 14:39 ` Properties Warren 2010-12-03 15:40 ` Properties Warren 2010-12-03 19:56 ` Properties Shark8 2010-12-03 20:12 ` Properties Warren 2010-12-03 5:53 ` Properties Shark8 2010-12-03 9:05 ` Properties Dmitry A. Kazakov 2010-12-03 19:52 ` Properties Shark8 2010-12-03 21:14 ` Properties Randy Brukardt 2010-12-04 5:35 ` Properties Shark8 2010-12-04 14:23 ` Properties Peter C. Chapin 2010-12-04 18:53 ` Properties Shark8 2010-12-13 15:10 ` Properties Brian Drummond 2010-12-03 22:38 ` Properties Dmitry A. Kazakov 2010-12-04 3:12 ` Properties Shark8 2010-12-04 13:19 ` Properties Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox