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 26 Apr 2010 05:22 On 25 Apr, 15:41, S Perryman <a...(a)a.net> wrote: > Nick Keighley wrote: > > On 22 Apr, 11:45, S Perryman <a...(a)a.net> 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. > > Your perceived differences may be based on the terms, as opposed to the > notions you are both attempting to convey with the terms. I was trying to nail down what the exact difference between a "class" and a "type" was. Some people seem to distinguish them, I don't know the difference. > >>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... > > Depends on your definitions of class and type does it not. yes but I was trying to find out what the "correct" (or widley used) definitions were! > >>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? > > A "built-in" type is one defined by the prog lang / system, and not by > a user of said / lang system. > > So nothing to do with "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. > > C uses "struct" as the keyword for defining tuple types. > > C++ changes the semantics of the C "struct" type (a struct is a specific > form of "class" ) . > > > What about arrays or unions (or is C++ just too broken to be hauled > > into the discussion?!) > > An array is a type. > C uses "union" as the keyword for defining basic "variant record" types. > > > but some people seem to think the type/class distinction is important > > Why ?? > If a distinction is important, there must be reasons (in the definitions > of type/class etc) for this to be so. and I was trying to found out what it was! Using the example of C++ (which isn't a very OO language) classes are a subset of types. There are types that aren't classes.
From: S Perryman on 26 Apr 2010 05:28 Nick Keighley wrote: > On 23 Apr, 15:43, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: NK>I'm not sure adding in polymorphism is useful at this [stage]. Could you NK>have a class "Integer"? >>Yes, e.g. { int_16, int_32, int_64, Big_Int } NK>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 > this sounds like a pretty weird defintion of class! So the thingies in > C++ (or UML) called "classes" aren't classes! AFAIK, this definition may come from the Ada prog lang. You have a type T. So "class(T)" means the set of all types that are substitutable for T (depending on the substitutability rules) . AFAIK, the general substitutability rules are for Ada : - ADTs The same as the Simula model - Fundamental types (numbers, enumerations etc) T2 is substitutable for T1 depending on things like whether there are subset/superset relationships between the values assignable to instances of T1 and T2. No doubt Dmitry +/- others familar with the semantics of the Ada type system will confirm/clarify the above. Regards, Steven Perryman
From: S Perryman on 26 Apr 2010 05:39 Nick Keighley wrote: > On 25 Apr, 15:41, S Perryman <a...(a)a.net> wrote: > I was trying to nail down what the exact difference between a "class" > and a "type" was. Some people seem to distinguish them, I don't know > the difference. As you will have seen from recent postings, the defs/differences seem to be based on specific prog langs. Which makes general debate difficult. NK>but some people seem to think the type/class distinction is important >>Why ?? >>If a distinction is important, there must be reasons (in the definitions >>of type/class etc) for this to be so. > and I was trying to found out what it was! Using the example of C++ > (which isn't a very OO language) classes are a subset of types. There > are types that aren't classes. In C++ , the keyword "class" denotes types that can inherit/redefine the (implementation) properties of other types. Additionally, the semantics of the C "struct" type have been changed to also allow such capabilities (and also a syntactic "short-hand" for the "public" access property) . The types that "aren't classes" cannot do this. Which as I said, is the reason why I talk in terms of type systems that allow one type to inherit the properties of other types. No "type" , no "class" etc. Only types, types that can inherit the properties of other types, and types that cannot. Regards, Steven Perryman
From: Dmitry A. Kazakov on 26 Apr 2010 10:03 On Mon, 26 Apr 2010 02:10:00 -0700 (PDT), Nick Keighley wrote: > On 23 Apr, 15:43, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> 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. > > I'm beginning to think you're using an unusual definition of class. Not really. If you considered what is a class type in the languages calling them "class", you would see that these are types you can derive from. The derived types share some common behavior, which the class type specify in some form. This way "Class" stands/is for this set of type. Class is about polymorphism (many types, same behavior). >>> the set of all entities sharing a common behaviour? >> >> Depending on the context it could be anything. > > I was rather hoping for a definition... It was a comment to the definition of yours: "the set of all entities sharing a common behaviour." >> BTW I didn't consider here >> OO modeling, if you had those objects in mind. > > is there a difference between the objects in OO modelling and OO > programming? In both cases I took them to be instances of classes (or > types in my case...). OO modeling deals with some domain where it tries to identify objects and classes. I care about programming language type system, not the way it might be applied. In particular which language entities represent which entities in the application domain. They could be many. >>>> What you mean under "class" is a polymorphic type that represents the >>>> class. > > well no I don't See below >>> I'm not sure adding in polymorphism is useful at this [stage]. 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 > > this sounds like a pretty weird defintion of class! So the thingies in > C++ (or UML) called "classes" aren't classes! No, they are exactly like this. A C++ class with virtual functions has values just like above. The type tag is vptr. The type specific value is the rest. >>>> 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>, ...}. > > class Point > { > public: > Point (int x, int y): x_(x), y_(y) {} > double distance_from_from_origin () { return sqrt (x_*x_ + > y_*y_); } > > private: > int x_; int y_; > }; > > sure looks like a class to me!! Just because of the word "class" in the declaration? >>>> 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] > > um. But a doesn't that ride a coach and horses through the Liskov > Substitution? 1. LSP is rubbish (no non-trivial LSP subtypes exist). 2. When you called Point a class you didn't care about LSP! const Point is not a LSP subtype of Point. Does it mean that Point shall not be a class? > A Trit isn't a Bool so it shouldn't derive from it. Huh, if you cared about LSP, you would note that generalization is much more LSP friendly that specialization. Because specialization gets broken in immutable methods, while generalization does in out and in-/out ones. Example: the famous Circle from Ellipse controversy. It is safer (but unsafe) to derive Ellipse from Circle than otherwise. But in reality I doubt you care about LSP. I certainly do not. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 26 Apr 2010 14:11
On Mon, 26 Apr 2010 16:03:30 +0200, Dmitry A. Kazakov wrote: > Huh, if you cared about LSP, you would note that generalization is much > more LSP friendly that specialization. Because specialization gets broken > in immutable methods, Mutable methods. Not my day today, sorry. > Example: the famous Circle from Ellipse controversy. It is safer (but > unsafe) to derive Ellipse from Circle than otherwise. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |