Prev: Lost in translation (with SPARK user rules)
Next: Sockets package in SPARK (Was: Lost in translation (with SPARK user rules))
From: Vadim Godunko on 10 Jun 2010 04:57 On Jun 10, 11:20 am, AdaMagica <christoph.gr...(a)eurocopter.com> wrote: > On 10 Jun., 08:34, Vadim Godunko <vgodu...(a)gmail.com> wrote: > > > I want to known more about how to use OOP in Ada without access types! > > type Element is tagged ... > subtype Any_Element is Element'Class; > > procedure Show (E: Element); > Thank you for example, this is example of dispatching but not use of Ada in heavy OOP style of programming. :-)
From: Dmitry A. Kazakov on 10 Jun 2010 05:07 On Thu, 10 Jun 2010 10:44:02 +0200, Yannick Duchêne (Hibou57) wrote: > Le Thu, 10 Jun 2010 10:07:17 +0200, Dmitry A. Kazakov > <mailbox(a)dmitry-kazakov.de> a écrit: >> Yes. These are abstract interfaces to be defined. This is an easy part >> BTW. > What about “not every thing in the same bag” philosophy ? (many others > failed in this trap) Who? The examples you probably have in mind use implementation inheritance, which is obviously doomed to fail. In order to work, it must be interface inheritance + ad-hoc supertypes (you cannot and need not declare everything in advance). > Moving generics to dynamic polymorphism... would be > dynamic polymorphism where there was a kind of static polymorphism. And > this is not the same from the point of view of program proof you like so > much (me too, I like). It is exactly same, because programs themselves are even more dynamic than types relationships. Nevertheless there is SPARK to deal with that. The type system must be designed to help the compiler to do more static analysis, provided that the programmer would be asked to give more annotations to the types. (It cannot be more typing than we already have with generics, with no safety whatsoever!) > Is there some kind of meta-class in you idea of a new modal ? (generics > can define new types and thus can initiate new class of types, you will > meta-class to achieve the same). I call this type algebra. There are operations that yield types from types and values. Generic instantiation is such an operation. Derivation is another. Array declaration is third. Type constraining is forth, etc. If I were ARG, I would consider the algebraic type operations the language needs, with the goals: 0. SIMPLIFY THE LANGUAGE 1. Reduce generics use no absolute minimum (without performance penalty) 2. Most of currently built-in types must become library-defined 3. The standard container library must be freed of generics 4. The problem of container subtypes to be solved (e.g. when and how a container of subtypes becomes a subtype or not) 5. The problem of containers of class-wides to be solved (+ relation of a container of class-wides to a container of specific types, when, how) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 10 Jun 2010 05:20 On Thu, 10 Jun 2010 01:51:54 -0700 (PDT), Vadim Godunko wrote: > On Jun 10, 12:21�pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> >> Hmm, I never use access to tagged types except for: >> > By "access types" I mean access to classwide types. I use them even less frequently than access to specific types. You probably have in mind containers of class-wide objects? But they are really rare and there is no need to leak access types into their interfaces. (Of course excluding things like doubly-linked lists, graphs etc) >> BTW, by "access types in OOP way", do you mean pointers, references or >> heap-allocated objects? >> > I mean distinguishing of objects by instance in opposite to > distinguishing by value. By instance = by specific type? This is dispatch, need not to go through an access type. Ada nicely allows me to hide access types behind implementations. It is a pity that return by reference was scrapped in favor of Pickwickian functions. Otherwise, even handles to objects might have avoided access types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Georg Bauhaus on 10 Jun 2010 06:10 On 10.06.10 11:07, Dmitry A. Kazakov wrote: > I call this type algebra. There are operations that yield types from types > and values. Generic instantiation is such an operation. Derivation is > another. Array declaration is third. Type constraining is forth, etc. > > If I were ARG, I would consider the algebraic type operations the language > needs, with the goals: > > 0. SIMPLIFY THE LANGUAGE > 1. Reduce generics use no absolute minimum (without performance penalty) > 2. Most of currently built-in types must become library-defined > 3. The standard container library must be freed of generics > 4. The problem of container subtypes to be solved (e.g. when and how a > container of subtypes becomes a subtype or not) > 5. The problem of containers of class-wides to be solved (+ relation of a > container of class-wides to a container of specific types, when, how) What will be the type of a non-generic package?
From: Georg Bauhaus on 10 Jun 2010 06:12
On 10.06.10 10:57, Vadim Godunko wrote: > On Jun 10, 11:20 am, AdaMagica <christoph.gr...(a)eurocopter.com> wrote: >> On 10 Jun., 08:34, Vadim Godunko <vgodu...(a)gmail.com> wrote: >> >>> I want to known more about how to use OOP in Ada without access types! >> >> type Element is tagged ... >> subtype Any_Element is Element'Class; >> >> procedure Show (E: Element); >> > Thank you for example, this is example of dispatching but not use of > Ada in heavy OOP style of programming. :-) Will it, in theory, be possible to write a Qt-like library in Ada such that client programs declare variables like W : Some_Window'Class := Some_Lib_Pack.Make (Typ => Some_Id); That is, programs do not use access Some_Window'Class? |