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: Nick Keighley on 23 Apr 2010 04:48 On 22 Apr, 11:45, S Perryman <a...(a)a.net> wrote: > Nick Keighley wrote: > > On 16 Apr, 09:37, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>> > >>On Fri, 16 Apr 2010 01:10:50 -0700 (PDT), Nilone wrote: > >>>On Apr 16, 8:38 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > >>>>On Thu, 15 Apr 2010 14:36:37 -0700 (PDT), Nilone wrote: well I seem to be more on your wavelength than Mr Kazakov's. At least you admit there may be some difference of opinion about these terms. > >>>>>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? > > >>>>What rules do you mean? > > >>>My view of IntegerType is that it's an object, not a class, and I made > >>>it as much so as the language allowed, hence the static methods and > >>>lack of constructor. > > >>Egh, object is a run-time instance of a type. > > > ok so far... > > >>Class is a set of [derived] types. > > > so what's a type? I tend to use class and type interchangeably but I > > know many people distinguish them. A type/class is set of objects all > > sharing the same behaviour. Or a set of objects each having a value > > with a set of operations defined on those objects. > > Because of all the problems with using terms in place of eachother, I > decided to try and step back and build my terms axiomatically so I can > attempt to debate with others on the various topics. > > So to that end, I merely define type as a predicate. > So a type T is a predicate, T : anything -> boolean. presumably you have *some* sort of a priori idea of what a type is. "it is green" not being a particularly usual predicate for type. Ah, sorry I misunderstood. I thought you were defining what a type is- that is the predicate was something you aplied to find out if it was a a type. Whilst what you mean is that the predicate determines if something is of a particular type. So I can still keep class/type isomorphism... > When you have an instance x, and you say x is "of type T" , I > require that T(x) holds. ok > The definition of T(x) depends on the properties that you require T > to have. > FWIW, in such discussions I don't use the words : > > - class > > To me "class" is merely a lexical token that is used by Simula (the > progenitor of OOP) to denote a specific form of user-defined type. a definition I'm fairly happy with. So built in types aren't classes? Ah, so C++ does have a reasonable distinction between class and type. So is a struct a class? Probably yes just uses a different keyword. What about arrays or unions (or is C++ just too broken to be hauled into the discussion?!) > - object > > I use "instance of a type" . > > - subclass > > I talk of inheritance, and type substitutability (an orthogonal topic) . > > I am as always, open to better definitions to use. but some people seem to think the type/class distinction is important
From: Dmitry A. Kazakov on 23 Apr 2010 10:43 On Fri, 23 Apr 2010 01:24:09 -0700 (PDT), Nick Keighley wrote: > On 22 Apr, 11:35, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> On Thu, 22 Apr 2010 01:59:50 -0700 (PDT), Nick Keighley wrote: >>> On 16 Apr, 09:37, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> >>>> Class is a set of [derived] types. >> >>> so what's a type? I tend to use class and type interchangeably but I >>> know many people distinguish them. A type/class is set of objects all >>> sharing the same behaviour. >> >> Neither is a set of objects. Set of objects is a property of a running >> program. E.g. the variables declared in the scope of a block is a set of >> objects. > > the set of all entities sharing a common behaviour? Depending on the context it could be anything. BTW I didn't consider here OO modeling, if you had those objects in mind. >> What you mean under "class" is a polymorphic type that represents the >> class. > > I'm not sure adding in polymorphism is useful at this state. Could you > have a class "Integer"? Yes, e.g. { int_16, int_32, int_64, Big_Int } > Is it polymorphic? No. Class is a set. There might be a type of polymorphic values. This type is polymorphic. Values of his type are: (int_16, 1), (int_32, 1), (int_64, 100), (Big_Int, 123) etc >> There are three things in this context: >> >> 1. type T, also "specific type" > > which rather begs the question "whats a type"? A set of values + a set of operations defined on and providing them. Integer, task, Employee are types. >> 2. the class rooted in T = the set of all types derived from T, i.e. >> {S|S<:T}. Set is not a type. Even if it were that would be a type of types, >> and not the thing: > > so types are base classes and classes are derived from types? Which of > these are types and which classes? > > Integer, Point, Socket These are all types. None is a class. Class is a set, e.g. integers is a class of all integer types. Another example: template <unsigned> class Foo is a class of all types obtained by substitution the parameter, i.e. {Foo<0>, Foo<1>, ...}. >> 3. class type T, also "polymorphic type", a type which values are tuples >> (type tag, type value). These values are polymorphic, which specific types >> may vary with the type tag. The specific types here are taken from the >> class rooted in T. >> >> People using "class" and "type" interchangeably are confusing 1. and 3. Why >> is it bad? > > types are in some sense atomic? I am not sure what do you mean by that. >> Consider T = Boolean. Then Boolean'Class cannot have the representation of >> T. There is no place to keep the type tag (vtab_ptr in C++). > > why can't you have classes without tags? You can, AKA static polymorphism. But for dynamic polymorphism (the most interesting case of) you need type information at run-time in order to dispatch. >> So the people >> start talking silly things that there are types and not so types, objects >> and not so objects, etc. Worse, some of these people develop programming >> languages where you cannot derive from Boolean. > > why would you want to! In order to have a hierarchy like this: Boolean {0,1} / \ Fuzzy logical [0,1] Tri-state {0, _|_, 1} | | | Belnap {0, _|_, 1, T) | | Intuitionistic fuzzy logical [0,1]x[0,1] >> Others develop languages where Boolean occupies several machine words. > > this caused by class/type confusion? among other mistakes... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Nick Keighley on 22 Apr 2010 04:59 On 16 Apr, 09:37, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Fri, 16 Apr 2010 01:10:50 -0700 (PDT), Nilone wrote: > > On Apr 16, 8:38 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > > wrote: > >> On Thu, 15 Apr 2010 14:36:37 -0700 (PDT), Nilone wrote: > >>> 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? > > >> What rules do you mean? > > > My view of IntegerType is that it's an object, not a class, and I made > > it as much so as the language allowed, hence the static methods and > > lack of constructor. > > Egh, object is a run-time instance of a type. ok so far... > Class is a set of [derived] types. so what's a type? I tend to use class and type interchangeably but I know many people distinguish them. A type/class is set of objects all sharing the same behaviour. Or a set of objects each having a value with a set of operations defined on those objects. > IntegerType, as the name suggest, is a type. > > > Inheritance requires that the methods of the class accept the same or > > broader set of arguments, while returning the same or narrower set of > > types, right? > > No. Inheritance is always covariant. > > A covariant argument/result is of the class closure (i.e. polymorphic). An > operation defined on the class = method [in the corresponding > argument/result]. > > Contravariant = no inheritance. An operation contravariant in some > argument/result is not a method in this argument/result = it is not > inherited in there. It is just so because the type is specific > (non-polymorphic). > > > If I tried to inherit my IntegerType from a similarly > > designed RealType, it would require that IntegerType.Divide() accept > > RealValues, which isn't what I want to do at all. > > Why so? If you inherit a method of the interface: > > function "/" (Left, Right : Real) return Real; > > then all arguments and the result are covariant. I see no problem. Except > that some [broken] languages give you no control over the covariance. > > BTW, if you derived Real from Complex, you would like to have Sqrt > covariant in the argument and contravariant in the result. nick keighley
From: Dmitry A. Kazakov on 22 Apr 2010 06:35 On Thu, 22 Apr 2010 01:59:50 -0700 (PDT), Nick Keighley wrote: > On 16 Apr, 09:37, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> Class is a set of [derived] types. > > so what's a type? I tend to use class and type interchangeably but I > know many people distinguish them. A type/class is set of objects all > sharing the same behaviour. Neither is a set of objects. Set of objects is a property of a running program. E.g. the variables declared in the scope of a block is a set of objects. What you mean under "class" is a polymorphic type that represents the class. There are three things in this context: 1. type T, also "specific type" 2. the class rooted in T = the set of all types derived from T, i.e. {S|S<:T}. Set is not a type. Even if it were that would be a type of types, and not the thing: 3. class type T, also "polymorphic type", a type which values are tuples (type tag, type value). These values are polymorphic, which specific types may vary with the type tag. The specific types here are taken from the class rooted in T. People using "class" and "type" interchangeably are confusing 1. and 3. Why is it bad? Consider T = Boolean. Then Boolean'Class cannot have the representation of T. There is no place to keep the type tag (vtab_ptr in C++). So the people start talking silly things that there are types and not so types, objects and not so objects, etc. Worse, some of these people develop programming languages where you cannot derive from Boolean. Others develop languages where Boolean occupies several machine words. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: S Perryman on 22 Apr 2010 06:45
Nick Keighley wrote: > On 16 Apr, 09:37, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >>On Fri, 16 Apr 2010 01:10:50 -0700 (PDT), Nilone wrote: >> >>>On Apr 16, 8:38 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> >>>wrote: >>> >>>>On Thu, 15 Apr 2010 14:36:37 -0700 (PDT), Nilone wrote: > > >>>>>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? >> >>>>What rules do you mean? >> >>>My view of IntegerType is that it's an object, not a class, and I made >>>it as much so as the language allowed, hence the static methods and >>>lack of constructor. >> >>Egh, object is a run-time instance of a type. > > > ok so far... > > > >>Class is a set of [derived] types. > > > so what's a type? I tend to use class and type interchangeably but I > know many people distinguish them. A type/class is set of objects all > sharing the same behaviour. Or a set of objects each having a value > with a set of operations defined on those objects. Because of all the problems with using terms in place of eachother, I decided to try and step back and build my terms axiomatically so I can attempt to debate with others on the various topics. So to that end, I merely define type as a predicate. So a type T is a predicate, T : anything -> boolean. When you have an instance x, and you say x is "of type T" , I require that T(x) holds. The definition of T(x) depends on the properties that you require T to have. FWIW, in such discussions I don't use the words : - class To me "class" is merely a lexical token that is used by Simula (the progenitor of OOP) to denote a specific form of user-defined type. - object I use "instance of a type" . - subclass I talk of inheritance, and type substitutability (an orthogonal topic) . I am as always, open to better definitions to use. Regards, Steven Perryman |