behaviour vs. data first
in [OOP]
|
Prev: Informatics 2010: 1st call extension - 30 April 2010
Next: The Eiffel Compiler tecomp version 0.22 released
From: Nilone on 14 Apr 2010 19:35 On Apr 15, 1:06 am, Nilone <rea...(a)gmail.com> wrote: > > I think I'm trying to understand how to implement homomorphisms on > algebraic data structures implemented as OO classes. For example, given the functions RealValue FromInteger(IntegerValue v) RealValue Divide(RealValue v1, RealValue v2) can/should the type system be able to determine RealValue(IntegerValue v1, IntegerValue v2) automatically, without requiring explicit type conversion or function overloading?
From: Dmitry A. Kazakov on 15 Apr 2010 02:59 On Wed, 14 Apr 2010 16:35:34 -0700 (PDT), Nilone wrote: > On Apr 15, 1:06�am, Nilone <rea...(a)gmail.com> wrote: >> >> I think I'm trying to understand how to implement homomorphisms on >> algebraic data structures implemented as OO classes. > > For example, given the functions > > RealValue FromInteger(IntegerValue v) > RealValue Divide(RealValue v1, RealValue v2) > > can/should the type system be able to determine > > RealValue(IntegerValue v1, IntegerValue v2) > > automatically, without requiring explicit type conversion or function > overloading? This is not a simple question. My personal view is that there should be no inference of this kind. If real must inherit to integer, that must be stated explicitly in the form of subtyping (usually called subclassing). BTW, the implementation of integer division cannot be inherited by real, because it is wrong. Regarding homomorphisms, an OO/ADT equivalent is substitutability and the vehicle in a strongly typed language is inheritance. I think it quite is possible to achieve ad-hoc subtypes with interface inheritance + subtyping + supertyping. E.g. if you have two unrelated types A, B and wanted A<:B, you could create a third "bridge" type C, such that A<:C (supertype) and C<:B (subtype). Because <: is transitive A<:B. Once C is declared the compiler will require to implement all missing implementations of inherited/exported operations. This can be automated by providing the compiler with type conversions appropriately declared etc. No OOPL is close to that. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: S Perryman on 15 Apr 2010 04:38 Nilone wrote: > On Apr 15, 1:06 am, Nilone <rea...(a)gmail.com> wrote: >>I think I'm trying to understand how to implement homomorphisms on >>algebraic data structures implemented as OO classes. > For example, given the functions > RealValue FromInteger(IntegerValue v) > RealValue Divide(RealValue v1, RealValue v2) > can/should the type system be able to determine > RealValue(IntegerValue v1, IntegerValue v2) > automatically, without requiring explicit type conversion or function > overloading? RealValue r ; IntegerValue i1, i2 ; r = divide(i1,i2) ; If RealValue is a (whole,fraction) abstraction, and IntegerValue is a (value) abstraction, are you asking whether the following should be inferred : r = divide(FromInteger(i1) , FromInteger(i2) ) ; If so, and I redefine "FromInteger" as an op RealValue : IntegerValue -> RealValue, then yes, the above could be inferred. The problem is, in an OO system, the type conversion op would have to be a multiple dispatch impl, with all the type safety issues therein (specifically whether an impl for all specific types of IntegerValue are known to exist) . Regards, Steven Perryman
From: Nilone on 15 Apr 2010 17:36 On Apr 15, 8:59 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Wed, 14 Apr 2010 16:35:34 -0700 (PDT), Nilone wrote: > > On Apr 15, 1:06 am, Nilone <rea...(a)gmail.com> wrote: > > >> I think I'm trying to understand how to implement homomorphisms on > >> algebraic data structures implemented as OO classes. > > > For example, given the functions > > > RealValue FromInteger(IntegerValue v) > > RealValue Divide(RealValue v1, RealValue v2) > > > can/should the type system be able to determine > > > RealValue(IntegerValue v1, IntegerValue v2) > > > automatically, without requiring explicit type conversion or function > > overloading? > > This is not a simple question. My personal view is that there should be no > inference of this kind. If real must inherit to integer, that must be > stated explicitly in the form of subtyping (usually called subclassing). > > BTW, the implementation of integer division cannot be inherited by real, > because it is wrong. > > Regarding homomorphisms, an OO/ADT equivalent is substitutability and the > vehicle in a strongly typed language is inheritance. > > I think it quite is possible to achieve ad-hoc subtypes with interface > inheritance + subtyping + supertyping. E.g. if you have two unrelated types > A, B and wanted A<:B, you could create a third "bridge" type C, such that > A<:C (supertype) and C<:B (subtype). Because <: is transitive A<:B. Once C > is declared the compiler will require to implement all missing > implementations of inherited/exported operations. This can be automated by > providing the compiler with type conversions appropriately declared etc. > > No OOPL is close to that. OO inheritance doesn't seem to suit algebraic structures. Isn't the co- and contravariance rules on algebraic domains reversed as compared to co-algebraic domains?
From: Nilone on 15 Apr 2010 18:25
On Apr 15, 10:38 am, S Perryman <a...(a)a.net> wrote: > > The problem is, in an OO system, the type conversion op would have to > be a multiple dispatch impl, with all the type safety issues therein > (specifically whether an impl for all specific types of IntegerValue > are known to exist) . I see, thanks. |