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 29 Apr 2010 04:59 On 26 Apr, 15:03, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > 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). light is slowly beginning to dawn. I'l try to summarise what I understand you to mean. Type: a value and a set of operations on that value Class: a set containing a type and all the types its derived from. So polymorphism/specialisation *is* the important thing about classes. My examples were trivial classes in that there was no specialisation going on. Am I getting closer? <snip> > >>>> 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? well it's an indication of intent! isn;y it a degenerate class? One having no parents? > >>>> 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). oo. I'd always thought it was important... > 2. When you called Point a class you didn't care about LSP! no? Why because Point isn't very interesting from a derivation point of view? > const Point is not a LSP subtype of Point. yes... > Does it mean that Point shall not be a class? er no. I don't see why Point can't be a class. Suppose we have an abstract class Tile. Tiles can be drawn (perhaps we are making a mosaic). There are derived classes PlainTile (which have a single colour) and StripedTile (which have several colours). Does this avoid LSP problems as Tile is abstract? Is it deriving from concrete or partically concrete classes taht give LSP difficulties? > > 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 [Mutable] 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. I'd come across the Circle/Ellipse example. > But in reality I doubt you care about LSP. I certainly do not. well I thought I did... Isn't polymorphism all about being able to substitute types?
From: Nick Keighley on 29 Apr 2010 05:00 On 26 Apr, 10:39, S Perryman <a...(a)a.net> wrote: > 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. thanks. At least I think I understand the question better now
From: Dmitry A. Kazakov on 29 Apr 2010 05:47 On Thu, 29 Apr 2010 01:59:35 -0700 (PDT), Nick Keighley wrote: > So polymorphism/specialisation *is* the important thing about classes. Yes. > My examples were trivial classes in that there was no specialisation > going on. You never know how a type will be used later In my view it makes sense to be able to derive from any type. >>> 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? > > well it's an indication of intent! isn;y it a degenerate class? One > having no parents? It still has a public interface, which can be considered as an abstract "parent". But the question was why to call this type "class." Does the word "type" sound bad? What is the sematic meaning of "class." To me class => polymorphism => a set. I don't know what is it for people calling types "class." >> 1. LSP is rubbish (no non-trivial LSP subtypes exist). > > oo. > > I'd always thought it was important... Important is substitutability (in order to reuse code). LSP is a failed attempt to achieve that. >> 2. When you called Point a class you didn't care about LSP! > > no? Why because Point isn't very interesting from a derivation point > of view? I could specialize, generalize, extend Point in many directions. Consider ASCII_Terminal_Point, Postscript_Point, Color_CMYK_Point etc. > Suppose we have an abstract class Tile. Tiles can be drawn (perhaps we > are making a mosaic). There are derived classes PlainTile (which have > a single colour) and StripedTile (which have several colours). Does > this avoid LSP problems as Tile is abstract? No, because some abstract methods can turn impossible implement on the whole class (for all concrete derived types). > Is it deriving from > concrete or partically concrete classes taht give LSP difficulties? Any deviation does. Whatever you change, if the change is substantial = changes the behavior, that evidently breaks some propositions about objects => breaks LSP. It does not imply that it breaks substitutability in the concrete program. LSP is a far stronger statement, it is about all possible programs. But you are interested in your concrete program, maybe a cloud of programs (as you change the program during the project's evolution etc), that is a way out. More programs we bring into consideration more difficult in becomes. It is asymptotically impossible, which is the LSP. >> But in reality I doubt you care about LSP. I certainly do not. > > well I thought I did... Isn't polymorphism all about being able to > substitute types? Yes, but that does not require LSP, not even substitutability. You can substitute unsigned for int even if some unsigneds are non-substitutable. It is a problem, but not yet a bug, so long you do not substitute those. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: S Perryman on 29 Apr 2010 06:17
Nick Keighley wrote: > On 26 Apr, 15:03, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >>But in reality I doubt you care about LSP. I certainly do not. > well I thought I did... Isn't polymorphism all about being able to > substitute types? No. Polymorphism is about entities existing in (multiple) different forms. Type substitutability is makes polymorphism useful. Similarly with type substitutability and inheritance (the Simula model) . Regards, Steven Perryman |