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 19 Apr 2010 14:49 Dmitry A. Kazakov wrote: > On Mon, 19 Apr 2010 13:50:42 +0100, S Perryman wrote: >>If there is an unsupported implementation for an actual M/input/output >>instance, that is a defect. > Only if that implementation is ever called. If we knew statically that it > is not called, we could safely ignore the defect. This scenario by definition is not a defect. >>Tis interesting to me as to what the middle ground is or might be. >>Or in a semi-precise mathematical form, forall : >>- program = P >>- T(P) = the type information that allows proof that no multiple dispatch >> defects exist in P >>Then for an incremental addition to P involving program unit U >>(program = P+U) : >>What are the contents of T(P) , T(U) , T(P+U) ?? > If T(U) then for P+U it must be shown that there is no contexts where any > two types causing a defect can be both instantiated. I don't see it as an > insuperable obstacle in a manifestedly typed language. What puzzles me is > how to provide necessary implementations. The problem is that the offending > types from P and U are already frozen in P+U. It is too late to override > anything there. [It is the issue of the last point where new methods can be > added to an interface. It cannot be anywhere, not before the first type > use.] There should be some graceful solution to that. We have the notion of the "open-closed" principle here. 1. You have to re-evaluate correctness, such that : correct(T(P+U) ) implies (correct(T(P) and T(U) ) 2. You have to recompute the dispatch 'closure' (DC for the sake of debate) . The requirement being : DC(P+U) can be used in place of DC(P) and DC(U) . For 1, T(P) and T(U) might have to be type manifests for detected possibilities of multiple dispatch. The runtime system then has to compute T(P+U) and ensure its correctness. Once correctness is ensured, then you are down to the dynamic loading issue (there should be an impl somewhere, in the units that comprise P+U) . >>>This is somewhat similar to loading libraries of incompatible versions, but much >>>worse. Most likely I will have no slightest idea what the problem is. One >>>library provides a new printer, another does a new shape, and I, the end >>>user, cannot use them together even if I don't use the missing combination. >>>Even worse, if I don't print anything, but there is a third library that >>>does, it won't load. That looks like a maintenance disaster. >>It adds another dimension into the realms of possible defect causes. >>But only for the 'dynamic loading' scenario. > Even if loaded components have statically known interfaces? That sounds > very disappointing. The required distinction is between all invocations of M being correct when they occur (after the required impls have been loaded into the system etc) , and loading errors (missing units etc) . Tis unacceptable for the same error to be reported for both scenarios (think of weakly-typed prog langs and the "does not understand" message, when an op is invoked on a "null" / non-null object) . Regards, Steven Perryman
From: Nilone on 20 Apr 2010 15:27 On Apr 20, 1:41 pm, S Perryman <a...(a)a.net> wrote: > I want to see some real examples of "containers" OK, since you're not asking for types of containers but for examples of containers, how about direct instances (as opposed to instances of subclasses) of ArrayList, Hashtable, Queue, SortedList and Stack in .Net? Note that C# is a mixed paradigm language, and all of those have non- OO features mixed in. > The problem for me is that you have not defined your terms precisely > enough. > > Does "store semantics" mean insertion ?? Something else ?? In OO, you pass a message to an object. What the object does with it is it's own business. By store and retrieve semantics, I meant that if you have an object to which you can pass objects and from which you can receive objects, you have a container. The terms seem vague because the concept of a container is very general. > You have these terms "container" , "data structure" , "store" etc that > apparently are intended to define, and distinguish between, certain > concepts. > > I am none the wiser as to how they all relate together, differ etc. I'm trying to clarify that myself. Data structure doesn't seem too difficult - see http://en.wikipedia.org/wiki/Data_structure. "Container" was introduced into this thread by Dmitry in the phrase "container types" to describe tuples, which he subsequently described as: On Apr 17, 5:13 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > 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. I only latched onto that notion of container, I didn't define it. The problem is, applying that description to data structures like tuples conflates the logical structure of data with the storage of such data in memory. > Which makes debate with you difficult at best. I apologise for the difficulty. If this discussion is as time- consuming for you as it is for me, then I'm very grateful for your effort. I suspect I'm worse off, though, since I'm a pedant and I write slowly. ;) > For me, a container (or collection) is a concept (abstraction) about > considering a number of elements as a whole. > > The container may be manipulated in terms of the whole, or in terms of > the constituent elements. > > Each operation defines the manner/effects of all such manipulations. > > All of these can be discussed *without reference to any particular > implementation* . Abstractions describe elements of a domain in general by ignoring their differences. Those differences can be behavioural or structural. Abstracting over behaviour to describe structure is no more "implementation" than abstracting over structure to describe behaviour. > > Given this, then : > > Sets consider a number of elements as a whole. > The "operators" manipulate sets as a whole (union, intersection > etc) , and in terms of individual elements (insert etc) . > > Set is a container. Your container has set-theoretic methods, but I wouldn't give it such a general name as Set. Here's a partial implementation of a C# class that also has set-theoretical methods, but it doesn't do individual elements or insertion. class Set<T> { public delegate bool MemberFunction(T element); MemberFunction ismember; public Set(MemberFunction func) { ismember = func; } public bool IsMember(T element) { return ismember(element); } static public Set<T> Union(Set<T> set1, Set<T> set2) { return new Set<T>((T x) => set1.IsMember(x) || set2.IsMember(x)); } static public Set<T> Intersection(Set<T> set1, Set<T> set2) { return new Set<T>((T x) => set1.IsMember(x) && set2.IsMember(x)); } } > Similarly for arrays, sequences, queues, maps etc. I'll grant you the queue - most definitions require adding elements to a queue as a fundamental part of the abstraction. The rest aren't containers, although you can build containers that implement those abstractions.
From: Nilone on 20 Apr 2010 15:40 On Apr 20, 1:41 pm, S Perryman <a...(a)a.net> wrote: > I want to see some real examples of "containers" OK, since you're not asking for types of containers but for examples of containers, how about direct instances (as opposed to instances of subclasses) of ArrayList, Hashtable, Queue, SortedList and Stack in .Net? > The problem for me is that you have not defined your terms precisely > enough. > > Does "store semantics" mean insertion ?? Something else ?? In OO, you pass a message to an object. What the object does with it is it's own business. By store and retrieve semantics, I meant that if you have an object to which you can pass objects and from which you can receive objects, you have a container. > You have these terms "container" , "data structure" , "store" etc that > apparently are intended to define, and distinguish between, certain > concepts. > > I am none the wiser as to how they all relate together, differ etc. I'm trying to clarify that myself. Data structure doesn't seem too difficult - see http://en.wikipedia.org/wiki/Data_structure. "Container" was introduced by Dmitry in the phrase "container types" to describe tuples, which he subsequently described as: On Apr 17, 5:13 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > 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. I only latched onto that notion of container, I didn't define it. The problem is, applying that description to data structures like tuples conflates the logical structure of data with its containment in memory. > Which makes debate with you difficult at best. I apologise for the difficulty. If this discussion is as time- consuming for you as it is for me, then I'm very grateful for your effort. I suspect I'm worse off, though, since I'm a pedant and I write slowly. ;) > For me, a container (or collection) is a concept (abstraction) about > considering a number of elements as a whole. > > The container may be manipulated in terms of the whole, or in terms of > the constituent elements. > > Each operation defines the manner/effects of all such manipulations. > > All of these can be discussed *without reference to any particular > implementation* . Abstractions describe elements of a domain in general by ignoring their differences. Those differences can be behavioural or structural. Abstracting over behaviour to describe structure is no more "implementation" than abstracting over structure to describe behaviour. > > Given this, then : > > Sets consider a number of elements as a whole. > The "operators" manipulate sets as a whole (union, intersection > etc) , and in terms of individual elements (insert etc) . > > Set is a container. Your container has set-theoretic methods, but I wouldn't give it such a general name as Set. Here's a partial implementation of a C# class that also has set-theoretical methods, but it doesn't do individual elements or insertion. class Set<T> { public delegate bool MemberFunction(T element); MemberFunction ismember; public Set(MemberFunction func) { ismember = func; } public bool IsMember(T element) { return ismember(element); } static public Set<T> Union(Set<T> set1, Set<T> set2) { return new Set<T>((T x) => set1.IsMember(x) || set2.IsMember(x)); } static public Set<T> Intersection(Set<T> set1, Set<T> set2) { return new Set<T>((T x) => set1.IsMember(x) && set2.IsMember(x)); } } > Similarly for arrays, sequences, queues, maps etc. I'll grant you the queue - most definitions require adding elements to a queue as a fundamental part of the abstraction. The rest aren't containers, although you can build containers that implement those abstractions.
From: Nilone on 20 Apr 2010 16:31 On Apr 20, 1:41 pm, S Perryman <a...(a)a.net> wrote: > I want to see some real examples of "containers" OK, since you're not asking for types of containers but for examples of containers, how about direct instances (as opposed to instances of subclasses) of ArrayList, Hashtable, Queue, SortedList and Stack in .Net? > The problem for me is that you have not defined your terms precisely > enough. > > Does "store semantics" mean insertion ?? Something else ?? In OO, you pass a message to an object. What the object does with it is it's own business. By store and retrieve semantics, I meant that if you have an object to which you can pass objects and from which you can receive objects, you have a container. > You have these terms "container" , "data structure" , "store" etc that > apparently are intended to define, and distinguish between, certain > concepts. > > I am none the wiser as to how they all relate together, differ etc. I'm trying to clarify that myself. Data structure doesn't seem too difficult - see http://en.wikipedia.org/wiki/Data_structure. "Container" was introduced by Dmitry in the phrase "container types" to describe tuples, which he subsequently described as: On Apr 17, 5:13 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > 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. I only latched onto that notion of container, I didn't define it. The problem is, applying that description to data structures like tuples conflates the logical structure of data with its containment in memory. > Which makes debate with you difficult at best. I apologise for the difficulty. If this discussion is as time- consuming for you as it is for me, then I'm very grateful for your effort. I suspect I'm worse off, though, since I'm a pedant and I write slowly. ;) > For me, a container (or collection) is a concept (abstraction) about > considering a number of elements as a whole. > > The container may be manipulated in terms of the whole, or in terms of > the constituent elements. > > Each operation defines the manner/effects of all such manipulations. > > All of these can be discussed *without reference to any particular > implementation* . Abstractions describe elements of a domain in general by ignoring their differences. Those differences can be behavioural or structural. Abstracting over behaviour to describe structure is no more "implementation" than abstracting over structure to describe behaviour. > > Given this, then : > > Sets consider a number of elements as a whole. > The "operators" manipulate sets as a whole (union, intersection > etc) , and in terms of individual elements (insert etc) . > > Set is a container. Your container is one possible implementation of a set. Here's another, and it doesn't do individual elements or insertion: class Set<T> { public delegate bool MemberFunction(T element); MemberFunction ismember; public Set(MemberFunction func) { ismember = func; } public bool IsMember(T element) { return ismember(element); } static public Set<T> Union(Set<T> set1, Set<T> set2) { return new Set<T>((T x) => set1.IsMember(x) || set2.IsMember(x)); } static public Set<T> Intersection(Set<T> set1, Set<T> set2) { return new Set<T>((T x) => set1.IsMember(x) && set2.IsMember(x)); } } A set is defined by its elements, not how those elements are stored or computed, which is an implementation detail. > Similarly for arrays, sequences, queues, maps etc. I'll grant you the queue - most definitions require adding elements to a queue as a fundamental part of the abstraction. The rest aren't containers, although you can build containers that implement those abstractions.
From: Nilone on 20 Apr 2010 16:58
On Apr 20, 10:31 pm, Nilone <rea...(a)gmail.com> wrote: Sorry for the multiple posts, everyone. Google's news server was unresponsive for a while. |