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: Dmitry A. Kazakov on 17 Apr 2010 03:33 On Fri, 16 Apr 2010 19:14:16 +0100, S Perryman wrote: > All I am saying is that IMHO a type checking system has to have as a > minimum (in order to be useful for developers in general) , the > intellectual/proving equivalence of kids whose maths ability is at a > particular level. Are you sure that kids are Turing complete? (:-)) >>>Multiple dispatch is a solved problem from the correctness viewpoint. >>>For a type system S, and an op M for which multiple dispatch can >>>occur, the type checker has to show (informally) : > >>>Regardless of what type of input/output parameters are >>>used for an invocation of M, there is at least one implementation of >>>M in S that can be used with said parameters. > >>>Obviously this requires analysis of a program (S) as a whole. >>>You cannot do this in a piecemeal way (separate compilation etc) . > >> But that would kill the idea. Clearly, modularity is a too important >> feature to be thrown away. > > You aren't discarding modularity. > > Merely ensuring that multiple dispatch cannot fail for M (whenever the > type system detects the possibility) for any given end program using M. > > This requires system-wide analysis (the end programs in C, Ada etc - > where S is static) . You need some "closed world assumptions" in order to > be certain that all combinations of input/output types will map to at > least one impl of M. Yes, but I want to be able to require all these combinations to be defined at some declaration point of a new type. If some types were invisible at this point, you should not be able to bring them in any context together with the declared type. E.g. procedure Print (P : in out Printer; S : Shape); context A: see shape Ellipse, printers Epson, Cannon, HP derive Circle from Ellipse implemented Print for Epson, Cannon, HP and Circle context B: see shape Ellipse derive Brother for Printer implemented Print for Brother and Ellipse context C: want to use Circle and Brother - type error! The problem is that this is too constraining. I need a way to add Print for Circle and Brother later, where both types are frozen, and use it in C. > For other envs (the dynamic loading / VM of Java etc) , you may not be > able to do so. Exactly. This is want I meant. (Modularity was probably not the best word) I have a problem with type checks postponed that late. > Although I think someone once mentioned here a prog lang > called "Nice" (extensions to Java) which supported multiple dispatch > and was able to check whether the closure of M covered all the types > seen in use as input/output parameters of M (cannot recall if twas done > at ".class" load time or not) . Interesting -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 17 Apr 2010 03:34 On Fri, 16 Apr 2010 11:46:59 -0700 (PDT), Nilone wrote: A short summary of the terminology: type = set of values + operations class = set of types [usually closed upon derivation], NOT A TYPE! object = a run-time instance of a type variable = a mutable object identified by name identity = value of a comparable type abstract type = a type without instances interface = an abstract type without implementation = type - implementation inheritance = membership in a class [built upon derivation] member operation in an argument/result = dispatching operation polymorphic = related to [the closure of] a class dispatch = conversion from polymorphic to specific subtype = inherits member operations = class member supertype = exports members subclass = subset of a class superclass = superset of a class covariant = member in the argument/result => inheritable contravariant = not a member = specific => non-inheritable > Going off into the realm of pure speculation, I'd like to find a way > to integrate OO and the relational model. Do I need to duck and run > for cover? ;) No. You need a type system capable to express relational container types (like tuples) and the algebra of these types. It is trivial in barely typed cases like SQL. It could be difficult if tuples hold ADTs. There are certain problems with that. The most difficult ones are type relations like between an array and its index, matrix and its plane, table and the result set etc. These are not specific to the relational model. So any type system can only gain from these problems solved. (RA alone has little interest, being a library of specialized containers) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Nilone on 17 Apr 2010 05:32 On Apr 16, 11:45 pm, Thomas Gagne <TandGandGA...(a)gmail.com> wrote: > Nilone wrote: > > 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. > > You could reference a language which has already figured this out, like > Smalltalk. If what you mean by "real" is the primitive data type > beneath IntegerType, then how IntegerType implements itself is supposed > to be hidden, isn't it? Right, the design of the number types in Smalltalk is very relevant and I learned a lot from it. I'm not sure where you're quoting "real" from, though, it doesn't appear in the part you quoted. I'm not using any primitive datatype beneath IntegerType. The point of that example was to recreate something like the integer types of procedural languages using only the OO mechanisms of the language.
From: Nilone on 17 Apr 2010 08:18 On Apr 17, 9:34 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > A short summary of the terminology: I think we mostly agree. I have just one or two questions / nitpicks. > type = set of values + operations We also need to include whether the set is the domain or codomain of the operations. > class = set of types [usually closed upon derivation], NOT A TYPE! This doesn't seem to include any notion of local state and methods on it. > type = set of values + operations > object = a run-time instance of a type > variable = a mutable object identified by name Where is object or instance in the definition of type, and where is value in the definition of object? The difference between "an instance of a type" and "a value of a type" is important here, so I'd appreciate it if you could go into that. > > No. You need a type system capable to express relational container types > (like tuples) and the algebra of these types. This topic has led to flame wars in the past. I hope it doesn't end up there again. I'll do my best to stay cool. ;) I see tuples (and arrays, and relations) as derived types, not container types. Using your terminology as best I can, a variable declared as a tuple(x : int, y : int) would be an object that stores and returns values from the set ZxZ, not an object containing two named int variables. The difference is significant, as can be seen in the problems with array covariance in Java and C#. > It could be difficult if tuples hold ADTs. There are > certain problems with that. The most difficult ones are type relations like > between an array and its index, matrix and its plane, table and the result > set etc. I don't see those problems yet. Would you mind pointing them out, or if you have any references that I could read, I would appreciate it. Nilone
From: Dmitry A. Kazakov on 17 Apr 2010 11:13
On Sat, 17 Apr 2010 05:18:12 -0700 (PDT), Nilone wrote: > On Apr 17, 9:34�am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> A short summary of the terminology: > > I think we mostly agree. I have just one or two questions / nitpicks. > >> type = set of values + operations > > We also need to include whether the set is the domain or codomain of > the operations. Both. Note that the operation can be one of many types. E.g. > is an operation of Integer in two arguments and an operation of Boolean in the result. >> class = set of types [usually closed upon derivation], NOT A TYPE! > > This doesn't seem to include any notion of local state and methods on > it. Yes, any set of types is a class. Examples: a class of types derived from T a class of instances of a template type a class of discrete types etc >> type = set of values + operations >> object = a run-time instance of a type >> variable = a mutable object identified by name > > Where is object or instance in the definition of type, Nowhere. There exist types with no objects. > and where is value in the definition of object? Any object's [visible] state maps to a certain value of its type. > The difference between "an > instance of a type" and "a value of a type" is important here, so I'd > appreciate it if you could go into that. Instance is an overloaded word. The difference is in the context. Objects are run-time or modeling artifacts. Values describe the semantics of the object states. They are entities of different domains, they never meet. >> No. You need a type system capable to express relational container types >> (like tuples) and the algebra of these types. > > This topic has led to flame wars in the past. I hope it doesn't end > up there again. I'll do my best to stay cool. ;) > > I see tuples (and arrays, and relations) as derived types, not > container types. I don't see why a container type cannot be a derived type. > Using your terminology as best I can, a variable > declared as a tuple(x : int, y : int) would be an object that stores > and returns values from the set ZxZ, not an object containing two > named int variables. I don't see any contradiction. The value of a tuple is a Cartesian product of values, e.g. (1, 2). The object having that value contains two other objects which values are 1 and 2. Where is a problem? Containment is an abstraction to getter and setter. You can obtain objects from a container, the way the compiler implements that is its business. Consider an array of Boolean packed into a register. Does it bother you that X[3] physically does not exist in the memory? >> It could be difficult if tuples hold ADTs. There are >> certain problems with that. The most difficult ones are type relations like >> between an array and its index, matrix and its plane, table and the result >> set etc. > > I don't see those problems yet. Would you mind pointing them out, or > if you have any references that I could read, I would appreciate it. Let you have a tuple type as above: int x int. You also have some cloud of types around it: 1. Table, a container of tuples 2. Result sets: ordered containers of tuples, of ints (from the column x), of ints (from the column y) 3. A plethora of types coming from operations involving several tables All these types are related to each other and you need methods declared on the table that use combinations of these types. Do you want to explicitly declare all that each time you create a new tuple type? But that is not all. Let you derive positive from int. What happens with the table? How the table, result sets of positive is related to the table of ints? Can you reuse operations of the latter? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |