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: Nilone on 20 Apr 2010 04:42 On Apr 19, 8:23 pm, S Perryman <a...(a)a.net> wrote: > All very nice, but irrelevant to my query. > > Give examples of all the types of "containers" that you believe to exist > in the mainstream world of software development. I'm not trying to avoid the question, it's just that when I think about it, the notion of a "type of container" breaks down to the implementation of a particular container. I'm willing to talk about classes of containers, with the understanding that classes aren't exclusive, i.e. an indexed container can also be a LIFO container. > Once you can tell us what you consider to be "containers" , then I > can scrutinise other things you have written in your debate on the topic. I consider a container to be any object of a class for which store and retrieve semantics are defined. > If you are struggling to do so, here is something I consider to be a > "container" : sets. Take Dmitry's definition of types as domain sets + operators. Would you consider that use of set to be a container? By my definition, it isn't, since it's not an object into which I can store things, although I could store values from a set in a container. I couldn't call a set a data structure either, although data structures can represent finite sets of values. > Hopefully that will propel you to give other examples that satisfy your > definition. I still didn't give examples, but I hope my post explains why. Nilone
From: Nilone on 20 Apr 2010 04:44 On Apr 19, 2:11 pm, Nilone <rea...(a)gmail.com> wrote: > On Apr 18, 10:33 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > > Before I reply to your points, I'd like to check if we should > continue. We seem to be talking past each other, and reasserting the > same points won't bring any progress. I do value your point of view, > even though I'm not yet familiar with thinking in that way, and I > don't want to make an enemy of someone so patient and intelligent as > you are. I'm not arguing that you're wrong in any way (except for the > FACT that structures AREN'T the same thing as containers, NOT EVER, LA > LA LA can't hear you :P), only that I think your views are > complemented by it's opposite, rather than contradicted. No? Well, if not, then I thank you for your time and effort. It may not seem like it, but I did learn some things and I appreciate it.
From: Nilone on 19 Apr 2010 08:11 On Apr 18, 10:33 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: Before I reply to your points, I'd like to check if we should continue. We seem to be talking past each other, and reasserting the same points won't bring any progress. I do value your point of view, even though I'm not yet familiar with thinking in that way, and I don't want to make an enemy of someone so patient and intelligent as you are. I'm not arguing that you're wrong in any way (except for the FACT that structures AREN'T the same thing as containers, NOT EVER, LA LA LA can't hear you :P), only that I think your views are complemented by it's opposite, rather than contradicted.
From: Dmitry A. Kazakov on 20 Apr 2010 06:41 On Mon, 19 Apr 2010 19:49:08 +0100, S Perryman wrote: > Dmitry A. Kazakov wrote: > >> 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. As an example, consider P declaring a new printer, U declaring a new shape. P+U has to declare an overriding of Print. > 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) . First there must a declaration of. There is a problem with identifying the context where the language must require such a declaration, since types are frozen and already in use. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: S Perryman on 20 Apr 2010 07:41
Nilone wrote: > On Apr 19, 8:23 pm, S Perryman <a...(a)a.net> wrote: >>All very nice, but irrelevant to my query. >>Give examples of all the types of "containers" that you believe to exist >>in the mainstream world of software development. > I'm not trying to avoid the question, it's just that when I think > about it, the notion of a "type of container" breaks down to the > implementation of a particular container. I'm willing to talk about > classes of containers, with the understanding that classes aren't > exclusive, i.e. an indexed container can also be a LIFO container. I want to see some real examples of "containers" >>Once you can tell us what you consider to be "containers" , then I >>can scrutinise other things you have written in your debate on the topic. > I consider a container to be any object of a class for which store and > retrieve semantics are defined. The problem for me is that you have not defined your terms precisely enough. Does "store semantics" mean insertion ?? Something else ?? 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. Which makes debate with you difficult at best. >>If you are struggling to do so, here is something I consider to be a >>"container" : sets. > Take Dmitry's definition of types as domain sets + operators. Would > you consider that use of set to be a container? 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* . 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. Similarly for arrays, sequences, queues, maps etc. > By my definition, it > isn't, since it's not an object into which I can store things, > although I could store values from a set in a container. I couldn't > call a set a data structure either, although data structures can > represent finite sets of values. All moot until we have precise definitions from you. Regards, Steven Perryman |