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: S Perryman on 21 Apr 2010 16:05 Dmitry A. Kazakov wrote: > Beware. Beware what ?? Someone who is failing to articulate or precisely specify what they mean, is to helped to that end, not to be avoided. I am looking at postings from someone, and asking : - what are they seeking - what did they want to say Don't think IMHO that either was achieved satisfactorily. I didn't get anything new to ponder ... Regards, Steven Perryman
From: S Perryman on 25 Apr 2010 10:41 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. >>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. >>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. Regards, Steven Perryman
From: Dmitry A. Kazakov on 26 Apr 2010 04:44 On 25 Apr 2010 23:56:59 GMT, Stefan Ram wrote: > S Perryman <a(a)a.net> writes: >>C uses "struct" as the keyword for defining tuple types. > > The defining assertion for an n-tuple is, that an n-tuple is > equal to another n-tuple iff each component of the first > n-tuple is equal to the corresponding component of the other > tuple. Yes, but that does not imply type equivalence. In a strongly typed language (which C++ partially is) equivalence is usually nominal. So even if two types have equivalent sets of values and equivalent sets of operations they are still not equivalent. >>C++ changes the semantics of the C "struct" type (a struct is a specific >>form of "class" ) . > > There are no structs in C++, there are only classes. You refer here to the keywords "struct" and "class". Semantically C's struct is C++'s class without virtual functions. >>If a distinction is important, there must be reasons (in the definitions >>of type/class etc) for this to be so. > > In Java, every class is a type, but not every type is a class. > The meaning of these words depend on their definition. So in > other languages, this might differ. To analyze and compare type systems, there must a language-independent terminology. Anyway, if class-type /= type there must be a rationale why some types have classes while others do not. This may not be based on any implementation merits, but on the type semantics. The point is that for the 1st class types (e.g. numbers, containers etc) there is no obvious semantic reason why some of them shall not be classes. Java has this distinction because of inconsistency of its type model, namely a false presumption that "classes" shall have referential semantics. P.S. For the 2nd class types like functions, sets of 1st class types etc, there might be some reasons. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Nick Keighley on 26 Apr 2010 05:10 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. I'm pretty sure most of the OO books I've read don't define it like that! > >>> 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. I was rather hoping for a definition... > 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...). > >> What you mean under "class" is a polymorphic type that represents the > >> class. well no I don't > > 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! > >> 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. ok. > 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>, ...}. 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!! > >> 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. I was womndering if "types" were built in types (int, float) and "classes" were composed of "types" (point, employee). But no. > >> 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. ok... > >> 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? A Trit isn't a Bool so it shouldn't derive from it. > >> Others develop languages where Boolean occupies several machine words. > > > this caused by class/type confusion? > > among other mistakes... -- Nick Keighley "in flippin pig mode again" Text found in macintosh resource fork
From: S Perryman on 26 Apr 2010 05:15
Stefan Ram wrote: > S Perryman <a(a)a.net> writes: >>C uses "struct" as the keyword for defining tuple types. > The defining assertion for an n-tuple is, that an n-tuple is > equal to another n-tuple iff each component of the first > n-tuple is equal to the corresponding component of the other tuple. Is it ?? Can you refer me to some doc etc that states this "defining assertion" . > Let's see whether C implements this fundamental equality relationship > for struct values: [...] So C does not provide the full properties of "n-tuples" as you "assert" should be so. So what ?? [ snipped - but read and acknowledged ] No major reply from me, as IMHO Dmitry Kazakov appears to have succinctly clarified your misunderstandings via his comments. But IMHO you should take note of one specific comment : "To analyze and compare type systems, there must a language-independent terminology." Regards, Steven Perryman |