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 23 Apr 2010 04:24 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. > > > 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? > What you mean under "class" is a polymorphic type that represents the > class. I'm not sure adding in polymorphism is useful at this state. Could you have a class "Integer"? Is it polymorphic? > There are three things in this context: > > 1. type T, also "specific type" which rather begs the question "whats a type"? > 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 > 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? > 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? > 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! > Others develop languages > where Boolean occupies several machine words. this caused by class/type confusion?
From: S Perryman on 21 Apr 2010 08:06 Nilone wrote: > 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? - ArrayList Implementation of a container abstraction (sequence) in terms of an array (another container abstraction) . - Hashtable Implementation of a container abstraction (map) using "hash tables" . - SortedList A container abstraction (ordered sequence) . - Queue/Stack Container abstraction (queue/stack) . Problem is, using your own definition, none of sequence/queue/stack are containers. They are all "logical arrangements" . In this case, by virtue of their relationship to arrays (which you have claimed is a "logical arrangement" ) . And so too for maps, if you do not consider sets to be a container. If not so, feel free to define / demonstrate "logical arrangement" , so we can see why is array is one, and say sequence is not. >>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. Oh, bad bad definition. A container has a notion of enclosure, or something being within. By the above, a structured comms link would be a container (sending/ receiving objects across the wire) . >>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. I don't consider a tuple to be a container as such. Although tuples do have properties akin to arrays (and arrays are fixed-size containers - well to me anyway) . >>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. What is a "behavioural" and "structural" difference ?? >>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. No. A set is one possible *form (type)* of container. > Here's another, and it doesn't do individual elements or insertion: You have provided a container that has *some of the properties* of a set. Not having all of the properties of a set (insertion etc) means the container is not a set. > A set is defined by its elements, not how those elements are stored or > computed, which is an implementation detail. A set is defined by its *properties* . Those properties are what distinguish sets from other forms of container. >>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. Most definitions require adding elements to sequences, to maps etc too. Regards, Steven Perryman
From: Dmitry A. Kazakov on 21 Apr 2010 08:31 On Wed, 21 Apr 2010 13:06:49 +0100, S Perryman wrote: > Nilone wrote: > >> A set is defined by its elements, not how those elements are stored or >> computed, which is an implementation detail. > > A set is defined by its *properties* . > Those properties are what distinguish sets from other forms of container. Beware. Nilone confuses objects and types. So where you mean a type he means, I cannot tell what, but in this example it looks like an individual set. Since the container abstraction lies two stores above (elements->sets->containers), it is not surprising that he denies that very notion. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Nilone on 21 Apr 2010 09:59 On Apr 21, 2:06 pm, S Perryman <a...(a)a.net> wrote: > You have provided a container that has *some of the properties* of > a set. Not having all of the properties of a set (insertion etc) means > the container is not a set. Thanks for the feedback. I feel further progress in this debate isn't possible now, and other matters have drawn my attention away. I appreciate all your time and effort, and I'll be back, but for now, I'm going to let it rest. Nilone
From: Daniel T. on 21 Apr 2010 15:24
Nilone <reaanb(a)gmail.com> wrote: > On Apr 21, 2:06�pm, S Perryman <a...(a)a.net> wrote: > > You have provided a container that has *some of the properties* of > > a set. Not having all of the properties of a set (insertion etc) means > > the container is not a set. > > Thanks for the feedback. I feel further progress in this debate isn't > possible now, and other matters have drawn my attention away. I > appreciate all your time and effort, and I'll be back, but for now, > I'm going to let it rest. No problem Nilone, sometimes we just have to "step away from the keyboard." I, for one, understand completely and I hope you come back soon. |