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 14 Apr 2010 07:11 On Apr 14, 11:55 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Wed, 14 Apr 2010 10:31:35 +0100, S Perryman wrote: > > Dmitry A. Kazakov wrote: > > >> On Tue, 13 Apr 2010 14:18:15 -0700 (PDT), raould wrote: > > >> A mathematician would talk about different structures e.g. groups, lattices, > >> rings, fields. Elements of these structures have different behavior. > >> Internals of the elements, which would be an equivalent of "data", is not > >> even considered, it is uninteresting. > > > Actually, there is a "data" aspect that is abstract. > > An integer is a sign, and a sequence of digits. > > Yes, it is a part of integer behavior that a unique finite sequence of > decimal digits can be obtained from an integer. > > Another frequently used sequence is the sequence of sets: > > 0 = > 1 = { } > 2 = {{ }} > 3 = {{{ }}} > > etc. > > > A real is also the above, but with an 'index' that denotes the start of the > > suffix of the sequence that is the fractional part. > > > So -12345 is the abstraction ( - , [ 5, 4, 3, 2, 1] ) . > > And -123.45 is the abstraction ( - , [5, 4, 3, 2, 1 ] , 2) . > > Another difference is that the sequence can be infinite + not unique, e.g.. > 1 = 1.0 = 1.00 = 0.9(9) etc. > > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de I'm following this thread with great interest, and I would find it helpful if someone could clarify the distinction between the behaviour of the structure (i.e. field, group, ring, etc) versus the behaviour of points in the structure. Which should we be modeling? Also, how do the structures relate, i.e. can we derive one from another in an OO context?
From: S Perryman on 14 Apr 2010 09:55 Nilone wrote: > I'm following this thread with great interest, and I would find it > helpful if someone could clarify the distinction between the behaviour > of the structure (i.e. field, group, ring, etc) versus the behaviour > of points in the structure. Which should we be modeling? Dunno (Dmitry may answer) . You tell us. :-) My contention is that if you consider integers and reals in abstract (ADT) terms, there are properties that are "data" (and not "computational" ) in concept. In this case, the value of the number itself (as opposed to the operations that can be performed on the number) . > Also, how > do the structures relate, i.e. can we derive one from another in an OO > context? What do you mean by "derive in an OO context" ?? Property inheritance (abstraction and/or representation) ?? Type conformance/substitutability ?? Something else ?? Regards, Steven Perryman
From: S Perryman on 14 Apr 2010 11:14 Stefan Ram wrote: > raould <raould(a)gmail.com> writes: >>tho i think part of the problem here will be that we have to define >>"data" and "behaviour"; > Exactly! > That's also the reason, why I wrote that I do not understand > �to get rid of data� - I just do not know, what exactly �data� > means in this case. You don't have this problem if you talk in terms of *properties* . ADTs have a set of properties associated with them. One such property is invariant conditions. Another is the operations that can be performed on the ADT. Operations also have their own specific properties (input/output parameters and types, pre/post conditions) . Regards, Steven Perryman
From: Dmitry A. Kazakov on 14 Apr 2010 11:45 On Wed, 14 Apr 2010 04:11:20 -0700 (PDT), Nilone wrote: > I'm following this thread with great interest, and I would find it > helpful if someone could clarify the distinction between the behaviour > of the structure (i.e. field, group, ring, etc) versus the behaviour > of points in the structure. Individual points (values or states) do not have any behavior outside the structure they compose. A value does not exist without the type of. So it is meaningless to talk about them separately. > Which should we be modeling? Both. > Also, how > do the structures relate, i.e. can we derive one from another in an OO > context? In OO context one is interface another is an instance, or what do you mean? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Nilone on 14 Apr 2010 19:06
On Apr 14, 5:45 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Wed, 14 Apr 2010 04:11:20 -0700 (PDT), Nilone wrote: > > I'm following this thread with great interest, and I would find it > > helpful if someone could clarify the distinction between the behaviour > > of the structure (i.e. field, group, ring, etc) versus the behaviour > > of points in the structure. > > Individual points (values or states) do not have any behavior outside the > structure they compose. > > A value does not exist without the type of. So it is meaningless to talk > about them separately. Thanks. That matches my own thoughts, which leads me to implement integers in the following way (using Java as a representative class- based language): public class IntegerType { public static class IntegerValue { // no publicly accessible constructor private IntegerValue() { } // package-private representation and parametrized constructors ... } // no publicly accessible constructor private IntegerType() { } // operators and relations public static IntegerValue FromString(String s) { ... } public static String ToString(IntegerValue v) { ... } public static IntegerValue Add(IntegerValue v1, IntegerValue v2) { ... } public static boolean Equal(IntegerValue v1, IntegerValue v2) { ... } ... } And I expect that all algebraic data structures would follow a similar design. Any comments, criticism or refinement? > > Also, how > > do the structures relate, i.e. can we derive one from another in an OO > > context? > > In OO context one is interface another is an instance, or what do you mean? I think I'm trying to understand how to implement homomorphisms on algebraic data structures implemented as OO classes. Nilone |