f



Mixing OO and DB

I know both object oriented programming and DB (SQL). But it seems
that these are incompatible. Or may somebody advice how to meddle them
together?

Being strong in both OOP and DB development, I am yet weak in writing
object oriented programs which use DB.

Maybe somebody may suggest me some article about mixing together DB
and OOP?
0
porton (14)
2/7/2008 8:35:26 PM
comp.object 3218 articles. 1 followers. Post Follow

892 Replies
1037 Views

Similar Articles

[PageSpeed] 10

On Feb 7, 12:35 pm, Victor Porton <por...@narod.ru> wrote:
> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible.

I suggest that OO ideas are too naive to continue influence
programming. Formal Concept Analysis (FCA) is much more theoretically
sound method how to organize things into taxonomies.

Here is an example -- a hierarchy of living things, restricted to the
set {Lamprey, Trout, Lungfish, ..., Human}. FCA starts with feature
matrix like this:

	           Jaws	Limbs	Hair	Lungs	Tail	Shell
Lamprey	0	0	0	0	1	0
Trout	            1	0	0	0	1	0
Lungfish	1	0	0	1	1	0
Turtle	            1	1	0	1	1	1
Cat	            1	1	1	1	1	0
Gorilla	            1	1	1	1	0	0
Human	            1	1	1	1	0	0

Then, the objects and the attributes (aka concepts) organize
themselves into a lattice like this

Lamprey -> Trout -> Lungfish -> Cat -> Gorilla
                       |         |
                       |         ---> Human
                       |
                       ----> Turtle

which is more powerful concept than OO hierarchy of classes. Each FCA
concept is essentially a limited form of a relation.

There are some reasons why FCA methods never enjoyed a success
comparable to OO and Relational Model. They are simply more
restrictive sets of relations which obey distributive property, why
relations in general don't.
0
2/7/2008 9:00:15 PM
On Feb 7, 12:35 pm, Victor Porton <por...@narod.ru> wrote:
> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?
>
> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.
>
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?

They *are* incompatible. Here's an excerpt from wikipedia:

Key philosophical differences between the OO and relational models can
be summarized as follows:

Declarative vs. imperative interfaces -- Relational thinking tends to
use data as interfaces, not behavior as interfaces. It thus has a
declarative tilt in design philosophy in contrast to OO's behavioral
tilt. (Some relational proponents propose using triggers, etc. to
provide complex behavior, but this is not a common viewpoint.)

Schema bound -- Objects do not have to follow a "parent schema" for
which attributes or accessors an object has, while table rows must
follow the entity's schema. A given row must belong to one and only
one entity. The closest thing in OO is inheritance, but it is
generally tree-shaped and optional. A dynamic reformulation of
relational theory may solve this, but it is not practical yet.

Access rules -- In relational databases, attributes are accessed and
altered through predefined relational operators, while OO allows each
class to create its own state alteration interface and practices. The
"self-handling noun" viewpoint of OO gives independence to each object
that the relational model does not permit. This is a "standards versus
local freedom" debate. OO tends to argue that relational standards
limit expressiveness, while relational proponents suggest the rule
adherence allows more abstract math-like reasoning, integrity, and
design consistency.

Relationship between nouns and actions -- OO encourages a tight
association between operations (actions) and the nouns (entities) that
the operations operate on. The resulting tightly-bound entity
containing both nouns and the operations is usually called a class, or
in OO analysis, a concept. Relational designs generally do not assume
there is anything natural or logical about such tight associations
(outside of relational operators).

Uniqueness observation -- Row identities (keys) generally have a text-
representable form, but objects do not require an externally-viewable
unique identifier.

Object identity -- Objects (other than immutable ones) are generally
considered to have a unique identity; two objects which happen to have
the same state at a given point in time are not considered to be
identical. Relations, on the other hand has no inherent concept of
this kind of identity. That said, it is a common practice to fabricate
"identity" for records in a database through use of globally-unique
candidate keys; though many consider this a poor practice for any
database record which does not have a one-to-one correspondence with a
real world entity. (Relational, like objects, can use domain keys if
they exist in the external world for identification purposes).
Relational systems strive for "permanent" and inspect-able
identification techniques, where-as object identification techniques
tend to be transient or situational.

Normalization -- Relational normalization practices are often ignored
by OO designs. However, this may just be a bad habit instead of a
native feature of OO. An alternate view is that a collection of
objects, interlinked via pointers of some sort, is equivalent to a
network database; which in turn can be viewed as an extremely-
denormalized relational database.

Schema inheritance -- Most relational databases do not support schema
inheritance. Although such a feature could be added in theory to
reduce the conflict with OOP, relational proponents are less likely to
believe in the utility of hierarchical taxonomies and sub-typing
because they tend to view set-based taxonomies or classification
systems as more powerful and flexible than trees. OO advocates point
out that inheritance/subtyping models need not be limited to trees
(though this is a limitation in many popular OO languages such as
Java), but non-tree OO solutions are seen as more difficult to
formulate than set-based variation-on-a-theme management techniques
preferred by relational. At the least, they differ from techniques
commonly used in relational algebra.

Structure vs. behaviour -- OO primarily focuses on ensuring that the
structure of the program is reasonable (maintainable, understandable,
extensible, reusable, safe), whereas relational systems focus on what
kind of behaviour the resulting run-time system has (efficiency,
adaptability, fault-tolerance, liveness, logical integrity, etc.).
Object-oriented methods generally assume that the primary user of the
object-oriented code and its interfaces are the application
developers. In relational systems, the end-users' view of the
behaviour of the system is sometimes considered to be more important.
However, relational queries and "views" are common techniques to re-
represent information in application- or task-specific configurations.
Further, relational does not prohibit local or application-specific
structures or tables from being created, although many common
development tools do not directly provide such a feature, assuming
objects will be used instead. This makes it difficult to know whether
the stated non-developer perspective of relational is inherent to
relational, or merely a product of current practice and tool
implementation assumptions.

As a result of the object-relational impedance mismatch, it is often
argued by partisans on both sides of the debate that the other
technology ought to be abandoned or reduced in scope. Some database
advocates view traditional "procedural" languages as more compatible
with a RDBMS than many OO languages; and/or suggest that a less OO-
style ought to be used. (In particular, it is argued that long-lived
domain objects in application code ought not to exist; any such
objects that do exist should be created when a query is made and
disposed of when a transaction or task is complete). On the other
hand, many OO advocates argue that more OO-friendly persistence
mechanisms, such as OODBMS, ought to be developed and used, and that
relational technology ought to be phased out. Of course, it should be
pointed out that many (if not most) programmers and DBAs do not hold
either of these viewpoints; and view the object-relational impedance
mismatch as a mere fact of life that Information Technology has to
deal with.

(end quote)

-T-
0
topmind (2124)
2/7/2008 9:01:25 PM
On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:

> I suggest that OO ideas are too naive to continue influence
> programming. Formal Concept Analysis (FCA) is much more theoretically
> sound method how to organize things into taxonomies.

Sorry, but the idea of subsets used in place of subtypes far surpasses in
naiveness anything one could charge "naive OO" with.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/7/2008 10:04:15 PM
On Feb 7, 2:04=A0pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:
> > I suggest that OO ideas are too naive to continue influence
> > programming. Formal Concept Analysis (FCA) is much more theoretically
> > sound method how to organize things into taxonomies.
>
> Sorry, but the idea of subsets used in place of subtypes far surpasses in
> naiveness anything one could charge "naive OO" with.

Are you referring to apparent object propelleheads unability to even
coherently define what the object/type is? Then, the ability to
operate a concept without defining it is certainly a sign of
superiority of your method.
0
2/7/2008 10:15:53 PM
On Feb 7, 8:35 pm, Victor Porton <por...@narod.ru> wrote:
> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?
>
> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.
>
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?I

If your true intention was not to start some serious flaming  (which
is inevitable cross-posting to comp.object and comp.database), then
I'd have a look at Date and Darwen's Third Manifesto, which describes
an Object Relational Model. However, in many waysOOP (however that is
defined) and Database Theory are diametrically opposed. This is hardly
suprising given that Relational Databases replaced the Network
Databases which have so much in common with OO.

In the end OOA is conceptual modeling, and you'll get away with
translating that directly to a logical model as long as your data
isn't going to be shared by people or applications that use different
conceptual models (and you can put up with the clunkiness of
navigational querying of course). If you do want to (or more likely
have to) meld OO and RM together, then google "object relational
mapping" software... but rather you than me ;)
0
jog (83)
2/7/2008 10:33:38 PM
On Feb 7, 1:01=A0pm, topmind <topm...@technologist.com> wrote:
> Schema inheritance -- Most relational databases do not support schema
> inheritance. Although such a feature could be added in theory to
> reduce the conflict with OOP, relational proponents are less likely to
> believe in the utility of hierarchical taxonomies and sub-typing
> because they tend to view set-based taxonomies or classification
> systems as more powerful and flexible than trees. OO advocates point
> out that inheritance/subtyping models need not be limited to trees
> (though this is a limitation in many popular OO languages such as
> Java), but non-tree OO solutions are seen as more difficult to
> formulate than set-based variation-on-a-theme management techniques
> preferred by relational. At the least, they differ from techniques
> commonly used in relational algebra.

This snippet highlights a major problem with wikipedia articles which
often combine two diametrically opposed views melded together. It
would be much more educational to analyse both views separately.

First, the reference to a concrete programming language (such as Java)
is amusing. It looks as silly as if relational proponent was searched
for SQL artifacts in order to get some insight into relational theory.

Generally, taxonomies are brittle. In the earlier example of concepts
matrix one have to decide whether to use an atribute such as "Has
Tail" or negate it into "No Tail" -- the resulting taxonomies are
quite different. The "No Tail" is considered more progressive, because
with the "Has Tail" attribute Gorilla and Human no longer fit at the
top of the evolutionary ladder!
0
2/7/2008 10:34:41 PM
On Feb 7, 1:00=A0pm, Tegiri Nenashi <TegiriNena...@gmail.com> wrote:
> On Feb 7, 12:35 pm, Victor Porton <por...@narod.ru> wrote:
>
> > I know both object oriented programming and DB (SQL). But it seems
> > that these are incompatible.
>
> I suggest that OO ideas are too naive to continue influence
> programming. Formal Concept Analysis (FCA) is much more theoretically
> sound method how to organize things into taxonomies.
>
> Here is an example -- a hierarchy of living things, restricted to the
> set {Lamprey, Trout, Lungfish, ..., Human}. FCA starts with feature
> matrix like this:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Jaws Limbs =A0 Hair =A0 =A0Lungs =
=A0 Tail =A0 =A0Shell
> Lamprey 0 =A0 =A0 =A0 0 =A0 =A0 =A0 0 =A0 =A0 =A0 0 =A0 =A0 =A0 1 =A0 =A0 =
=A0 0
> Trout =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 0 =A0 =A0 =A0 0 =A0 =A0 =A0 0 =A0 =
=A0 =A0 1 =A0 =A0 =A0 0
> Lungfish =A0 =A0 =A0 =A01 =A0 =A0 =A0 0 =A0 =A0 =A0 0 =A0 =A0 =A0 1 =A0 =
=A0 =A0 1 =A0 =A0 =A0 0
> Turtle =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 1 =A0 =A0 =A0 0 =A0 =A0 =A0 1 =A0 =
=A0 =A0 1 =A0 =A0 =A0 1
> Cat =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 1 =A0 =A0 =A0 1 =A0 =A0 =A0 1 =
=A0 =A0 =A0 1 =A0 =A0 =A0 0
> Gorilla =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 1 =A0 =A0 =A0 1 =A0 =A0 =A0 1 =A0 =
=A0 =A0 0 =A0 =A0 =A0 0
> Human =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 1 =A0 =A0 =A0 1 =A0 =A0 =A0 1 =A0 =
=A0 =A0 0 =A0 =A0 =A0 0
>
> Then, the objects and the attributes (aka concepts) organize
> themselves into a lattice like this
>
> Lamprey -> Trout -> Lungfish -> Cat -> Gorilla
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 ---> Huma=
n
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0----> Turtle
>
> which is more powerful concept than OO hierarchy of classes. Each FCA
> concept is essentially a limited form of a relation.

It should be pointed out that biological taxonomies are often not an
appropriate test of variations-on-a-theme management techniques for
many domains. This is because biology is based on descent-based
evolution; while other domain items, such as Apple Widgets are not,
and are composed of a buffet-like mix-and-match of features based on
S. Job's whims. He can make a Tiger-Crab if he wants, but evolution
won't (unless Monsanto goes mad).

>
> There are some reasons why FCA methods never enjoyed a success
> comparable to OO and Relational Model. They are simply more
> restrictive sets of relations which obey distributive property, why
> relations in general don't.

-T-
0
topmind (2124)
2/7/2008 10:42:22 PM
On Feb 7, 2:04=A0pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:
> > I suggest that OO ideas are too naive to continue influence
> > programming. Formal Concept Analysis (FCA) is much more theoretically
> > sound method how to organize things into taxonomies.
>
> Sorry, but the idea of subsets used in place of subtypes far surpasses in
> naiveness anything one could charge "naive OO" with.

Oh goody, another Types-Vs.-Sets fight is brewing. Get the popcorn...

>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

-T-
0
topmind (2124)
2/7/2008 10:43:44 PM
On Feb 7, 9:35 pm, Victor Porton <por...@narod.ru> wrote:
> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?
>
> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.
>
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?

Whether OO and a relational DB is incompatible or not, depends on how
you use OO. In the relational camp, objects and relations are
considered being orthogonal features. A relation (table), is a
relation between values (objects). In fact, classes are one way of
defining types (domains) needed in the relational model. For example,
the datetime type or a currency type may be defined using classes.

The problem occurs when one try to use classes/objects as data
structures. The relational model only allow relations as data
structures. If you create classes like "employee", "customer", you
will soon encounter  big problems. But classes like "SSN", "telephone
no", "zip code" will fit perfect together with the relational model.

One other important thing is that objects used in relations must be
immutable. Objects are values. If you start using mutable (data)
objects in multi-user environments, you will soon encounter a lot of
concurrency issues, that the RDBMS is supposed to do for you instead.

Objects and classes can obviously be used successfully for other
things  not related to data management. For example, classes/objects
are suitable for buildning a GUI.

//frebe
0
frebe73 (444)
2/8/2008 7:58:11 AM
On Thu, 7 Feb 2008 14:15:53 -0800 (PST), Tegiri Nenashi wrote:

> On Feb 7, 2:04�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:
>>> I suggest that OO ideas are too naive to continue influence
>>> programming. Formal Concept Analysis (FCA) is much more theoretically
>>> sound method how to organize things into taxonomies.
>>
>> Sorry, but the idea of subsets used in place of subtypes far surpasses in
>> naiveness anything one could charge "naive OO" with.
> 
> Are you referring to apparent object propelleheads unability to even
> coherently define what the object/type is?

At least they try to face the problem. Which is not about clustering some
arbitrary set of attributes.

> Then, the ability to
> operate a concept without defining it is certainly a sign of
> superiority of your method.

Certainly a notion of type can be given with all necessary rigorousness.
The only question is how useful a particular definition is in the context
of software design (correctness, maintenance, complexity, non-functional
constraints).

P.S. Plucked chicken is not yet a man (remembering a two thousand year old
anecdote).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/8/2008 8:50:17 AM
On Feb 8, 8:50 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 7 Feb 2008 14:15:53 -0800 (PST), Tegiri Nenashi wrote:
> > On Feb 7, 2:04 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:
> >>> I suggest that OO ideas are too naive to continue influence
> >>> programming. Formal Concept Analysis (FCA) is much more theoretically
> >>> sound method how to organize things into taxonomies.
>
> >> Sorry, but the idea of subsets used in place of subtypes far surpasses in
> >> naiveness anything one could charge "naive OO" with.
>
> > Are you referring to apparent object propelleheads unability to even
> > coherently define what the object/type is?
>
> At least they try to face the problem.

Although you only have to face the problem of definining what an
"object" is if you've conjured that problem in the first place.

> Which is not about clustering some arbitrary set of attributes.

What is it about then? Genuinely interested.

>
> > Then, the ability to
> > operate a concept without defining it is certainly a sign of
> > superiority of your method.
>
> Certainly a notion of type can be given with all necessary rigorousness.
> The only question is how useful a particular definition is in the context
> of software design (correctness, maintenance, complexity, non-functional
> constraints).
>
> P.S. Plucked chicken is not yet a man (remembering a two thousand year old
> anecdote).
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

0
jog (83)
2/8/2008 9:44:46 AM
On Fri, 8 Feb 2008 01:44:46 -0800 (PST), JOG wrote:

> On Feb 8, 8:50 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 7 Feb 2008 14:15:53 -0800 (PST), Tegiri Nenashi wrote:
>>> On Feb 7, 2:04 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:
>>>>> I suggest that OO ideas are too naive to continue influence
>>>>> programming. Formal Concept Analysis (FCA) is much more theoretically
>>>>> sound method how to organize things into taxonomies.
>>
>>>> Sorry, but the idea of subsets used in place of subtypes far surpasses in
>>>> naiveness anything one could charge "naive OO" with.
>>
>>> Are you referring to apparent object propelleheads unability to even
>>> coherently define what the object/type is?
>>
>> At least they try to face the problem.
> 
> Although you only have to face the problem of definining what an
> "object" is if you've conjured that problem in the first place.

Much confusion arise from mixing domain and solution spaces when talking
about "objects." Otherwise I see nothing impossible neither in defining
"object" as a language term nor in doing so in the corresponding problem
domain. One should just remember that they are different beasts.

>> Which is not about clustering some arbitrary set of attributes.
> 
> What is it about then? Genuinely interested.

It is about software design. Assuming that to design software is to cluster
a set of all possible programs into the categories "does-the-thing",
"does-other-thing" is funny, at least.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/8/2008 11:29:52 AM
Victor Porton <porton@narod.ru> wrote:

> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?

You specifically mention SQL, what language are you trying to "meddle" 
SQL to? I expect, in any case, that it isn't going to be easy. It 
usually isn't easy to "meddle" two languages together. (I'm assuming 
here that "meddle" means the same thing as "meld".)

> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.
> 
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?

I don't know much about "DB development" myself, but Robert Martin's 
"Designing Object Oriented C++ Applications using the Booch Method" has 
a section about mixing DB and OOP. He basically says that you need to 
use down-casts to mix them. (Which implies that they don't mix well.)
0
daniel_t (1960)
2/8/2008 12:29:00 PM
Victor Porton <porton@narod.ru> writes:
> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle
> them together?
>
> Being strong in both OOP and DB development, I am yet weak in
> writing object oriented programs which use DB.

     You're experiencing the well known "object relational impedance
mismatch."  There are two basic issues underlying this problem.
First, the relational approach focuses on data while the OO approach
focuses on behavior.  Of course you can implement some behavior in an
RDBMS and manage state in a OO language, but the design drivers are
different.

     Second, and partly related to the first issue, when used in the
same software system the two components change for different reasons.
A relational schema is often used by multiple different applications
and must therefore provide reasonable performance for a broad range of
data creation, read, update, and deletion patterns.  Even when the
relational schema is embedded in a single application, state changes
for different reasons and as different rates from behavior.

     The object model, on the other hand, is optimized to address
non-functional requirements (NFRs) related to the problem domain.  The
supported behaviors may change or be extended without needing to
change state at all.

> Maybe somebody may suggest me some article about mixing together DB
> and OOP?

     Because of the impedance mismatch, most OO systems use some form
of object-relational mapping.  A quick Google turns up this as a
reasonable starting point for your research:

          http://www.agiledata.org/essays/mappingObjects.html

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/8/2008 1:10:11 PM
"Victor Porton" <porton@narod.ru> wrote in message
news:89b92dec-b710-4c24-9c8e-731de01fb49a@u10g2000prn.googlegroups.com...
> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?
>
> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.
>
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?

First off, I think it's reall the mixing of OO and RDM that's of interest,
rather than the mixing of OO and DB.


Better minds than mine have attempted to deal with the impedance mismatch
between OO and RDM.  In general, they have been disappointed by their own
results.

I suspect that most of them have gone about it in the wrong way.  Most of
them have tried to project an object world onto a system of relations.  What
they end up with is presistent data that captures the state of each object,
and its membership in a class.  The behavior of objects that belong to any
class is generally defined outside of any coherent data model  (even if it's
stored in a blob in a database).

I think it might be interesting to explore the whole concept backwards:
start with the idea that a table is just a specific class of object,  and a
persistent table is just a specific class of persistent object.  Then come
up with two things:  how to store persistent objects and retrieve them when
necessary without regard for any data model; and  how to get tables and
application objects to collaborate on common objectives.

This doesn't sound easy to me, at all.  But it could be promising,  provided
there is real value in OO.  I don't know OO well enough to have a considered
opinion on that score.



0
cressey73 (124)
2/8/2008 1:48:50 PM
David Cressey wrote:

> "Victor Porton" <porton@narod.ru> wrote in message
> news:89b92dec-b710-4c24-9c8e-731de01fb49a@u10g2000prn.googlegroups.com...
> 
>>I know both object oriented programming and DB (SQL). But it seems
>>that these are incompatible. Or may somebody advice how to meddle them
>>together?
>>
>>Being strong in both OOP and DB development, I am yet weak in writing
>>object oriented programs which use DB.
>>
>>Maybe somebody may suggest me some article about mixing together DB
>>and OOP?
> 
> First off, I think it's reall the mixing of OO and RDM that's of interest,
> rather than the mixing of OO and DB.
> 
> Better minds than mine have attempted to deal with the impedance mismatch
> between OO and RDM.  In general, they have been disappointed by their own
> results.

Nuh uh--Not me! I was not disappointed. Raising the programming language 
from the low OO level to the higher RM level works great!


> I suspect that most of them have gone about it in the wrong way.  Most of
> them have tried to project an object world onto a system of relations.  What
> they end up with is presistent data that captures the state of each object,
> and its membership in a class.  The behavior of objects that belong to any
> class is generally defined outside of any coherent data model  (even if it's
> stored in a blob in a database).
> 
> I think it might be interesting to explore the whole concept backwards:
> start with the idea that a table is just a specific class of object,  

A great blunder.


and a
> persistent table is just a specific class of persistent object.  Then come
> up with two things:  how to store persistent objects and retrieve them when
> necessary without regard for any data model; and  how to get tables and
> application objects to collaborate on common objectives.
> 
> This doesn't sound easy to me, at all.  But it could be promising,  provided
> there is real value in OO.  I don't know OO well enough to have a considered
> opinion on that score.

Have you read _The Third Manifesto_ ? D&D put a lot of thought into what 
parts of OO have any real value.
0
bbadour (434)
2/8/2008 1:57:09 PM
"frebe" <frebe73@gmail.com> wrote in message
news:081cbab9-89f6-4459-9e5c-3346e6d96e99@s37g2000prg.googlegroups.com...

> The problem occurs when one try to use classes/objects as data
> structures. The relational model only allow relations as data
> structures. If you create classes like "employee", "customer", you
> will soon encounter  big problems. But classes like "SSN", "telephone
> no", "zip code" will fit perfect together with the relational model.

Alan Kay once said "I don't like data structures".  This was in the context
of some lecture on virtual reality.  If you'll think about the consequences
of that opinion for a little while,  you'll be devastated.



0
cressey73 (124)
2/8/2008 2:38:57 PM
On Fri, 08 Feb 2008 13:48:50 GMT, David Cressey wrote:

> I think it might be interesting to explore the whole concept backwards:
> start with the idea that a table is just a specific class of object,  and a
> persistent table is just a specific class of persistent object. 

It so obvious that I wonder how one could even consider it "interesting,"
rather than mandatory. (BTW, persistence is an orthogonal issue to typed
relations. As well as concurrency is.)

The problem is that contemporary type systems in OOPL aren't very good to
handle this.

> This doesn't sound easy to me, at all.  But it could be promising,  provided
> there is real value in OO.  I don't know OO well enough to have a considered
> opinion on that score.

Look, if typed systems had no sense, then why would anybody have table
cells typed? Once you accept usefulness of the latter, you should also
apply types to the former.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/8/2008 3:57:50 PM
Dmitry A. Kazakov wrote:

> On Fri, 08 Feb 2008 13:48:50 GMT, David Cressey wrote:

>>I think it might be interesting to explore the whole concept backwards:
>>start with the idea that a table is just a specific class of object

In an RDB, a "table" T is more than that.
It also represents the extent set (all instances) of T.

Then we have issues coming from the semantics of relational algebra.

For example:

In an object type system, what would the semantics of "joins" be ??

Should it have the same semantics as the relational model (a new type
tuple etc) ?? Or something else ??

If so, how would this new type be implemented/realised in the underlying
system (closures etc) when the join is done on two different object
instances ??


 >Then come up with two things:  how to store persistent objects and
 >retrieve them when
 >necessary without regard for any data model; and  how to get tables and
 >application objects to collaborate on common objectives.

For me, the big problem has always been the following :

SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)

s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;

In the OO world, the problem is that for each instance of SomeType held
in Somewhere, the *implementation* of the property 'x' could be merely
an actual data value, or a serious computation process. That is the ADT/OO
way.

If the implementation is a computation process, there is also no guarantee
that each instance in Somewhere actually use the *same* implementation.

So all the optimisation etc that is achievable when you constrain x/y/z to
be raw data values only, is lost when you can no longer presume such
constraints.

It is because of this that I believe that the only paradigm that is capable
of providing the true engine for a relational info base that caters for
both OO and current RDBMS, is Functional programming (data values and
computation entities - functions - are treated the same, techniques such as
lazy evaluation, "copy on write" behaviour etc) .

With imperative prog langs (C, C++ , Java etc) , I can never see the
"mismatch impedence" ever being overcome. :-(


Regards,
Steven Perryman
0
S
2/8/2008 4:44:53 PM
Many years ago, the ANSI X3H2 Committee had a meeting in Rapid City,
SD where Bjarne Stroustrup gave a talk on C++ and OO programming
(overhead slides, not Powerpoints!)

We asked about putting OO into SQL3 (the internal name of the working
draft Standard at that time).  He said that Bells Labs had tried four
ways to do this and they were all failures.  Bells Labs was the
smarter people on Earth at that time. He summary was that OO was good
for programming and bad for data.
0
jcelko212 (1247)
2/8/2008 5:05:59 PM
On 8 feb, 18:05, -CELKO- <jcelko...@earthlink.net> wrote:
> Many years ago, the ANSI X3H2 Committee had a meeting in Rapid City,
> SD where Bjarne Stroustrup gave a talk on C++ and OO programming
> (overhead slides, not Powerpoints!)
>
> We asked about putting OO into SQL3 (the internal name of the working
> draft Standard at that time). =A0He said that Bells Labs had tried four
> ways to do this and they were all failures. =A0Bells Labs was the
> smarter people on Earth at that time. He summary was that OO was good
> for programming and bad for data.

They asked Bjarne Stroustrup? Why??

  "I invented the term Object-Oriented, and I can tell you I did not
have C++ in mind."
  - Alan Kay

-- Jan Hidders
0
hidders (21)
2/8/2008 5:17:54 PM
On 8 feb, 15:38, "David Cressey" <cresse...@verizon.net> wrote:
> "frebe" <freb...@gmail.com> wrote in message
>
> news:081cbab9-89f6-4459-9e5c-3346e6d96e99@s37g2000prg.googlegroups.com...
>
> > The problem occurs when one try to use classes/objects as data
> > structures. The relational model only allow relations as data
> > structures. If you create classes like "employee", "customer", you
> > will soon encounter =A0big problems. But classes like "SSN", "telephone
> > no", "zip code" will fit perfect together with the relational model.
>
> Alan Kay once said "I don't like data structures". =A0This was in the cont=
ext
> of some lecture on virtual reality. =A0If you'll think about the consequen=
ces
> of that opinion for a little while, =A0you'll be devastated.

For some reason it doesn't have that effect on me. Without more
context it's a bit hard to say what he exactly meant, and I can think
of a few interpretations that range from the quite silly to the really
brilliant.

-- Jan Hidders
0
hidders (21)
2/8/2008 5:37:13 PM
On Fri, 08 Feb 2008 16:44:53 +0000, S Perryman wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Fri, 08 Feb 2008 13:48:50 GMT, David Cressey wrote:
> 
>>>I think it might be interesting to explore the whole concept backwards:
>>>start with the idea that a table is just a specific class of object
> 
> In an RDB, a "table" T is more than that.
> It also represents the extent set (all instances) of T.
> 
> Then we have issues coming from the semantics of relational algebra.
> 
> For example:
> 
> In an object type system, what would the semantics of "joins" be ??
> 
> Should it have the same semantics as the relational model (a new type
> tuple etc) ?? Or something else ??
> 
> If so, how would this new type be implemented/realised in the underlying
> system (closures etc) when the join is done on two different object
> instances ??

The same problem exists with any algebra less flat than numeric fields.
What is the type of Matrix x Matrix? What is the type of Velocity /
Duration? etc. The problem is rather fundamental and appears when we deal
with operations built on tuples of types.

The point is though that there is nothing in RA to deserve a special
treatment. That is actually is not an option, because we just cannot
provide a tailored solution for each and ever algebra.

>  >Then come up with two things:  how to store persistent objects and
>  >retrieve them when
>  >necessary without regard for any data model; and  how to get tables and
>  >application objects to collaborate on common objectives.
> 
> For me, the big problem has always been the following :
> 
> SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
> 
> s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
> 
> In the OO world, the problem is that for each instance of SomeType held
> in Somewhere, the *implementation* of the property 'x' could be merely
> an actual data value, or a serious computation process. That is the ADT/OO
> way.
> 
> If the implementation is a computation process, there is also no guarantee
> that each instance in Somewhere actually use the *same* implementation.
> 
> So all the optimisation etc that is achievable when you constrain x/y/z to
> be raw data values only, is lost when you can no longer presume such
> constraints.

I see it different. First the above should be decomposed into primitive
operations over the types involved. There is at least the type of the table
and one of the cell. If SELECT were doubly dispatching, then one could
certainly provide different implementations for different combinations of
types.

To me a bigger problem is that RA is "computationally instable" in the
sense that a minor variations of same constructs may have massive effects
on resources consumptions, i.e. distributed overhead. OO tries to localize
effects by decoupling and encapsulation.

> It is because of this that I believe that the only paradigm that is capable
> of providing the true engine for a relational info base that caters for
> both OO and current RDBMS, is Functional programming (data values and
> computation entities - functions - are treated the same, techniques such as
> lazy evaluation, "copy on write" behaviour etc) .

Doesn't it just postpone the problem until run-time?

> With imperative prog langs (C, C++ , Java etc) , I can never see the
> "mismatch impedence" ever being overcome. :-(

That would be unfortunate, because I see a general problem with declarative
approaches as they try to sort things out per means of "magic." Without
magical devices at hand, we should design them by themselves. How?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/8/2008 7:32:03 PM
On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> The same problem exists with any algebra less flat than numeric fields.
> What is the type of Matrix x Matrix?

Speaking of matrices, what do you possibly achieve by bundling
together the multiply(Matrix,Matrix) function together with the Matrix
data structure (other than loosing the symmetry: consider
matrix1.multiply(matrix2) method call how ugly is that)? Perhaps you
want a convenient listing of all the functions that have Matrix as a
first argument? Such a query shouldn't be a problem in any of
contemporary IDEs which *are* databases storing the source code. Or
you imply that you can define Matrix2x2 and subtype it into
GeneralMatrix? How silly is that (given that it is just simpler to
write general implementation). Or maybe one is advised to subclass the
other way?

If you serious about working with matrices (or any math) in your
application, then you design a mini-language which looks as Maple,
Matlab, or Mathematica.

> The point is though that there is nothing in RA to deserve a special
> treatment. That is actually is not an option, because we just cannot
> provide a tailored solution for each and ever algebra.

You mean you don't want to, or you are not qualified to?

> > For me, the big problem has always been the following :
>
> > SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
>
> > s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
>
> > In the OO world, the problem is that for each instance of SomeType held
> > in Somewhere, the *implementation* of the property 'x' could be merely
> > an actual data value, or a serious computation process. That is the ADT/OO
> > way.

If x is computed, then why don't you introduce a function that
computes it? In relational world a function call is a join. If this
function is not known at runtime, then what logic is involved in
selecting it? Can't the problem solved by dynamically constructing
this query?

> I see it different. First the above should be decomposed into primitive
> operations over the types involved. There is at least the type of the table
> and one of the cell. If SELECT were doubly dispatching, then one could
> certainly provide different implementations for different combinations of
> types.

What is SELECT? The whole query? The projection part? You OO guys
perfected the art speaking gibberish.

> To me a bigger problem is that RA is "computationally instable" in the
> sense that a minor variations of same constructs may have massive effects
> on resources consumptions, i.e. distributed overhead. OO tries to localize
> effects by decoupling and encapsulation.

You mean optimization? This is true, query optimization in relational
world is far more advanced than the one in the procedural programming
(which includes OO), and therefore it has more challenging problems.

> > It is because of this that I believe that the only paradigm that is capable
> > of providing the true engine for a relational info base that caters for
> > both OO and current RDBMS, is Functional programming (data values and
> > computation entities - functions - are treated the same, techniques such as
> > lazy evaluation, "copy on write" behaviour etc) .

Function is just a relation with functional dependency. It works
pretty much like an index. When a function is called from a query, it
is essentially a join, although there is no ambiguity which order this
join is evaluated. Therefore, in principle, FP is too weak to embrace
relational. It is more likely to happen the other way.

Relational programing has its weaknesses, but they are not what OO
propellerheads think. One missing part in the relational is formal
grammars and languages. The underlying theory of grammars and language
theory is Kleene algebra which is incompatible with RA. Witness how
regular expressions are integrated into SQL, as if there is no common
operation in relational algebra and algebra of strings...
0
2/8/2008 9:18:05 PM
Responding to Porton...

> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?

Superficially they are not. An OO Class Model and a Data Model (nee 
Entity Relationship Diagram) use essentially the same notation and both 
are normalized using the same NF criteria.

The difference lies in the way the models are constructed and the way 
that elements of the entire model (the Class Diagram is only one 
component of an OOA/D model and cannot be separated from the other 
components) play together. While the construction paradigms are not 
directly incompatible, they will typically lead to different models 
because different things are abstracted (problem space subject matters 
vs data) and there are different goals in creating the model.

One manifestation of that is that the OO model will be highly tailored 
to the unique rules and policies needed to solve the problem in hand. In 
contrast, the goal of a Data Model is to represent data in a generic, 
usage-independent manner.

Thus there is an inherent incompatibility but it lies in the goals and 
construction methodologies rather than the notation syntax or element 
semantics.

Generally speaking the OO paradigm is overkill for pure data processing 
(i.e., classic CRUD/USER processing). In addition the RAD IDEs have 
largely automated much of what one would construct from scratch in an OO 
context. In doing so, though, the RAD IDEs have limited themselves to 
situations where 2D layered models apply and one can provide 1:1 mapping 
between the UI and the DB (i.e., form-based UIs that map conveniently to 
stored tables). For that sort of pure data processing the RAD paradigm 
is much better suited.

OTOH, when one has to solve a large problem using complex business rules 
and policies in a manner that is unique to the problem, one begins to 
realize the benefits of the OO paradigm -- particularly when the 
requirements are volatile over time. But for those sorts of 
applications, both the UI and the persistence mechanisms are of 
relatively little importance. Thus the problem solution doesn't care if 
one communicates with the user via a GUI, a web browser, or smoke 
signals. Nor does the problem solution care if the data store is an RDB, 
an OODB, flat files, or clay tablets.

So in OO applications, the UI and persistence access tend to be isolated 
and encapsulated as low level service subsystems. The subsystem 
interface then allows the mechanisms to be substituted transparently 
without touching the problem solution.

A corollary is that because such subsystems are narrowly defined around 
a particular subject matter like an RDB, one can abstract the invariants 
of the paradigm. Thus for an RDB access subsystem one abstracts classes 
like Schema, Table, Tuple, and Query rather than objects like Customer, 
Order, and Shipment. That, in turn, allows one to express detailed 
differences in terms of external configuration data. (In an RDB, the 
schema itself becomes an identity mapping mechanism; one just needs to 
link interface messages to schema names.) So typically one only needs to 
design and implement a UI or DB paradigm once in an OO fashion; one can 
then reuse the subsystem across different applications by simply 
providing an appropriate configuration file and an interface (think: GoF 
Facade pattern).

> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.

If you are solving CRUD/USER problems my advice would be to forget about 
using OO and employ traditional RAD techniques. If you are solving 
non-CRUD/USER problems, then I think all you have to do is isolate, 
encapsulate, and abstract the invariants of the DB paradigm.

> 
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?

You might check out Fig. 17.2 in "Executable UML" by Mellor and Balcer. 
The example is about abstracting a web browser UI but it is a good 
example of abstracting the paradigm invariants. Exactly the same model 
could be used for any application that talks to a web browser; all that 
changes is what instances are initialized and what their attribute 
values are -- all provided by configuration data. The extrapolation to a 
model with objects like Table and Query should be fairly obvious.


-- 
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development".  Email
info@pathfindermda.com for your copy.
Pathfinder is hiring: 
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
0
hsl (257)
2/8/2008 9:46:34 PM
On Fri, 8 Feb 2008 13:18:05 -0800 (PST), Tegiri Nenashi wrote:

> On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:

>> The same problem exists with any algebra less flat than numeric fields.
>> What is the type of Matrix x Matrix?
> 
> Speaking of matrices, what do you possibly achieve by bundling
> together the multiply(Matrix,Matrix) function together with the Matrix
> data structure (other than loosing the symmetry: consider
> matrix1.multiply(matrix2) method call how ugly is that)?

Egh, prefix notation is just a notation, utterly misleading in most cases,
BTW. Semantically matrix multiplication deals with a triplet:

   Multiply : Matrix x Matrix -> Matrix

So if Multiply is to be bound to an object then that has to be a tuple
(Matrix, Matrix, Matrix).

(If you think that OO = prefix notation, then it is not the OO I meant.)

> If you serious about working with matrices (or any math) in your
> application, then you design a mini-language which looks as Maple,
> Matlab, or Mathematica.

Really? And what if I am serious about working with something else too?
What about "serious" working with matrices *and* data bases? So next time
it should be me whining here about impedance between OO, DB and now a fancy
matrix language? What a brilliant future waits for us...

>> The point is though that there is nothing in RA to deserve a special
>> treatment. That is actually is not an option, because we just cannot
>> provide a tailored solution for each and ever algebra.
> 
> You mean you don't want to, or you are not qualified to?

Neither. I do admire compiler construction, but customers became thrifty.
Silly they don't want to pay for developing a new programming language for
each other new project!

>> To me a bigger problem is that RA is "computationally instable" in the
>> sense that a minor variations of same constructs may have massive effects
>> on resources consumptions, i.e. distributed overhead. OO tries to localize
>> effects by decoupling and encapsulation.
> 
> You mean optimization? This is true, query optimization in relational
> world is far more advanced than the one in the procedural programming
> (which includes OO), and therefore it has more challenging problems.

If solution is itself a problem... No, I didn't mean optimization. What
makes you believe in optimization? How reliable your belief is? Let you
look at a program, can you predict if it meets time and space constraints?
Before optimization? After optimization?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/8/2008 10:15:40 PM
H. S. Lahman wrote:

> Responding to Porton...
> 
>> I know both object oriented programming and DB (SQL). But it seems
>> that these are incompatible. Or may somebody advice how to meddle them
>> together?
> 
> Superficially they are 

[snipped lengthy bs complete with not 1 but 8 paradigms]

> fairly obvious.

Seldom in the history of mankind have so many words said so little.

(Lots of greek and latin roots always bode ill.)
0
bbadour (434)
2/8/2008 10:58:46 PM
Newsgroups: comp.object, comp.databases.theory

I cringe every time I see a thread crossposted to these two groups. Good 
seldomn comes of it. 


0
2/8/2008 11:16:23 PM
On Feb 8, 7:32 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> [snip]
> That would be unfortunate, because I see a general problem with declarative
> approaches as they try to sort things out per means of "magic." Without
> magical devices at hand, we should design them by themselves. How?

I'm wondering if that made more sense in the original russian?

>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

0
jog (83)
2/9/2008 1:57:59 AM
Mixing OO and DB:
In practise we do it all the time.
In theory it can't work.

Leslie Sanford wrote:

> Newsgroups: comp.object, comp.databases.theory
> I cringe every time I see a thread crossposted to these two groups.
> Good seldomn comes of it. 

Do you have an explanation for that?

Within one group, the easy way is: the other guys are so stupid.
Let's skip 'the other guys are so stupid' in this sub-thread.
I re-included cdt.

Let's cross this divide, and behave as if it is a real border.
This means you can't carry all of your preconceptions, and you will 
have to adapt your language.

Any ideas except 'the other guys are so stupid'?


--
What you see depends on where you stand.



0
mAsterdam (155)
2/9/2008 10:21:08 AM
On Sat, 09 Feb 2008 11:21:08 +0100, mAsterdam wrote:

> Leslie Sanford wrote:
> 
>> Newsgroups: comp.object, comp.databases.theory
>> I cringe every time I see a thread crossposted to these two groups.
>> Good seldomn comes of it. 
> 
> Do you have an explanation for that?
> 
> Any ideas except 'the other guys are so stupid'?

Market. Both OO and RDB are technologies with market products on sale.
Between us we can admit shortcomings and problems, but what if customers
would hear that? I don't accuse anybody of being hypocritical. Just once
anybody gets accustomed to doublespeak it becomes difficult for him to
switch back. It is like being confronted by a salesman in a shop. Relax, we
aren't to buy anything, just looking around...

P.S. I don't want to appear politically correct. IMO comp.object is less
aggressive than comp.databases.theory. People like topmind and frebe aren't
excommunicated regardless their propaganda. Does comp.databases.theory have
such?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/9/2008 11:01:56 AM
>=A0Even when the
> relational schema is embedded in a single application, state changes
> for different reasons and as different rates from behavior.

Would you mind giving examples of such changes? (You can skip the
"denormalisation for performance" example.)

> =A0 =A0 =A0The object model, on the other hand, is optimized to address
> non-functional requirements (NFRs) related to the problem domain.

Doesn't that indicate that OO is pretty low-level, and that the
coupling between the logical model and the phisycal model is high?
Wouldn't it be better if we could separate the logical model handling
functional requirements, and the physical model handling non-
functional requirements?

> > Maybe somebody may suggest me some article about mixing together DB
> > and OOP?
>
> =A0 =A0 =A0Because of the impedance mismatch, most OO systems use some for=
m
> of object-relational mapping. =A0

O/R mapping is not the best way of mixing together DB and OOP.

//frebe
0
frebe73 (444)
2/9/2008 11:26:00 AM
Dmitry A. Kazakov wrote:
> mAsterdam wrote:
> 
>> Leslie Sanford wrote:
>>
>>> Newsgroups: comp.object, comp.databases.theory
>>> I cringe every time I see a thread crossposted to these two groups.
>>> Good seldomn comes of it. 
>> Do you have an explanation for that?
>>
>> Any ideas except 'the other guys are so stupid'?
> 
> Market. Both OO and RDB are technologies with market products on sale.

Let's see if I can play with this using a metaphore.

So are, say, ships and engines (technologies with market products on
sale). Both have their own laws.
Designing a motorized boat requires a shared understanding
of some of them. There is a market for sailing boats,
there is a market for engines wchich can be used in other things than 
ships. In this thread, we /are/ mixing. Shouldn't there be a market 
for motorizing boats and for engines fit for use on a ship?


> Between us we can admit shortcomings and problems, but what if customers
> would hear that? I don't accuse anybody of being hypocritical. Just once
> anybody gets accustomed to doublespeak it becomes difficult for him to
> switch back. It is like being confronted by a salesman in a shop. Relax, we
> aren't to buy anything, just looking around...
> 
> P.S. I don't want to appear politically correct. 
> IMO comp.object is less
> aggressive than comp.databases.theory. People like topmind and frebe aren't
> excommunicated regardless their propaganda. Does comp.databases.theory have
> such?

This is a c.o politically correct
'the other guys are so stupid' question.


--
What you see depends on where you stand.
0
mAsterdam (155)
2/9/2008 12:32:21 PM
"mAsterdam" <mAsterdam@vrijdag.org> wrote in message
news:47ad7dc5$0$85790$e4fe514c@news.xs4all.nl...

> Any ideas except 'the other guys are so stupid'?

My reaction is biased towards databases.  That's where I'm coming from.  No
apologies for that.

I'd like to suggest that the origins of the database appraoch and the
origins of the object oriented approach are very different.  The database
approach started from an enterprise wide database and has scaled its way
down to tiny (conceptually) databases embedded in single applications.  The
object oriented approach started with simulations and scaled its way up to
the problems that are being worked on now,  including enterprise wide
solutions.

The fundamental problem to be addressed in database work is shareability.
If database data is not shareable, it's less valuable.  Codd's work on
applying the relational model of data to the organization of databases for
large scale sharing of large scale data is fundamentally aimed at promoting
uniformity and thereby shareability without unduly limiting flexibility at
the low end.  In the trade-off between  uniformity and flexibility, the
relational model pushed the envelope so far out that all of the other
database contenders from the 1970s have been almost pushed off the map.  I'm
thinking of the graph based DBMS products that dominated the market in circa
1978.

While theoretical advances such as those discussed in c.d.t. are important
in their own right, the fundamental market presence of the relational model
in practical work has settled on the SQL model of data.  A lot of us mere
practicioners treat the SQL model and the relational model as variations on
the same theme.  In terms of the internals of data storage,  data blocks
that can contain table rows or index nodes make up the bulk of the data
whose management  is transparent to the users of the DBMS.

The fundamental problem in simulations, as I see it,  is autonomy.  If each
unit in a simulation is not autonomous, the simulation will be constrained
at the system level to behave in ways that do not mimic the systems being
simulated.  Objects are largely autonomous,  and that is their great
utility.  Objects are more autonomous than functions and procedures from the
great programming languages of the 1970s because objects carry state.  That
is why OOP has displaced structured programming to a large extent.

In order for objects to collaborate they have to exchange signals  (data).
In order to usefully exchange data,  there has to be a common convention
regarding both the form and the content of the messages passed between
objects.  Most of the OO stuff I've seen (which isn't very much)
concentrate on bilateral contracts between pairs of objects as to what the
form and content  (meaning?) of exchanged messages will be.

Most of the best database work concentrates on universal contracts (although
the word "contracted" isn't widely used) governing the entire body of data
stored in a database,  and a vast multitude of transactions that collaborate
(going forward in time) that adhere to the single contract or some subset of
it.

This looks overly contraining to the programmer accustomed to object
oriented thinking.

The bilateral contracts that tend to govern data exchange in object worlds
look chaotic to someone such as myself,  schooled in database work.

This is the best I can do to describe the differences in non-pejorative
terms.


0
cressey73 (124)
2/9/2008 2:34:33 PM
On Sat, 09 Feb 2008 13:32:21 +0100, mAsterdam wrote:

> Dmitry A. Kazakov wrote:
>> mAsterdam wrote:
>> 
>>> Leslie Sanford wrote:
>>>
>>>> Newsgroups: comp.object, comp.databases.theory
>>>> I cringe every time I see a thread crossposted to these two groups.
>>>> Good seldomn comes of it. 
>>> Do you have an explanation for that?
>>>
>>> Any ideas except 'the other guys are so stupid'?
>> 
>> Market. Both OO and RDB are technologies with market products on sale.
> 
> Let's see if I can play with this using a metaphore.
> 
> So are, say, ships and engines (technologies with market products on
> sale). Both have their own laws.
> Designing a motorized boat requires a shared understanding
> of some of them. There is a market for sailing boats,
> there is a market for engines wchich can be used in other things than 
> ships. In this thread, we /are/ mixing. Shouldn't there be a market 
> for motorizing boats and for engines fit for use on a ship?

Ship and engine design are a proper engineering activities, while "software
engineering" is not. Exaggerating a lot, we could compare it with religions
and their "market products." Certainly a god is more worth if there is no
any other...

All technical disciplines are based on natural sciences which provide a
common ground for an interdisciplinary communication. This is not the case
for either OO or RDB. They not only compete in selling, often snake oil,
which questions whether they indeed are different disciplines, as your
example suggests. But also they do not have any elaborated scientific
disciplines backing them and shared by them. (I don't count mathematics,
which is as unspecific to software engineering, as for example English
language is)

> > People like topmind and frebe aren't
> > excommunicated regardless their propaganda. Does comp.databases.theory have
> > such?

> This is a c.o politically correct 'the other guys are so stupid' question. 

I just wished to know it for statistics... So the answer is 'no'? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/9/2008 2:44:02 PM
frebe <frebe73@gmail.com> writes:
>>�Even when the relational schema is embedded in a single
>> application, state changes for different reasons and as different
>> rates from behavior.
>
> Would you mind giving examples of such changes? (You can skip the
> "denormalisation for performance" example.)

     Denormalization for performance of a particular application is a
perfectly valid example.  Thanks for mentioning it.  Another reason
for the different rates of change are that new behaviors can be added
without the need for additional data.

>> � � �The object model, on the other hand, is optimized to address
>> non-functional requirements (NFRs) related to the problem domain.
>
> Doesn't that indicate that OO is pretty low-level, and that the
> coupling between the logical model and the phisycal model is high?

     Not at all.  OO supports the creation of abstractions that
represent concepts in both the problem and solution domain.  Those
abstractions constitute a type of domain specific language (DSL) for
better expression of the solution implementation.  Naturally, some
languages are better at this abstraction than others.

     Some of the components in an OO system will be closer to details
such as data formats and network protocols while others will deal with
problem and solution concepts like service lease management and value
at risk calculations (to take two examples from a recent project).
Techniques like dependency inversion, among many others, allow these
components to be decoupled as much as possible, to allow
non-disruptive modification and extension.

     The terms "high level" and "low level" tend to be more pejorative
than descriptive in these discussions.  They make sense within a
particular paradigm, but generate more heat than light across paradigms.

> Wouldn't it be better if we could separate the logical model
> handling functional requirements, and the physical model handling
> non- functional requirements?

     That can be easily done with OO techniques.  In fact, one of the
selling points of the product suite I work with in my day job is that
the application code is insulated from the deployment topology.  That
product is built on an OO design using OO languages.

>> > Maybe somebody may suggest me some article about mixing together
>> > DB and OOP?
>>
>> � � �Because of the impedance mismatch, most OO systems use some
>> form of object-relational mapping. �
>
> O/R mapping is not the best way of mixing together DB and OOP.

     What alternative do you recommend?

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/9/2008 2:52:18 PM
mAsterdam <mAsterdam@vrijdag.org> wrote:

> Any ideas except 'the other guys are so stupid'?

I've been on comp.object a long time, never visited 
comp.databases.theory. David Cressey admitted to having "not seen much" 
of OO theory, so I will have to admit to having not seen much of 
database theory, and even less of SQL.

I bring up SQL because Mr. Cressey says that, "A lot of us mere 
practicioners [sic] treat the SQL model and the relational model as 
variations on the same theme." If SQL is the exemplar of the relational 
model, then let me propose that SmallTalk be used as the exemplar of the 
OO model (some in comp.object will strongly disagree, primarily because 
SmallTalk cannot handle multi-dispatching, but I'm willing to settle.)

Now I grant that I know very little of SQL, in fact I may know less of 
SQL than Mr. Cressey knows of SmallTalk, :-) but it seems to me that 
comparing the two languages, as exemplars, is fundamentally unfair to 
SQL simply because as I understand it, SQL is *not* turing complete, 
whereas SmallTalk is.

Since "mAsterdam" brought up the ship metaphor... Imagine two companies, 
one makes engines, while the other makes whole boats (engine included.) 
Even if the first company's engines are superior to the engines made by 
the second company, is it really fair to compare which of the companies' 
products are the best for going out to sea? I think not.

In response to mAsterdam's call for a civilized discussion of the pros 
and cons of both theories, I can't say much because I only know one side 
of the argument. But I will be following the thread in the hopes of 
learning something.
0
daniel_t (1960)
2/9/2008 3:32:13 PM
mAsterdam <mAsterdam@vrijdag.org> writes:
> Mixing OO and DB:
> In practise we do it all the time.
> In theory it can't work.
>
> Leslie Sanford wrote:
>
>> Newsgroups: comp.object, comp.databases.theory
>> I cringe every time I see a thread crossposted to these two groups.
>> Good seldomn comes of it. 
>
> Do you have an explanation for that?
>
> Within one group, the easy way is: the other guys are so stupid.
> Let's skip 'the other guys are so stupid' in this sub-thread.  I
> re-included cdt.
>
> Let's cross this divide, and behave as if it is a real border.  This
> means you can't carry all of your preconceptions, and you will have
> to adapt your language.
>
> Any ideas except 'the other guys are so stupid'?

     Ah, an idealist.  I love the smell of them being burned by their
own side in the morning....

     Seriously, I wish you luck in this endeavor.  My thoughts on this
are that different approaches ("paradigms", for lack of a better term)
are more suited to particular problem domains.  Not particularly
profound, I know.  The problem seems to stem from an all too common
desire, perhaps even a deep-seated human need, to identify with a
single paradigm.  It's the Highlander Principle in software:  There
can only be one!

     I'm old enough to have made the transition from client-server
systems written in C and SQL (Oracle 3 and 4, no less) to OO, first
with Zortech C++ and then other languages.  The people I know who went
through that transition are far less likely to be single-paradigm
bigots than people who know only Java (damn young whippersnappers)
because they have personally experienced the costs and benefits of
each set of techniques and idioms.

     Working in a variety of domains (both problem and solution) seems
to ameliorate single-paradigm bigotry as well.  People who have spent
their careers with big iron databases often lack the context to
understand the benefits of other paradigms, just as do newly minted
grads who know only Java.  One of my favorite interview questions is
"What do you like best about your favorite programming language or
environment and what would you change about it if you could?"  Anyone
who can't think of an improvement is out the door.

     I prefer to work with people who understand procedural,
relational, OO, and functional programming.  The boundaries between
these paradigms are not sharp -- useful techniques span paradigms.
Ultimately I'm looking for a gestalt development environment that
leverages the benefits of the superset of these techniques to deliver
high quality software.  That's the real goal, after all.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/9/2008 3:35:52 PM
David Cressey wrote:

> "mAsterdam" <mAsterdam@vrijdag.org> wrote in message
> news:47ad7dc5$0$85790$e4fe514c@news.xs4all.nl...
> 
>>Any ideas except 'the other guys are so stupid'?
> 
> My reaction is biased towards databases.  That's where I'm coming from.  No
> apologies for that.
> 
> I'd like to suggest that the origins of the database appraoch and the
> origins of the object oriented approach are very different.  The database
> approach started from an enterprise wide database and has scaled its way
> down to tiny (conceptually) databases embedded in single applications.  The
> object oriented approach started with simulations and scaled its way up to
> the problems that are being worked on now,  including enterprise wide
> solutions.

Did you see the sample code I wrote for a simulation in D a year or two ago?

[snip]
0
bbadour (434)
2/9/2008 4:28:50 PM
> >>=A0Even when the relational schema is embedded in a single
> >> application, state changes for different reasons and as different
> >> rates from behavior.
>
> > Would you mind giving examples of such changes? (You can skip the
> > "denormalisation for performance" example.)
>
> =A0 =A0 =A0Denormalization for performance of a particular application is =
a
> perfectly valid example. =A0

Unless your database supports materialized views.

>=A0Another reason
> for the different rates of change are that new behaviors can be added
> without the need for additional data.

Yes, pretty obvious. The schema is the foundation of the application.
There are many reason to change the application stack on top of the
schema. But do you have some example of a schema that need to be
changed, and the behavior doesn't need to change?

> >> =A0 =A0 =A0The object model, on the other hand, is optimized to address=

> >> non-functional requirements (NFRs) related to the problem domain.
>
> > Doesn't that indicate that OO is pretty low-level, and that the
> > coupling between the logical model and the phisycal model is high?
>
> =A0 =A0 =A0Not at all. =A0OO supports the creation of abstractions that
> represent concepts in both the problem and solution domain.

And the abstractions for concepts in the problem domain doesn't have
to be optimized to address non-functional requirements?

> =A0 =A0 =A0The terms "high level" and "low level" tend to be more pejorati=
ve
> than descriptive in these discussions. =A0They make sense within a
> particular paradigm, but generate more heat than light across paradigms.

I might have a naive definition of "high level" and "low level": If
you implement a solution using two different tools, the solution that
has less lines of source code and takes less time to implement, is the
most high-level.

> >> > Maybe somebody may suggest me some article about mixing together
> >> > DB and OOP?
>
> >> =A0 =A0 =A0Because of the impedance mismatch, most OO systems use some
> >> form of object-relational mapping. =A0
>
> > O/R mapping is not the best way of mixing together DB and OOP.
>
> =A0 =A0 =A0What alternative do you recommend?

My recommendation is that if you already are using a database, you
should not use objects as data structures. That is job is supposed to
be done by the database.

//frebe
0
frebe73 (444)
2/9/2008 4:50:59 PM
Victor Porton <porton@narod.ru> writes:
>object oriented programs which use DB.

  When the interface to the database is procedural, one might be
  forced to use procedural idioms to access it. One can write an
  object-oriented interface layer to the database and henceforth
  access the database only via this layer.

  A similar situation arises when one uses a class without access
  to its source code. Sometimes one can't use certain 
  object-oriented idioms then, if the class does not support them.

0
ram (2986)
2/9/2008 5:24:06 PM
"Daniel T." <daniel_t@earthlink.net> wrote in message
news:daniel_t-2CAF35.10321309022008@earthlink.vsrv-sjc.supernews.net...
> mAsterdam <mAsterdam@vrijdag.org> wrote:
>
> > Any ideas except 'the other guys are so stupid'?
>
> I've been on comp.object a long time, never visited
> comp.databases.theory. David Cressey admitted to having "not seen much"
> of OO theory, so I will have to admit to having not seen much of
> database theory, and even less of SQL.
>
> I bring up SQL because Mr. Cressey says that, "A lot of us mere
> practicioners [sic] treat the SQL model and the relational model as
> variations on the same theme." If SQL is the exemplar of the relational
> model, then let me propose that SmallTalk be used as the exemplar of the
> OO model (some in comp.object will strongly disagree, primarily because
> SmallTalk cannot handle multi-dispatching, but I'm willing to settle.)
>
> Now I grant that I know very little of SQL, in fact I may know less of
> SQL than Mr. Cressey knows of SmallTalk, :-) but it seems to me that
> comparing the two languages, as exemplars, is fundamentally unfair to
> SQL simply because as I understand it, SQL is *not* turing complete,
> whereas SmallTalk is.

Turing completeness is not, IMO, as important in a data sublanguage as it is
in a programming language.  A Turing complete extension of SQL could be
made.

BTW, SQL is,  strictly speaking, not in line with the relational model.  The
differences  were important to Ed Codd.  They are also important to some of
the c.d.t. regulars.  Smalltalk is closer to being mainstream in OOP than
SQL is to being mainstream in RM.

>
> Since "mAsterdam" brought up the ship metaphor... Imagine two companies,
> one makes engines, while the other makes whole boats (engine included.)
> Even if the first company's engines are superior to the engines made by
> the second company, is it really fair to compare which of the companies'
> products are the best for going out to sea? I think not.
>

Database theory and practice does not cover the same ground that programming
theory and practice does.

> In response to mAsterdam's call for a civilized discussion of the pros
> and cons of both theories, I can't say much because I only know one side
> of the argument. But I will be following the thread in the hopes of
> learning something.

If the past is any guide,  the discussion will generate more heat than
light.


0
cressey73 (124)
2/9/2008 5:40:04 PM

Patrick May wrote:
> mAsterdam <mAsterdam@vrijdag.org> writes:
> > Mixing OO and DB:
> > In practise we do it all the time.
> > In theory it can't work.
> >
> > Leslie Sanford wrote:
> >
> >> Newsgroups: comp.object, comp.databases.theory
> >> I cringe every time I see a thread crossposted to these two groups.
> >> Good seldomn comes of it.
> >
> > Do you have an explanation for that?
> >
> > Within one group, the easy way is: the other guys are so stupid.
> > Let's skip 'the other guys are so stupid' in this sub-thread.  I
> > re-included cdt.
> >
> > Let's cross this divide, and behave as if it is a real border.  This
> > means you can't carry all of your preconceptions, and you will have
> > to adapt your language.
> >
> > Any ideas except 'the other guys are so stupid'?
>
>      Ah, an idealist.  I love the smell of them being burned by their
> own side in the morning....
>
>      Seriously, I wish you luck in this endeavor.  My thoughts on this
> are that different approaches ("paradigms", for lack of a better term)
> are more suited to particular problem domains.  Not particularly
> profound, I know.  The problem seems to stem from an all too common
> desire, perhaps even a deep-seated human need, to identify with a
> single paradigm.  It's the Highlander Principle in software:  There
> can only be one!
>
>      I'm old enough to have made the transition from client-server
> systems written in C and SQL (Oracle 3 and 4, no less) to OO, first
> with Zortech C++ and then other languages.  The people I know who went
> through that transition are far less likely to be single-paradigm
> bigots than people who know only Java (damn young whippersnappers)
> because they have personally experienced the costs and benefits of
> each set of techniques and idioms.
>
>      Working in a variety of domains (both problem and solution) seems
> to ameliorate single-paradigm bigotry as well.  People who have spent
> their careers with big iron databases often lack the context to
> understand the benefits of other paradigms, just as do newly minted
> grads who know only Java.  One of my favorite interview questions is
> "What do you like best about your favorite programming language or
> environment and what would you change about it if you could?"  Anyone
> who can't think of an improvement is out the door.
>
>      I prefer to work with people who understand procedural,
> relational, OO, and functional programming.  The boundaries between
> these paradigms are not sharp -- useful techniques span paradigms.
> Ultimately I'm looking for a gestalt development environment that
> leverages the benefits of the superset of these techniques to deliver
> high quality software.  That's the real goal, after all.

The problem with paradigm-potpourri is that its more expensive to hire
people who have sufficient experience in them all. The industry tends
to force programmers into managers or unemployment after about 15
years, and 15 years is not enough for most programmers to master that
many paradigms. And, I don't think the benefits of mixing is strong
enough to offset that either.

>
> Regards,
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
>                        | systems design and implementation.
>           pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)

-T-
0
topmind (2124)
2/9/2008 7:37:47 PM

Dmitry A. Kazakov wrote:

> P.S. I don't want to appear politically correct. IMO comp.object is less
> aggressive than comp.databases.theory. People like topmind and frebe aren't
> excommunicated regardless their propaganda.

Believe me, they've tried.

> Does comp.databases.theory have
> such?
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

-T-
0
topmind (2124)
2/9/2008 7:41:56 PM

David Cressey wrote:
> "mAsterdam" <mAsterdam@vrijdag.org> wrote in message
> news:47ad7dc5$0$85790$e4fe514c@news.xs4all.nl...
>
> > Any ideas except 'the other guys are so stupid'?
>
> My reaction is biased towards databases.  That's where I'm coming from.  No
> apologies for that.
>
> I'd like to suggest that the origins of the database appraoch and the
> origins of the object oriented approach are very different.  The database
> approach started from an enterprise wide database and has scaled its way
> down to tiny (conceptually) databases embedded in single applications.  The
> object oriented approach started with simulations and scaled its way up to
> the problems that are being worked on now,  including enterprise wide
> solutions.
>
> The fundamental problem to be addressed in database work is shareability.
> If database data is not shareable, it's less valuable.  Codd's work on
> applying the relational model of data to the organization of databases for
> large scale sharing of large scale data is fundamentally aimed at promoting
> uniformity and thereby shareability without unduly limiting flexibility at
> the low end.  In the trade-off between  uniformity and flexibility, the
> relational model pushed the envelope so far out that all of the other
> database contenders from the 1970s have been almost pushed off the map.  I'm
> thinking of the graph based DBMS products that dominated the market in circa
> 1978.
>
> While theoretical advances such as those discussed in c.d.t. are important
> in their own right, the fundamental market presence of the relational model
> in practical work has settled on the SQL model of data.  A lot of us mere
> practicioners treat the SQL model and the relational model as variations on
> the same theme.  In terms of the internals of data storage,  data blocks
> that can contain table rows or index nodes make up the bulk of the data
> whose management  is transparent to the users of the DBMS.
>
> The fundamental problem in simulations, as I see it,  is autonomy.  If each
> unit in a simulation is not autonomous, the simulation will be constrained
> at the system level to behave in ways that do not mimic the systems being
> simulated.  Objects are largely autonomous,  and that is their great
> utility.  Objects are more autonomous than functions and procedures from the
> great programming languages of the 1970s because objects carry state.  That
> is why OOP has displaced structured programming to a large extent.

In name only, actually. Most production code for custom apps is not
very OOP. It may use a lot of pre-packaged classes, but the code
itself is mostly procedural in OO clothing.

>
> In order for objects to collaborate they have to exchange signals  (data).
> In order to usefully exchange data,  there has to be a common convention
> regarding both the form and the content of the messages passed between
> objects.  Most of the OO stuff I've seen (which isn't very much)
> concentrate on bilateral contracts between pairs of objects as to what the
> form and content  (meaning?) of exchanged messages will be.
>
> Most of the best database work concentrates on universal contracts (although
> the word "contracted" isn't widely used) governing the entire body of data
> stored in a database,  and a vast multitude of transactions that collaborate
> (going forward in time) that adhere to the single contract or some subset of
> it.
>
> This looks overly [constraining] to the programmer accustomed to object
> oriented thinking.

I think part of the problem is that there are not enough "nimble
RDBMS" or table engines around, with such ideas as dynamic columns and
dynamic tables. It's like judging OOP by only looking at Java and
Eiffel instead of Smalltalk and Python.

>
> The bilateral contracts that tend to govern data exchange in object worlds
> look chaotic to someone such as myself,  schooled in database work.
>
> This is the best I can do to describe the differences in non-pejorative
> terms.

If there is rhyme and reason to OO designs, OO proponents are
obligated to show it. Instead we get different stories and black-box
anecdotes.

-T-
0
topmind (2124)
2/9/2008 11:08:46 PM
frebe <frebe73@gmail.com> writes:
>> >>�Even when the relational schema is embedded in a single
>> >> application, state changes for different reasons and as
>> >> different rates from behavior.
>>
>> > Would you mind giving examples of such changes? (You can skip the
>> > "denormalisation for performance" example.)
>>
>> � � �Denormalization for performance of a particular application is
>> a perfectly valid example. �
>
> Unless your database supports materialized views.

     And if your application can accept that the data in those views
may be out of date.

>>�Another reason for the different rates of change are that new
>> behaviors can be added without the need for additional data.
>
> Yes, pretty obvious. The schema is the foundation of the
> application.

     Actually, it's the behavior that's the foundation of the
application.  A relational schema may not be necessary at all or may
be simply an implementation choice.

> There are many reason to change the application stack on top of the
> schema. But do you have some example of a schema that need to be
> changed, and the behavior doesn't need to change?

     In addition to denormalization for performance, examples where
the database is shared are trivial to find.  Not all applications
change at the same rate, so not all applications need the same schema
changes.

     With a single application database, distributed applications
demonstrate additional trivial scenarios.  A new service or agent
might need data that is not of interest to existing services and
agents.

>> >>      The object model, on the other hand, is optimized to
>> >> address non-functional requirements (NFRs) related to the
>> >> problem domain.
>>
>> > Doesn't that indicate that OO is pretty low-level, and that the
>> > coupling between the logical model and the phisycal model is high?
>>
>>      Not at all.  OO supports the creation of abstractions that
>> represent concepts in both the problem and solution domain.
>
> And the abstractions for concepts in the problem domain doesn't have
> to be optimized to address non-functional requirements?

     Some may be involved in addressing NFRs such as performance,
scalability, high availability, resiliency, and so forth, certainly.

>>      The terms "high level" and "low level" tend to be more
>> pejorative than descriptive in these discussions.  They make sense
>> within a particular paradigm, but generate more heat than light
>> across paradigms.
>
> I might have a naive definition of "high level" and "low level": If
> you implement a solution using two different tools, the solution
> that has less lines of source code and takes less time to implement,
> is the most high-level.

     That sounds closer to a definition of "expressiveness".

>> >> > Maybe somebody may suggest me some article about mixing
>> >> > together DB and OOP?
>>
>> >>      Because of the impedance mismatch, most OO systems use some
>> >> form of object-relational mapping.
>>
>> > O/R mapping is not the best way of mixing together DB and OOP.
>>
>>      What alternative do you recommend?
>
> My recommendation is that if you already are using a database, you
> should not use objects as data structures. That is job is supposed
> to be done by the database.

     So your answer to the question "How do I mix OO and relational?"
is "Don't use OO."  Succinct, but not particularly responsive.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/9/2008 11:18:03 PM
Dmitry A. Kazakov wrote:
> mAsterdam wrote:
>> Dmitry A. Kazakov wrote:
>>> mAsterdam wrote:
>>>> Leslie Sanford wrote:
>>>>
>>>>> Newsgroups: comp.object, comp.databases.theory
>>>>> I cringe every time I see a thread crossposted to these two groups.
>>>>> Good seldomn comes of it. 
>>>> Do you have an explanation for that?
>>>>
>>>> Any ideas except 'the other guys are so stupid'?
>>> Market. Both OO and RDB are technologies with market products on sale.
>> Let's see if I can play with this using a metaphore.
>>
>> So are, say, ships and engines (technologies with market products on
>> sale). Both have their own laws.
>> Designing a motorized boat requires a shared understanding
>> of some of them. There is a market for sailing boats,
>> there is a market for engines wchich can be used in other things than 
>> ships. In this thread, we /are/ mixing. Shouldn't there be a market 
>> for motorizing boats and for engines fit for use on a ship?
> 
> Ship and engine design are a proper engineering activities, while "software
> engineering" is not. Exaggerating a lot, we could compare it with religions
> and their "market products." Certainly a god is more worth if there is no
> any other...

Metaphores only go so far. However, if you are extending it to
religion just to illustrate the depth of the divide and the
presence of the unknown, there is no need to do so.
No shipwright knows all there is to know about ships,
even about the ones of his own design.
Engines have come a long enough way to have that as well.

> All technical disciplines are based on natural sciences which provide a
> common ground for an interdisciplinary communication. This is not the case
> for either OO or RDB. They not only compete in selling, often snake oil,
> which questions whether they indeed are different disciplines, as your
> example suggests. 

It does indeed. If studying OO and DB are not
different disciplines then their whole ground is common.
What is left is dogma, groupthink and language.
Does that explain the whole of the divide?
I don't think so.

> But also they do not have any elaborated scientific
> disciplines backing them and shared by them. (I don't count mathematics,
> which is as unspecific to software engineering, as for example English
> language is)

Though specialized formalisms do exist, math is helpfull
to all disciplines. So, yes.
I think it can't be the main source of the divide.

<interesting snip>

>>> People like topmind and frebe aren't
>>> excommunicated regardless their propaganda. Does comp.databases.theory have
>>> such?
> 
>> This is a c.o politically correct 'the other guys are so stupid' question. 
> 
> I just wished to know it for statistics... So the answer is 'no'? (:-))

Table manners can be quite offensive.


--
What you see depends on where you stand.
0
mAsterdam (155)
2/9/2008 11:38:41 PM
Daniel T. wrote:
> mAsterdam wrote:
<unsnip>
>> Leslie Sanford wrote:
>> Newsgroups: comp.object, comp.databases.theory
>> 
>> I cringe every time I see a thread crossposted to these two groups.  
>> Good seldomn comes of it. 

</unsnip>
> Any ideas except 'the other guys are so stupid'?

[snip]
> Since "mAsterdam" brought up the ship metaphor... Imagine two companies, 
> one makes engines, while the other makes whole boats (engine included.) 
> Even if the first company's engines are superior to the engines made by 
> the second company, is it really fair to compare which of the companies' 
> products are the best for going out to sea? I think not.

Metaphores only... etc. We have to constantly check wether the nuance 
of a metaphore is still relevant to the topic. In this case, I think 
it is. I am not asking to compare products. I am wondering why
problems, which are dealt with in practise every day, are not dealt
with in theory.

> In response to mAsterdam's call for a civilized discussion of the pros 
> and cons of both theories, I can't say much because I only know one side 
> of the argument. But I will be following the thread in the hopes of 
> learning something.

While I would not mind such a discussion in a specific setting,
it is not what I am asking for. If it is just a matter of pros and 
cons in general, let's just pick the best and get on.
OO and DB serve different purposes.
The balance should be situational.


--
What you see depends on where you stand.
0
mAsterdam (155)
2/10/2008 12:07:00 AM
Patrick May wrote:
> mAsterdam writes:
>> Mixing OO and DB:
>> In practise we do it all the time.
>> In theory it can't work.
>>
>> Leslie Sanford wrote:
>>
>>> Newsgroups: comp.object, comp.databases.theory
>>> I cringe every time I see a thread crossposted to these two groups.
>>> Good seldomn comes of it. 
>> Do you have an explanation for that?
>>
>> Within one group, the easy way is: the other guys are so stupid.
>> Let's skip 'the other guys are so stupid' in this sub-thread.  I
>> re-included cdt.
>>
>> Let's cross this divide, and behave as if it is a real border.  This
>> means you can't carry all of your preconceptions, and you will have
>> to adapt your language.
>>
>> Any ideas except 'the other guys are so stupid'?
> 
>      Ah, an idealist.  I love the smell of them being burned by their
> own side in the morning....

Idealist - who, me? Don't know, I don't think so.
Anyway, the ones burning those who cross borders
are not on my side. They never were.

>      Seriously, I wish you luck in this endeavor.  My thoughts on this
> are that different approaches ("paradigms", for lack of a better term)

approach?

> are more suited to particular problem domains.  Not particularly
> profound, I know.  The problem seems to stem from an all too common
> desire, perhaps even a deep-seated human need, to identify with a
> single paradigm.  It's the Highlander Principle in software:  There
> can only be one!
> 
>      I'm old enough to have made the transition from client-server
> systems written in C and SQL (Oracle 3 and 4, no less) to OO, first
> with Zortech C++ and then other languages.  

Zortech, because Borland did not like the name Zorland.

> The people I know who went
> through that transition are far less likely to be single-paradigm
> bigots than people who know only Java (damn young whippersnappers)
> because they have personally experienced the costs and benefits of
> each set of techniques and idioms.
> 
>      Working in a variety of domains (both problem and solution) seems
> to ameliorate single-paradigm bigotry as well.  People who have spent
> their careers with big iron databases often lack the context to
> understand the benefits of other paradigms, just as do newly minted
> grads who know only Java.  One of my favorite interview questions is
> "What do you like best about your favorite programming language or
> environment and what would you change about it if you could?"  Anyone
> who can't think of an improvement is out the door.
> 
>      I prefer to work with people who understand procedural,
> relational, OO, and functional programming.  The boundaries between
> these paradigms are not sharp -- useful techniques span paradigms.
> Ultimately I'm looking for a gestalt development environment that
> leverages the benefits of the superset of these techniques to deliver
> high quality software.  That's the real goal, after all.

That is stricly one side of the fence - it is the goal for a
software development process.
The goal for a DB is to serve as a vehicle to manage data.

Paradigm, gestalt development environment, leverages the benefits of 
the superset of these techniques, gestalt development, I'll requote:

 >> Let's cross this divide, and behave as if it is a real border.
 >> This means you can't carry all of your preconceptions,
 >> and you will have to adapt your language.

Do I need to explain?


--
What you see depends on where you stand.
0
mAsterdam (155)
2/10/2008 12:50:04 AM

mAsterdam wrote:
> Patrick May wrote:

> > The people I know who went
> > through that transition are far less likely to be single-paradigm
> > bigots than people who know only Java (damn young whippersnappers)
> > because they have personally experienced the costs and benefits of
> > each set of techniques and idioms.
> >
> >      Working in a variety of domains (both problem and solution) seems
> > to ameliorate single-paradigm bigotry as well.  People who have spent
> > their careers with big iron databases often lack the context to
> > understand the benefits of other paradigms, just as do newly minted
> > grads who know only Java.  One of my favorite interview questions is
> > "What do you like best about your favorite programming language or
> > environment and what would you change about it if you could?"  Anyone
> > who can't think of an improvement is out the door.
> >
> >      I prefer to work with people who understand procedural,
> > relational, OO, and functional programming.  The boundaries between
> > these paradigms are not sharp -- useful techniques span paradigms.
> > Ultimately I'm looking for a gestalt development environment that
> > leverages the benefits of the superset of these techniques to deliver
> > high quality software.  That's the real goal, after all.
>
> That is stricly one side of the fence - it is the goal for a
> software development process.
> The goal for a DB is to serve as a vehicle to manage data.
>

The line between those can be very fuzzy. It is possible to formulate
the vast majority of just about any app you see as "managing data",
especially if you have good data-centric tools. How far one goes is an
age-old battle.

-T-
0
topmind (2124)
2/10/2008 1:20:13 AM
mAsterdam <mAsterdam@vrijdag.org> writes:
> Patrick May wrote:
>>      I prefer to work with people who understand procedural,
>> relational, OO, and functional programming.  The boundaries between
>> these paradigms are not sharp -- useful techniques span paradigms.
>> Ultimately I'm looking for a gestalt development environment that
>> leverages the benefits of the superset of these techniques to
>> deliver high quality software.  That's the real goal, after all.
>
> That is stricly one side of the fence - it is the goal for a
> software development process.  The goal for a DB is to serve as a
> vehicle to manage data.

     I disagree.  Software is a means to an end, not an end in itself,
at least in the vast majority of commercial settings.  Databases are
just one type of software.  The end goal is to provide business
value.  Quality software, meaning software that meets the current
needs of the business, that can be easily extended to meet future
needs, and that is economically feasible to develop, provides that
business value.  No business really wants a database per se, but many
do want the benefits of rapid access to consistent business
information.

> Paradigm, gestalt development environment, leverages the benefits of
> the superset of these techniques, gestalt development, I'll requote:
>
>>> Let's cross this divide, and behave as if it is a real border.
>>> This means you can't carry all of your preconceptions, and you
>>> will have to adapt your language.
>
> Do I need to explain?

     Evidently, because I don't accept that the divide exists in any
meaningful sense.  I use multiple paradigms as the situation warrants
and I work with a number of people who do as well.  They're all just
different tools, each with advantages and disadvantages.  Grouping one
set of tools together and calling it "relational", another set "object
oriented", and another set "functional" is useful to identify those
that complement each other, but it's important to realize that those
sets are not disjoint.  It's also important to realize that the tools
in each set complement each other _in a particular context_.  In a
different context, that is, a different problem or solution domain,
different sets of tools may make sense.

     There are more things in heaven and earth, mAsterdam, than are
dreamt of in your paradigms.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/10/2008 4:17:18 AM
On Feb 9, 8:17 pm, Patrick May <p...@spe.com> wrote:
> mAsterdam <mAster...@vrijdag.org> writes:
> > Patrick May wrote:
> >>      I prefer to work with people who understand procedural,
> >> relational, OO, and functional programming.  The boundaries between
> >> these paradigms are not sharp -- useful techniques span paradigms.
> >> Ultimately I'm looking for a gestalt development environment that
> >> leverages the benefits of the superset of these techniques to
> >> deliver high quality software.  That's the real goal, after all.
>
> > That is stricly one side of the fence - it is the goal for a
> > software development process.  The goal for a DB is to serve as a
> > vehicle to manage data.
>
>      I disagree.  Software is a means to an end, not an end in itself,
> at least in the vast majority of commercial settings.  Databases are
> just one type of software.  The end goal is to provide business
> value.  Quality software, meaning software that meets the current
> needs of the business, that can be easily extended to meet future
> needs, and that is economically feasible to develop, provides that
> business value.  No business really wants a database per se, but many
> do want the benefits of rapid access to consistent business
> information.
>
> > Paradigm, gestalt development environment, leverages the benefits of
> > the superset of these techniques, gestalt development, I'll requote:
>
> >>> Let's cross this divide, and behave as if it is a real border.
> >>> This means you can't carry all of your preconceptions, and you
> >>> will have to adapt your language.
>
> > Do I need to explain?
>
>      Evidently, because I don't accept that the divide exists in any
> meaningful sense.  I use multiple paradigms as the situation warrants
> and I work with a number of people who do as well.  They're all just
> different tools, each with advantages and disadvantages.  Grouping one
> set of tools together and calling it "relational", another set "object
> oriented", and another set "functional" is useful to identify those
> that complement each other, but it's important to realize that those
> sets are not disjoint.  It's also important to realize that the tools
> in each set complement each other _in a particular context_.  In a
> different context, that is, a different problem or solution domain,
> different sets of tools may make sense.

But OOP and relational often don't compliment each other, but instead
fight over territory. Unless clear and logical rules form that tell us
when to stop one and start the other, this problem is not small.

Product/domain classification systems are a prime example. If you
manage them in the database, then you don't need polymorphism (unless
you duplicate information unnecessarily). Further, the set-oriented
classification systems used in relational are often not compatible
with the DAG/tree-based classification systems preferred by OO.

It's not just where the classification is represented, but how.
Personally, I think sets are superior to DAG-based taxonomies for
managing variations-on-a-theme.

>
>      There are more things in heaven and earth, mAsterdam, than are
> dreamt of in your paradigms.
>
> Regards,
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
>                        | systems design and implementation.
>           p...@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)

-T-
0
topmind (2124)
2/10/2008 5:58:27 AM
On 10 Feb, 00:18, Patrick May <p...@spe.com> wrote:
> frebe <freb...@gmail.com> writes:
> >> >>=A0Even when the relational schema is embedded in a single
> >> >> application, state changes for different reasons and as
> >> >> different rates from behavior.
>
> >> > Would you mind giving examples of such changes? (You can skip the
> >> > "denormalisation for performance" example.)
>
> >> =A0 =A0 =A0Denormalization for performance of a particular application =
is
> >> a perfectly valid example. =A0
>
> > Unless your database supports materialized views.
>
> =A0 =A0 =A0And if your application can accept that the data in those views=

> may be out of date.

Unless you do "refresh on commit".

Having a denormalized schema is also a good way of introducing data
that is out of date. It is also an advantage if the RDBMS can handle
the consistency issues. If you try to handle them by yourself, it is
more likely that it will fail.

> =A0 =A0 =A0With a single application database, distributed applications
> demonstrate additional trivial scenarios. =A0A new service or agent
> might need data that is not of interest to existing services and
> agents.

The reason why the schema change is that the behavior change. Behavior
and schema doesn't change for different reasons.

> >> >> > Maybe somebody may suggest me some article about mixing
> >> >> > together DB and OOP?
>
> >> >> =A0 =A0 =A0Because of the impedance mismatch, most OO systems use so=
me
> >> >> form of object-relational mapping.
>
> >> > O/R mapping is not the best way of mixing together DB and OOP.
>
> >> =A0 =A0 =A0What alternative do you recommend?
>
> > My recommendation is that if you already are using a database, you
> > should not use objects as data structures. That is job is supposed
> > to be done by the database.
>
> =A0 =A0 =A0So your answer to the question "How do I mix OO and relational?=
"
> is "Don't use OO." =A0Succinct, but not particularly responsive.

I didn't say that. Like I said before, classes may perfectly well be
used for defining types for relational attributes. Objects map to
attribute values, not to relations.

//frebe
0
frebe73 (444)
2/10/2008 6:07:35 AM
"topmind" <topmind@technologist.com> wrote in message
news:09e3c5bf-b099-46b1-bfa3-9076ba08b2c1@i29g2000prf.googlegroups.com...
>
>
> David Cressey wrote:

> > The fundamental problem in simulations, as I see it,  is autonomy.  If
each
> > unit in a simulation is not autonomous, the simulation will be
constrained
> > at the system level to behave in ways that do not mimic the systems
being
> > simulated.  Objects are largely autonomous,  and that is their great
> > utility.  Objects are more autonomous than functions and procedures from
the
> > great programming languages of the 1970s because objects carry state.
That
> > is why OOP has displaced structured programming to a large extent.
>
> In name only, actually. Most production code for custom apps is not
> very OOP. It may use a lot of pre-packaged classes, but the code
> itself is mostly procedural in OO clothing.
>

A very analogous problem exists in many SQL databases in the field.  At
least, the problem existed 7 years ago, and I believe persists to this day.
A large number of SQL database designers have only a primitive idea of how
the relational data model works,  or how to use it wisely.  They design
databases as if they were designing a network of linked records,  just as
they would have in the 1970s.

Then they dress their design in relational clothing,  and pass it off as
relational.  As a consequence, what can really be done with a relational
system is frequently so  completely misrepresented that the unwary form a
distorted view of what it's all about.


> >
> > In order for objects to collaborate they have to exchange signals
(data).
> > In order to usefully exchange data,  there has to be a common convention
> > regarding both the form and the content of the messages passed between
> > objects.  Most of the OO stuff I've seen (which isn't very much)
> > concentrate on bilateral contracts between pairs of objects as to what
the
> > form and content  (meaning?) of exchanged messages will be.
> >
> > Most of the best database work concentrates on universal contracts
(although
> > the word "contracted" isn't widely used) governing the entire body of
data
> > stored in a database,  and a vast multitude of transactions that
collaborate
> > (going forward in time) that adhere to the single contract or some
subset of
> > it.
> >
> > This looks overly [constraining] to the programmer accustomed to object
> > oriented thinking.
>
> I think part of the problem is that there are not enough "nimble
> RDBMS" or table engines around, with such ideas as dynamic columns and
> dynamic tables. It's like judging OOP by only looking at Java and
> Eiffel instead of Smalltalk and Python.
>

Your idea of "nimble"  and my idea of "chaotic" might overlap.  We are going
to have to watch out for that subthread if we are going to in fact exchange
useful views on OO and RDM, and not quickly degenerate into name calling.



0
cressey73 (124)
2/10/2008 6:42:14 AM
"Patrick May" <pjm@spe.com> wrote in message news:m2sl01sawh.fsf@spe.com...
> mAsterdam <mAsterdam@vrijdag.org> writes:
> > Patrick May wrote:
> >>      I prefer to work with people who understand procedural,
> >> relational, OO, and functional programming.  The boundaries between
> >> these paradigms are not sharp -- useful techniques span paradigms.
> >> Ultimately I'm looking for a gestalt development environment that
> >> leverages the benefits of the superset of these techniques to
> >> deliver high quality software.  That's the real goal, after all.
> >
> > That is stricly one side of the fence - it is the goal for a
> > software development process.  The goal for a DB is to serve as a
> > vehicle to manage data.
>
>      I disagree.  Software is a means to an end, not an end in itself,
> at least in the vast majority of commercial settings.  Databases are
> just one type of software.

I would have said "DBMSes are just one type of software."  Is that what you
meant?

I don't think of a database as "software".

I agree with much of your major point, by the way.


0
cressey73 (124)
2/10/2008 6:48:51 AM
On Sun, 10 Feb 2008 00:38:41 +0100, mAsterdam wrote:

> Dmitry A. Kazakov wrote:
>> mAsterdam wrote:
>>> Dmitry A. Kazakov wrote:
>>>> mAsterdam wrote:
>>>>> Leslie Sanford wrote:
>>>>>
>>>>>> Newsgroups: comp.object, comp.databases.theory
>>>>>> I cringe every time I see a thread crossposted to these two groups.
>>>>>> Good seldomn comes of it. 
>>>>> Do you have an explanation for that?
>>>>>
>>>>> Any ideas except 'the other guys are so stupid'?
>>>> Market. Both OO and RDB are technologies with market products on sale.
>>> Let's see if I can play with this using a metaphore.
>>>
>>> So are, say, ships and engines (technologies with market products on
>>> sale). Both have their own laws.
>>> Designing a motorized boat requires a shared understanding
>>> of some of them. There is a market for sailing boats,
>>> there is a market for engines wchich can be used in other things than 
>>> ships. In this thread, we /are/ mixing. Shouldn't there be a market 
>>> for motorizing boats and for engines fit for use on a ship?
>> 
>> Ship and engine design are a proper engineering activities, while "software
>> engineering" is not. Exaggerating a lot, we could compare it with religions
>> and their "market products." Certainly a god is more worth if there is no
>> any other...
> 
> Metaphores only go so far. However, if you are extending it to
> religion just to illustrate the depth of the divide and the
> presence of the unknown, there is no need to do so.
> No shipwright knows all there is to know about ships,
> even about the ones of his own design.
> Engines have come a long enough way to have that as well.

So software engineering will do in the future. But presently there is no
hundreds of years behind us. Consider, year 2000 B.C., a discussion about
merits of whips against clubs for slave management. Surely slave management
is fundamental for ships propelling, slaves have to be arranged in rows,
etc...

>> All technical disciplines are based on natural sciences which provide a
>> common ground for an interdisciplinary communication. This is not the case
>> for either OO or RDB. They not only compete in selling, often snake oil,
>> which questions whether they indeed are different disciplines, as your
>> example suggests. 
> 
> It does indeed. If studying OO and DB are not
> different disciplines then their whole ground is common.
> What is left is dogma, groupthink and language.
> Does that explain the whole of the divide?

Yes, because the common ground is not understood and not even articulated.

When in a subthread Patrick May wrote about the goals of software design
(quality), you disagreed. In your metaphor, he just said that a ship should
float. You replied that it is not about ships. How can we discuss means
when there is no agreement on what we are going to achieve?

Anybody on my side of the fence would say that DB is merely a software. But
that is a consequence of an even more heretical concept that data is a
fiction, a product of some language. (So any distinction between DB and
DBMS is also fictional.) This is what divides us, not engineering
techniques.

> Table manners can be quite offensive.

from food's point of view...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/10/2008 9:22:50 AM
David Cressey wrote:
> "Patrick May" <pjm@spe.com> wrote in message news:m2sl01sawh.fsf@spe.com...
> 
>>mAsterdam <mAsterdam@vrijdag.org> writes:
>>
>>>Patrick May wrote:
>>>
>>>>     I prefer to work with people who understand procedural,
>>>>relational, OO, and functional programming.  The boundaries between
>>>>these paradigms are not sharp -- useful techniques span paradigms.
>>>>Ultimately I'm looking for a gestalt development environment that
>>>>leverages the benefits of the superset of these techniques to
>>>>deliver high quality software.  That's the real goal, after all.
>>>
>>>That is stricly one side of the fence - it is the goal for a
>>>software development process.  The goal for a DB is to serve as a
>>>vehicle to manage data.
>>
>>     I disagree.  Software is a means to an end, not an end in itself,
>>at least in the vast majority of commercial settings.  Databases are
>>just one type of software.
> 
> I would have said "DBMSes are just one type of software."  Is that what you
> meant?
> 
> I don't think of a database as "software".
> 
> I agree with much of your major point, by the way.

When did vehicles cease to be means to ends and become ends themselves?
0
bbadour (434)
2/10/2008 12:38:07 PM
Patrick May wrote:
> mAsterdam writes:
>> Patrick May wrote:
>>>      I prefer to work with people who understand procedural,
>>> relational, OO, and functional programming.  The boundaries between
>>> these paradigms are not sharp -- useful techniques span paradigms.
>>> Ultimately I'm looking for a gestalt development environment that
>>> leverages the benefits of the superset of these techniques to
>>> deliver high quality software.  That's the real goal, after all.
>> That is stricly one side of the fence - it is the goal for a
>> software development process.  The goal for a DB is to serve as a
>> vehicle to manage data.
> 
>      I disagree.  

Whith 'The goal for a DB is to serve as a vehicle to manage data.',
or with 'stricly one side of the fence', or with both?

> Software is a means to an end, not an end in itself,
> at least in the vast majority of commercial settings.  

Software is a business asset, not the business itself
'in the vast majority of commercial settings'.
That is just excluding software companies.
One can distinguish between their products and
the stuff they use to do their business - even
when they do eat their own dogfood.

I don't see the relevance of this exclusion (yet?).
If your point is just a proposal to look at it as
a means to an end - I'm ok with that.

> Databases are just one type of software.  

Conflating database and the software supporting it, DBMS.

Do you need that? The further you are away from something
the less distinctions you see, of course, but when reasoning
about one part leads you to wrong conclusions about the whole,
you'll have to inspect more closely.

> The end goal is to provide business value. 

Is data a business asset in your view?

> Quality software, meaning software that meets the current
> needs of the business, that can be easily extended to meet future
> needs, and that is economically feasible to develop, provides that
> business value.  No business really wants a database per se, but many
> do want the benefits of rapid access to consistent business
> information.

Somewhat like answering 'Is data a business asset in your view?'
With 'not per se'.
Not accepting a reason of being is another way of
saying 'the other guys are so stupid'.

>> Paradigm, gestalt development environment, leverages the benefits of
>> the superset of these techniques, gestalt development, I'll requote:
>>
>>>> Let's cross this divide, and behave as if it is a real border.
>>>> This means you can't carry all of your preconceptions, and you
>>>> will have to adapt your language.
>> Do I need to explain?
> 
> Evidently, because I don't accept that the divide exists in any
> meaningful sense.  

So, nothing to mix. This denies the validity of the OP's question.

I'd snip the rest, but there was something of interest per se
in the remainder of your post.

> I use multiple paradigms as the situation warrants
> and I work with a number of people who do as well. 
> They're all just different tools, each with advantages and disadvantages.

http://en.wikipedia.org/wiki/Paradigm currently says:
"Kuhn defines a scientific paradigm as:

     * what is to be observed and scrutinized
     * the kind of questions that are supposed to be asked and
       probed for answers in relation to this subject
     * how these questions are to be structured
     * how the results of scientific investigations should be
       interpreted",
and there is a link to a nice article:
http://www.mnsu.edu/comdis/kuster/Infostuttering/Paradigmparalysis.html

Liberal and overly selfconfident use of the word
paradigm hints at entrenchment within one, not the capability
of distinguishing the boundaries, their nature and how to
deal with them.

> Grouping one set of tools together and calling it "relational",
> another set "object oriented", and another set "functional" 
> is useful to identify those that complement each other, 
> but it's important to realize that those sets are not disjoint.
> It's also important to realize that the tools in each set 
> complement each other _in a particular context_.  In a
> different context, that is, a different problem or solution domain,
> different sets of tools may make sense.

Agreed. A consequence of this position is, though,
that it becomes crucial to recognize contexts,
particularity of situations and the divides between them.

>      There are more things in heaven and earth, mAsterdam, than are
> dreamt of in your paradigms.

Queerer than we can suppose: 
http://video.google.com/videoplay?docid=6308228560462155344


--
What you see depends on where you stand.
0
mAsterdam (155)
2/10/2008 2:34:17 PM
"David Cressey" <cressey73@verizon.net> writes:
> "Patrick May" <pjm@spe.com> wrote in message news:m2sl01sawh.fsf@spe.com...
>> mAsterdam <mAsterdam@vrijdag.org> writes:
>> > Patrick May wrote:
>> >>      I prefer to work with people who understand procedural,
>> >> relational, OO, and functional programming.  The boundaries between
>> >> these paradigms are not sharp -- useful techniques span paradigms.
>> >> Ultimately I'm looking for a gestalt development environment that
>> >> leverages the benefits of the superset of these techniques to
>> >> deliver high quality software.  That's the real goal, after all.
>> >
>> > That is stricly one side of the fence - it is the goal for a
>> > software development process.  The goal for a DB is to serve as a
>> > vehicle to manage data.
>>
>>      I disagree.  Software is a means to an end, not an end in itself,
>> at least in the vast majority of commercial settings.  Databases are
>> just one type of software.
>
> I would have said "DBMSes are just one type of software."  Is that
> what you meant?

     Clarification accepted, thank you.

> I agree with much of your major point, by the way.

     As all right thinking people must.  ;-)

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/10/2008 2:58:25 PM
mAsterdam <mAsterdam@vrijdag.org> writes:
> Patrick May wrote:
>> Databases are just one type of software.  
>
> Conflating database and the software supporting it, DBMS.

     Definitely sloppy wording on my part, clarified elsethread.

>> I use multiple paradigms as the situation warrants and I work with
>> a number of people who do as well. They're all just different
>> tools, each with advantages and disadvantages.
>
> http://en.wikipedia.org/wiki/Paradigm currently says:
> "Kuhn defines a scientific paradigm as:
>
>     * what is to be observed and scrutinized
>     * the kind of questions that are supposed to be asked and
>       probed for answers in relation to this subject
>     * how these questions are to be structured
>     * how the results of scientific investigations should be
>       interpreted",
> and there is a link to a nice article:
> http://www.mnsu.edu/comdis/kuster/Infostuttering/Paradigmparalysis.html
>
> Liberal and overly selfconfident use of the word paradigm hints at
> entrenchment within one, not the capability of distinguishing the
> boundaries, their nature and how to deal with them.

     The word "paradigm" has evolved to have a less rigorous meaning
within software.  I actually don't like the term thus applied, but I
was using it in the canonical sense for this context.

>> Grouping one set of tools together and calling it "relational",
>> another set "object oriented", and another set "functional" is
>> useful to identify those that complement each other, but it's
>> important to realize that those sets are not disjoint.  It's also
>> important to realize that the tools in each set complement each
>> other _in a particular context_.  In a different context, that is,
>> a different problem or solution domain, different sets of tools may
>> make sense.
>
> Agreed. A consequence of this position is, though, that it becomes
> crucial to recognize contexts, particularity of situations and the
> divides between them.

     No argument here.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/10/2008 3:11:24 PM
frebe <frebe73@gmail.com> writes:
> On 10 Feb, 00:18, Patrick May <p...@spe.com> wrote:
>> >>      Denormalization for performance of a particular application
>> >> is a perfectly valid example.
>>
>> > Unless your database supports materialized views.
>>
>>      And if your application can accept that the data in those
>> views may be out of date.
>
> Unless you do "refresh on commit".

     That still leaves a window during which the data can be out of
date.  It also imposes certain performance costs that may or may not
be acceptable.

> Having a denormalized schema is also a good way of introducing data
> that is out of date.

     How so?  Regardless of the normalization of the schema,
operations should be ACID.

>>      With a single application database, distributed applications
>> demonstrate additional trivial scenarios.  A new service or agent
>> might need data that is not of interest to existing services and
>> agents.
>
> The reason why the schema change is that the behavior
> change. Behavior and schema doesn't change for different reasons.

     As I pointed out, even with a database used only by a single,
albeit distributed, application, there are reasons for the schema to
change that do not require existing behaviors to change.  Similarly,
there are behavior changes that do not impact the schema.  This is
even more prevalent in databases used by multiple applications.

>> >> > O/R mapping is not the best way of mixing together DB and OOP.
>>
>> >>      What alternative do you recommend?
>>
>> > My recommendation is that if you already are using a database,
>> > you should not use objects as data structures. That is job is
>> > supposed to be done by the database.
>>
>>      So your answer to the question "How do I mix OO and
>> relational?"  is "Don't use OO."  Succinct, but not particularly
>> responsive.
>
> I didn't say that. Like I said before, classes may perfectly well be
> used for defining types for relational attributes. Objects map to
> attribute values, not to relations.

     Do you have a reference to this technique being used in practice?
I'd need to see the details to understand what you mean.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/10/2008 3:19:49 PM
> >> >> =A0 =A0 =A0Denormalization for performance of a particular applicati=
on
> >> >> is a perfectly valid example.
>
> >> > Unless your database supports materialized views.
>
> >> =A0 =A0 =A0And if your application can accept that the data in those
> >> views may be out of date.
>
> > Unless you do "refresh on commit".
>
> =A0 =A0 =A0That still leaves a window during which the data can be out of
> date. =A0It also imposes certain performance costs that may or may not
> be acceptable.

Doesn't "refresh on commit", refresh the materialized view within the
transaction?

Having redundant data may also impose certain performance costs that
may or may not be acceptable.

> > Having a denormalized schema is also a good way of introducing data
> > that is out of date.
>
> =A0 =A0 =A0How so? =A0Regardless of the normalization of the schema,
> operations should be ACID.

But it is up to the application programmer to make it ACID. Like you
said you might have other less well-written application accessing the
same schema, introducing update abnormalities. Database normalization
has many benifits. Denormalization has many disadvantages.

> >> =A0 =A0 =A0With a single application database, distributed applications=

> >> demonstrate additional trivial scenarios. =A0A new service or agent
> >> might need data that is not of interest to existing services and
> >> agents.
>
> > The reason why the schema change is that the behavior
> > change. Behavior and schema doesn't change for different reasons.
>
> =A0 =A0 =A0As I pointed out, even with a database used only by a single,
> albeit distributed, application, there are reasons for the schema to
> change that do not require existing behaviors to change. =A0

Then it wouldn't be any problem for you to give some examples.

> Similarly, there are behavior changes that do not impact the schema. =A0

I don't think we have a disagreement about this one.

> >> >> > O/R mapping is not the best way of mixing together DB and OOP.
>
> >> >> =A0 =A0 =A0What alternative do you recommend?
>
> >> > My recommendation is that if you already are using a database,
> >> > you should not use objects as data structures. That is job is
> >> > supposed to be done by the database.
>
> >> =A0 =A0 =A0So your answer to the question "How do I mix OO and
> >> relational?" =A0is "Don't use OO." =A0Succinct, but not particularly
> >> responsive.
>
> > I didn't say that. Like I said before, classes may perfectly well be
> > used for defining types for relational attributes. Objects map to
> > attribute values, not to relations.
>
> =A0 =A0 =A0Do you have a reference to this technique being used in practic=
e?
> I'd need to see the details to understand what you mean.

What part didn't you understand? Every relational attribute (table
colum) has a type (domain). Classes are suitable for defining types.
Examples of relational attributes are dates, telephon numbers, zip
codes, images, audio clips. But entities like customer, employee,
invoice, are not good candidates for classes, if you are using the
relational model.

//frebe
0
frebe73 (444)
2/10/2008 3:48:55 PM
Dmitry A. Kazakov wrote:
> mAsterdam wrote:
>> Dmitry A. Kazakov wrote:
>>> mAsterdam wrote:
>>>> Dmitry A. Kazakov wrote:
>>>>> mAsterdam wrote:
>>>>>> Leslie Sanford wrote:
>>>>>>
>>>>>>> Newsgroups: comp.object, comp.databases.theory
>>>>>>> I cringe every time I see a thread crossposted to these two groups.
>>>>>>> Good seldomn comes of it. 
>>>>>> Do you have an explanation for that?
>>>>>>
>>>>>> Any ideas except 'the other guys are so stupid'?
>>>>> Market. Both OO and RDB are technologies with market products on sale.
>>>> Let's see if I can play with this using a metaphore.
>>>>
>>>> So are, say, ships and engines (technologies with market products on
>>>> sale). Both have their own laws.
>>>> Designing a motorized boat requires a shared understanding
>>>> of some of them. There is a market for sailing boats,
>>>> there is a market for engines wchich can be used in other things than 
>>>> ships. In this thread, we /are/ mixing. Shouldn't there be a market 
>>>> for motorizing boats and for engines fit for use on a ship?
>>> Ship and engine design are a proper engineering activities, while "software
>>> engineering" is not. Exaggerating a lot, we could compare it with religions
>>> and their "market products." Certainly a god is more worth if there is no
>>> any other...
>> Metaphores only go so far. However, if you are extending it to
>> religion just to illustrate the depth of the divide and the
>> presence of the unknown, there is no need to do so.
>> No shipwright knows all there is to know about ships,
>> even about the ones of his own design.
>> Engines have come a long enough way to have that as well.
> 
> So software engineering will do in the future. But presently there is no
> hundreds of years behind us. 

What matters here is: does the engineer know everythying there is to 
know about his product? The answer is no - wether the product
is a ship, an engine, a database or a piece of software.

> Consider, year 2000 B.C., a discussion about
> merits of whips against clubs for slave management. 

Yet another extension to the metaphore - you think it isn't
rich enough?

> Surely slave management
> is fundamental for ships propelling, slaves have to be arranged in rows,
> etc...

In your extension, you appear to map your slaves to data.
Slaves behave, objects do. Data doesn't.

>>> All technical disciplines are based on natural sciences which provide a
>>> common ground for an interdisciplinary communication. This is not the case
>>> for either OO or RDB. They not only compete in selling, often snake oil,
>>> which questions whether they indeed are different disciplines, as your
>>> example suggests. 
>> It does indeed. If studying OO and DB are not
>> different disciplines then their whole ground is common.
>> What is left is dogma, groupthink and language.
>> Does that explain the whole of the divide?
> 
> Yes, because the common ground is not understood and not even articulated.

All ground is common. This, like Patrick May's stance,
invalidates the OP's question.

> When in a subthread Patrick May wrote about the goals of software design
> (quality), you disagreed. 

That is not what I disagreed with.
This is a serious misrepresentation.
You can read. Is it intentional?

> In your metaphor, he just said that a ship should
> float. You replied that it is not about ships. 

Maybe you just misread it, maybe I said something in an unclear way.
Please quote the passage you are hinting at.

> How can we discuss means
> when there is no agreement on what we are going to achieve?
> 
> Anybody on my side of the fence
Please describe the fence as seen from your side.

> would say that DB is merely a software. 
> But that is a consequence of an even more heretical concept that data is
> a fiction, a product of some language. (So any distinction between DB
> and DBMS is also fictional.) 

All models, all concepts are fictional, but we are
talking about shared fictions here, so that filosofical
insight does not help us here.
I see the same DB/DBMS conflation as Patrick made.
I asked Patrick, and I'm asking you:
Do you need that?

> This is what divides us, not engineering techniques.
> 
>> Table manners can be quite offensive.
> 
> from food's point of view...

You like rapid topic shifts?




--
What you see depends on where you stand.
0
mAsterdam (155)
2/10/2008 3:52:00 PM
Patrick May wrote:
> mAsterdam writes:
>> Patrick May wrote:
>>> Databases are just one type of software.  
>> Conflating database and the software supporting it, DBMS.
> 
>      Definitely sloppy wording on my part, clarified elsethread.

Ok.

For the sake of discussion I'd prefer it if you would alert snips.

<unsnip>
>> Is data a business asset in your view? 
</unsnip>

[snip prelude]

> The word "paradigm" has evolved to have a less rigorous meaning
> within software.  I actually don't like the term thus applied, but I
> was using it in the canonical sense for this context.

Ok.

[snip agreement]
0
mAsterdam (155)
2/10/2008 4:02:04 PM
On Sun, 10 Feb 2008 16:52:00 +0100, mAsterdam wrote:

> In your extension, you appear to map your slaves to data.
> Slaves behave, objects do. Data doesn't.

If data did not behave how would it be possible to use data?

[What is data, in your opinion? On my side: data are values semantically
bound to some entities from the problem space. (The type of values
describes the behavior of data.)]

>> Yes, because the common ground is not understood and not even articulated.
> 
> All ground is common. This, like Patrick May's stance,
> invalidates the OP's question.

Yes.

>> When in a subthread Patrick May wrote about the goals of software design
>> (quality), you disagreed. 
> 
> That is not what I disagreed with.

So you agree that software design could be such a ground?

>> In your metaphor, he just said that a ship should
>> float. You replied that it is not about ships. 
> 
> Maybe you just misread it, maybe I said something in an unclear way.
> Please quote the passage you are hinting at.

"That is stricly one side of the fence - it is the goal for a software
development process. The goal for a DB is to serve as a vehicle to manage
data."

If the ultimate goal is same, then managing the thing called data is mere
one possible thread of the process.

> Please describe the fence as seen from your side.

In short and technically, it is refusal to view tables as typed values.

> I see the same DB/DBMS conflation as Patrick made.
> I asked Patrick, and I'm asking you:
> Do you need that?

Yes, I do, especially when talking about a common ground.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/10/2008 5:45:43 PM
On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 10 Feb 2008 16:52:00 +0100, mAsterdam wrote:
> > In your extension, you appear to map your slaves to data.
> > Slaves behave, objects do. Data doesn't.
>
> If data did not behave how would it be possible to use data?
>
> [What is data, in your opinion?

Data. Lots of datum - from latin, meaning statement of fact. Predicate
and value in FOL.  A value without description is of course just
noise.

> On my side: data are values semantically bound

"Semantically bound"? yuck, I think you need to break that down to
brass tacks.

> to some entities from the problem space. (The type of values describes the behavior of data.)]

Entities feature in or are extracted from data, not the other way
around.  Data is certainly not "bound to" entities, which is hand wavy
terminology at best. My concern for OO is not that its mechanisms are
not useful, but that it gives objects primacy before data, instead of
the other way around as per the definition of the term.

Entities don't store data. Rather, observed data allows us to
formulate entities.

>
> >> Yes, because the common ground is not understood and not even articulated.
>
> > All ground is common. This, like Patrick May's stance,
> > invalidates the OP's question.
>
> Yes.
>
> >> When in a subthread Patrick May wrote about the goals of software design
> >> (quality), you disagreed.
>
> > That is not what I disagreed with.
>
> So you agree that software design could be such a ground?
>
> >> In your metaphor, he just said that a ship should
> >> float. You replied that it is not about ships.
>
> > Maybe you just misread it, maybe I said something in an unclear way.
> > Please quote the passage you are hinting at.
>
> "That is stricly one side of the fence - it is the goal for a software
> development process. The goal for a DB is to serve as a vehicle to manage
> data."
>
> If the ultimate goal is same, then managing the thing called data is mere
> one possible thread of the process.
>
> > Please describe the fence as seen from your side.
>
> In short and technically, it is refusal to view tables as typed values.
>
> > I see the same DB/DBMS conflation as Patrick made.
> > I asked Patrick, and I'm asking you:
> > Do you need that?
>
> Yes, I do, especially when talking about a common ground.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

0
jog (83)
2/10/2008 6:29:58 PM
On Sun, 10 Feb 2008 10:29:58 -0800 (PST), JOG wrote:

> On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Sun, 10 Feb 2008 16:52:00 +0100, mAsterdam wrote:
>>> In your extension, you appear to map your slaves to data.
>>> Slaves behave, objects do. Data doesn't.
>>
>> If data did not behave how would it be possible to use data?
>>
>> [What is data, in your opinion?
> 
> Data. Lots of datum - from latin, meaning statement of fact. Predicate
> and value in FOL.  A value without description is of course just
> noise.

"Fact" in which domain? Or maybe you simply mean that data is a set of
statements in some formal language, without any particular meaning. Then
those aren't facts, but mere a program.

>> On my side: data are values semantically bound
> 
> "Semantically bound"? yuck, I think you need to break that down to
> brass tacks.

Sure. After you have applied inference rules to the bunch of statements
called data, you get another bunch of statements which has as little sense
as the former had, unless there is a meaning attached to. This meaning
necessary lies outside the formal system.

>> to some entities from the problem space. (The type of values describes the behavior of data.)]
> 
> Entities feature in or are extracted from data, not the other way
> around.

Entities extracted from data? Cool, if I only could extract warmth from 22
degrees Celsius, that would reduce my energy bills!

> My concern for OO is not that its mechanisms are
> not useful, but that it gives objects primacy before data, instead of
> the other way around as per the definition of the term.

(There is no any primacy as data just do not exist alone.) But returning to
the question about fences, if OO mechanisms are useful, what is wrong with
using them? What prevents you from talking about mechanisms rather than
pushing [dubious] philosophical agenda?
 
> Entities don't store data. Rather, observed data allows us to
> formulate entities.

I cannot decipher that. When I referred to entities I meant ones in the
problem space. "Observing data," makes me think that you believe in data
physically existing in the real world. I never saw the number 123 out
there, maybe I should work less, and more frequently look out of the window
in order to spot it...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/10/2008 7:50:40 PM
frebe <frebe73@gmail.com> writes:
>> >> >>      Denormalization for performance of a particular
>> >> >> application is a perfectly valid example.
>>
>> >> > Unless your database supports materialized views.
>>
>> >>      And if your application can accept that the data in those
>> >> views may be out of date.
>>
>> > Unless you do "refresh on commit".
>>
>>      That still leaves a window during which the data can be out of
>> date.  It also imposes certain performance costs that may or may
>> not be acceptable.
>
> Doesn't "refresh on commit", refresh the materialized view within
> the transaction?

     That's one possible semantic.  Another is to update post-commit,
in order to minimize the performance impact of materialized views on
the underlying schema.

> Having redundant data may also impose certain performance costs that
> may or may not be acceptable.

     Certainly, but denormalization for performance is a relatively
common technique.  It does provide value in some environments.

>> > Having a denormalized schema is also a good way of introducing
>> > data that is out of date.
>>
>>      How so?  Regardless of the normalization of the schema,
>> operations should be ACID.
>
> But it is up to the application programmer to make it ACID. Like you
> said you might have other less well-written application accessing
> the same schema, introducing update abnormalities. Database
> normalization has many benifits. Denormalization has many
> disadvantages.

     Normalization is certainly to be preferred, but the benefits of
it must be balanced against its costs.

>> >>      With a single application database, distributed
>> >> applications demonstrate additional trivial scenarios.  A new
>> >> service or agent might need data that is not of interest to
>> >> existing services and agents.
>>
>> > The reason why the schema change is that the behavior
>> > change. Behavior and schema doesn't change for different reasons.
>>
>>      As I pointed out, even with a database used only by a single,
>> albeit distributed, application, there are reasons for the schema
>> to change that do not require existing behaviors to change.
>
> Then it wouldn't be any problem for you to give some examples.

     I've already done so.  Denormalization for performance.  Addition
of new functionality.  We could add refactoring to take advantage of
new (or existing but unused) functionality of the RDBMS.  Support for
additional reports (a subset of addition of new functionality).

     I'm not sure where you're going with this.  What point are you
trying to make?

>> >>      So your answer to the question "How do I mix OO and
>> >> relational?"  is "Don't use OO."  Succinct, but not particularly
>> >> responsive.
>>
>> > I didn't say that. Like I said before, classes may perfectly well
>> > be used for defining types for relational attributes. Objects map
>> > to attribute values, not to relations.
>>
>>      Do you have a reference to this technique being used in
>> practice?  I'd need to see the details to understand what you mean.
>
> What part didn't you understand? Every relational attribute (table
> colum) has a type (domain). Classes are suitable for defining types.
> Examples of relational attributes are dates, telephon numbers, zip
> codes, images, audio clips. But entities like customer, employee,
> invoice, are not good candidates for classes, if you are using the
> relational model.

     That ignores the fact that OO is about implementing behavior.  In
many systems there is no need for the relational model, except as an
interface to other systems that happen to be database centric.

     Can you provide an example of an RDBMS that integrates with
classes as you describe?

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/10/2008 9:29:35 PM
On Feb 10, 7:50 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 10 Feb 2008 10:29:58 -0800 (PST), JOG wrote:
> > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Sun, 10 Feb 2008 16:52:00 +0100, mAsterdam wrote:
> >>> In your extension, you appear to map your slaves to data.
> >>> Slaves behave, objects do. Data doesn't.
>
> >> If data did not behave how would it be possible to use data?
>
> >> [What is data, in your opinion?
>
> > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > and value in FOL.  A value without description is of course just
> > noise.
>
> "Fact" in which domain? Or maybe you simply mean that data is a set of
> statements in some formal language, without any particular meaning. Then
> those aren't facts, but mere a program.

Fact, as in... "statement of fact". As in a true proposition. That's
it. Nothing else.

Let's cut the blather, it's not necessary.

>
> >> On my side: data are values semantically bound
>
> > "Semantically bound"? yuck, I think you need to break that down to
> > brass tacks.
>
> Sure. After you have applied inference rules to the bunch of statements
> called data, you get another bunch of statements which has as little sense
> as the former had, unless there is a meaning attached to. This meaning
> necessary lies outside the formal system.

Fair enough, that makes sense.

>
> >> to some entities from the problem space. (The type of values describes the behavior of data.)]
>
> > Entities feature in or are extracted from data, not the other way
> > around.
>
> Entities extracted from data? Cool, if I only could extract warmth from 22
> degrees Celsius, that would reduce my energy bills!

Yes, and whatever other sentences you want to type in that don't make
sense, you fill your boots.

>
> > My concern for OO is not that its mechanisms are
> > not useful, but that it gives objects primacy before data, instead of
> > the other way around as per the definition of the term.
>
> (There is no any primacy as data just do not exist alone.)

There is no need to pluralize data. It has long been acceptable to use
the term in the singular.

> But returning to
> the question about fences, if OO mechanisms are useful, what is wrong with
> using them?

They bind you into a single brittle conceptual model, as opposed to
offering a neutral logical model from which different conceptual
models may be extracted. Lordy, why am I bothering? You aren't
interested in expanding your knowledge are you?

> What prevents you from talking about mechanisms rather than
> pushing [dubious] philosophical agenda?

Blah, blah. I have no agenda apart from building good systems. I use
both OO and RM, and understand the strength and weaknesses of both. I
gave you a definition of data, but you're gonna have to google the
difference between conceptual and logical models.

>
> > Entities don't store data. Rather, observed data allows us to
> > formulate entities.
>
> I cannot decipher that. When I referred to entities I meant ones in the
> problem space. "Observing data," makes me think that you believe in data
> physically existing in the real world. I never saw the number 123 out
> there, maybe I should work less, and more frequently look out of the window
> in order to spot it...

You "never saw the value '123' out there"  in the real world? Good
grief. You've not seen a phone number written down either then, or a
room number, or heard of lotus 123? Right you are then.

Look I'm rapidly becoming aware that your responses are incoherent,
and as such are almost impossible to respond to sensibly. Perhaps
someone from comp.object can let me know if you normally offer any
salient points and there is merely a language issue at hand here, or
whether I'm wasting my time. There is no point in my posting again
until then.

>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

0
jog (83)
2/10/2008 10:30:44 PM
Dmitry A. Kazakov wrote:
> mAsterdam wrote:
> 
>> In your extension, you appear to map your slaves to data.
>> Slaves behave, objects do. Data doesn't.
> 
> If data did not behave how would it be possible to use data?

Being active is not, as your question presupposes,
a prerequisite to being used.

> [What is data, in your opinion? 

Recorded facts.

In the context of electronic dataprocessing
it only makes sense to talk about data when the medium on
which they are recorded is readable by some mechanism to
achieve electronic representation, but that is not inherent
to data.

> On my side: data are values semantically
> bound to some entities from the problem space. 

The one recording the facts (or the designer of the datacapture)
will have some entities in mind when recording/capturing the data.
To make sure that the interpretation won't be far off, a
description in terms of entities (from the problem space) helps.

This does not garantee that the interpretation in terms of entities
of formerly collected facts will stay the same.

"semantically bound" suggests a formalism.
Did you intend that? If so which one?

> (The type of values describes the behavior of data.)]

How? I don't understand what you are saying here -
this may be a language thing, though.
An example might clarify.

>>> Yes, because the common ground is not understood and not even articulated.
>> All ground is common. This, like Patrick May's stance,
>> invalidates the OP's question.
> 
> Yes.
> 
>>> When in a subthread Patrick May wrote about the goals of software design
>>> (quality), you disagreed. 
>> That is not what I disagreed with.
> 
> So you agree that software design could be such a ground?

It is not clear what you are asking me to agree to.

>>> In your metaphor, he just said that a ship should
>>> float. You replied that it is not about ships. 
>> Maybe you just misread it, maybe I said something in an unclear way.
>> Please quote the passage you are hinting at.
> 
> "That is stricly one side of the fence - it is the goal for a software
> development process. The goal for a DB is to serve as a vehicle to manage
> data."

I do not see how you can read this as:
"In your metaphor, he just said that a ship should
float. You replied that it is not about ships."

Please state your own opinions.
You are not doing a good job stating mine.

> If the ultimate goal is same, then managing the thing called data is mere
> one possible thread of the process.

That does not follow.
Furthermore: after the process stops, the data remains.

>> Please describe the fence as seen from your side.
> 
> In short and technically, it is refusal to view tables as typed values.
> 
>> I see the same DB/DBMS conflation as Patrick made.
>> I asked Patrick, and I'm asking you:
>> Do you need that?
> 
> Yes, I do, especially when talking about a common ground.

Patrick May considered his DB/DBMS conflation just sloppy,
you need it. Please elaborate.

Up to now your arguments do not yet
step outside the 'the other guys are so stupid' box.
Are you planning to? I specifically asked to skip those.

--
What you see depends on where you stand.
0
mAsterdam (155)
2/11/2008 12:52:48 AM
JOG schreef:
> Dmitry A. Kazakov wrote:
[snip]
>> [What is data, in your opinion?
> 
> Data. Lots of datum - from latin, meaning statement of fact. Predicate
> and value in FOL.  A value without description is of course just
> noise.
Yep.

[snip]
> My concern for OO is not that its mechanisms are
> not useful, but that it gives objects primacy before data, instead of
> the other way around as per the definition of the term.

This smells like 'the other guys are so stupid'.


--
What you see depends on where you stand.
0
mAsterdam (155)
2/11/2008 1:19:32 AM
On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
> On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:

> > [What is data, in your opinion?
>
> Data. Lots of datum - from latin, meaning statement of fact. Predicate
> and value in FOL.  A value without description is of course just
> noise.

Latin datum is past participle of dare, "to give".  What make you say
data is necessarily a set of propositions?  Are you suggesting a value
is meaningless without a proposition?  Why can't a datum just be a
value?  Wouldn't you say a recorded image is data?
0
davidbl (206)
2/11/2008 2:05:47 AM
On Mon, 11 Feb 2008 01:52:48 +0100, mAsterdam wrote:

> Dmitry A. Kazakov wrote:
>> mAsterdam wrote:
>> 
>>> In your extension, you appear to map your slaves to data.
>>> Slaves behave, objects do. Data doesn't.
>> 
>> If data did not behave how would it be possible to use data?
> 
> Being active is not, as your question presupposes,
> a prerequisite to being used.

No, I didn't meant that. Behavior is independent on who acts on whom.
Consider it as a list of all things you could ever do with data.

>> [What is data, in your opinion? 
> 
> Recorded facts.
> 
> In the context of electronic dataprocessing
> it only makes sense to talk about data when the medium on
> which they are recorded is readable by some mechanism to
> achieve electronic representation, but that is not inherent
> to data.

True. Inherent is presence of some reading device.

But why is recording essential? It throws in many things which seem
unrelated or constraining, such as time aspect and physical presence. Or to
put it otherwise, can you consider unrecorded, not memorized data? May I
translate data into a different representation and then erase the original
record? Will data still be there?

>> On my side: data are values semantically
>> bound to some entities from the problem space. 
> 
> The one recording the facts (or the designer of the datacapture)
> will have some entities in mind when recording/capturing the data.
> To make sure that the interpretation won't be far off, a
> description in terms of entities (from the problem space) helps.
> 
> This does not garantee that the interpretation in terms of entities
> of formerly collected facts will stay the same.

Yes. That cannot be guaranteed.

> "semantically bound" suggests a formalism.
> Did you intend that? If so which one?

Actually it suggests absence of formalism. A formal system operates on data
without any clue of the meaning of.

>> (The type of values describes the behavior of data.)]
> 
> How? I don't understand what you are saying here -
> this may be a language thing, though.
> An example might clarify.

Consider the value 1. It has no behavior (and no use) so long you don't
tell us its type. It you say that 1 is an integer, then its behavior will
include "has negative inverse." If the type is Positive, then the behavior
will be "no negative inverse", "can be squared in R" etc.

(Behavior does not presume anything like tiny cogwheels hidden inside 1.
The cogwheels are rather big and all outside (:-))

>> If the ultimate goal is same, then managing the thing called data is mere
>> one possible thread of the process.
> 
> That does not follow.
> Furthermore: after the process stops, the data remains.

Really? You wrote just above:

"it only makes sense to talk about data when the medium on
which they are recorded is readable by some mechanism to
achieve electronic representation, but that is not inherent
to data."

Which is all true. So let you have a medium without a process that can read
it, what did remain of data? It what sense do data remain? As a possibility
to start a process by some other process which still runs? Consider it on
the example with 1.

>>> Please describe the fence as seen from your side.
>> 
>> In short and technically, it is refusal to view tables as typed values.
>> 
>>> I see the same DB/DBMS conflation as Patrick made.
>>> I asked Patrick, and I'm asking you:
>>> Do you need that?
>> 
>> Yes, I do, especially when talking about a common ground.
> 
> Patrick May considered his DB/DBMS conflation just sloppy,
> you need it.

No, his first, maybe unconscious, reaction was right. DB in interesting to
us part is software, or else we should have been in sci.physics.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/11/2008 9:21:39 AM
Victor Porton schrieb:
> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?
> 
> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.
> 
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?

Here is a short paper describing one possible approach to this problem:

Informal Introduction into the Concept-Oriented Programming:
http://conceptoriented.com/papers/CopInformalIntroduction.html

The paper is aimed at formulating main principles of the 
concept-oriented programming but section 8 gives a general idea what the 
concept-oriented data model is.

Some discussion can be found here:
http://www.theserverside.com/news/thread.tss?thread_id=47699
0
spam3404 (19)
2/11/2008 10:56:13 AM
On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
> On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> > > [What is data, in your opinion?
>
> > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > and value in FOL.  A value without description is of course just
> > noise.
>
> Latin datum is past participle of dare, "to give".  What make you say
> data is necessarily a set of propositions?

The OED. "Facts, esp. numerical facts, collected together for
reference or information." The etymology stems from 'dare', because
facts are always communicated or "given". I understand of course that
the term is thrown around wantonly and ambiguosly nowadays, but as
data theorists, we shouldn't be party to that imo ;)

> Are you suggesting a value
> is meaningless without a proposition?  Why can't a datum just be a
> value?

Because ta value has to be associated with something. Hofstadter gave
a good example of this with the groove modulations on a vinyl record.
To us they are (musical) data, to an alien not knowing their context,
it is not. You need the context.

> Wouldn't you say a recorded image is data?

Of course, so long as I know it's an image. If its just ones and
zero's stored in a computer, without anyway of telling they represent
a picture, then it is simply noise.

0
jog (83)
2/11/2008 11:07:28 AM
On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
> On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > wrote:
> > > > [What is data, in your opinion?
>
> > > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > > and value in FOL.  A value without description is of course just
> > > noise.
>
> > Latin datum is past participle of dare, "to give".  What make you say
> > data is necessarily a set of propositions?
>
> The OED. "Facts, esp. numerical facts, collected together for
> reference or information." The etymology stems from 'dare', because
> facts are always communicated or "given". I understand of course that
> the term is thrown around wantonly and ambiguosly nowadays, but as
> data theorists, we shouldn't be party to that imo ;)

> > Are you suggesting a value
> > is meaningless without a proposition?  Why can't a datum just be a
> > value?
>
> Because ta value has to be associated with something. Hofstadter gave
> a good example of this with the groove modulations on a vinyl record.
> To us they are (musical) data, to an alien not knowing their context,
> it is not. You need the context.
>
> > Wouldn't you say a recorded image is data?
>
> Of course, so long as I know it's an image. If its just ones and
> zero's stored in a computer, without anyway of telling they represent
> a picture, then it is simply noise.

Let's indeed assume we know how to interpret the 1's and 0's as an
image.  So what have we got?  Nothing but a *value*.  We can display
it.  We can comment on whether we like it - even if we haven't a clue
where it came from.  But I don't see any sense in which the image
value gives us any statements of fact beyond the specification of a
value.  A value simply "is".

I would suggest that a lot of the data in the world is characterised
more closely as "interesting values" than collections of
propositions.  For example a recorded poem is an interesting value.
So also a movie, mp3, book, web page or source code listing.

0
davidbl (206)
2/11/2008 12:44:22 PM
On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
> On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
>
>
> > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > > wrote:
> > > > > [What is data, in your opinion?
>
> > > > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > > > and value in FOL.  A value without description is of course just
> > > > noise.
>
> > > Latin datum is past participle of dare, "to give".  What make you say
> > > data is necessarily a set of propositions?
>
> > The OED. "Facts, esp. numerical facts, collected together for
> > reference or information." The etymology stems from 'dare', because
> > facts are always communicated or "given". I understand of course that
> > the term is thrown around wantonly and ambiguosly nowadays, but as
> > data theorists, we shouldn't be party to that imo ;)
> > > Are you suggesting a value
> > > is meaningless without a proposition?  Why can't a datum just be a
> > > value?
>
> > Because ta value has to be associated with something. Hofstadter gave
> > a good example of this with the groove modulations on a vinyl record.
> > To us they are (musical) data, to an alien not knowing their context,
> > it is not. You need the context.
>
> > > Wouldn't you say a recorded image is data?
>
> > Of course, so long as I know it's an image. If its just ones and
> > zero's stored in a computer, without anyway of telling they represent
> > a picture, then it is simply noise.
>
> Let's indeed assume we know how to interpret the 1's and 0's as an
> image.  So what have we got?  Nothing but a *value*.

No, you now have a value with applied context. That creates a fact.
You now therefore have data. It's simple to show - consider "1000001".
Thats currently a value, but its not data. Its only data when I store
it, and state one of the following:

"100001" is a text string
"100001" is an integer (i.e. 65)
"100001" is an ascii character (i.e. A)
etc..

> We can display
> it.  We can comment on whether we like it - even if we haven't a clue
> where it came from.  But I don't see any sense in which the image
> value gives us any statements of fact beyond the specification of a
> value.  A value simply "is".
>
> I would suggest that a lot of the data in the world is characterised
> more closely as "interesting values" than collections of
> propositions.

You cannot store these interesting values without implicitly stating
some fact about them.

>  For example a recorded poem is an interesting value.
> So also a movie, mp3, book, web page or source code listing.



0
jog (83)
2/11/2008 2:08:30 PM
On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
> On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>
>
>
>
>
> > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > > > wrote:
> > > > > > [What is data, in your opinion?
>
> > > > > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > > > > and value in FOL.  A value without description is of course just
> > > > > noise.
>
> > > > Latin datum is past participle of dare, "to give".  What make you say
> > > > data is necessarily a set of propositions?
>
> > > The OED. "Facts, esp. numerical facts, collected together for
> > > reference or information." The etymology stems from 'dare', because
> > > facts are always communicated or "given". I understand of course that
> > > the term is thrown around wantonly and ambiguosly nowadays, but as
> > > data theorists, we shouldn't be party to that imo ;)
> > > > Are you suggesting a value
> > > > is meaningless without a proposition?  Why can't a datum just be a
> > > > value?
>
> > > Because ta value has to be associated with something. Hofstadter gave
> > > a good example of this with the groove modulations on a vinyl record.
> > > To us they are (musical) data, to an alien not knowing their context,
> > > it is not. You need the context.
>
> > > > Wouldn't you say a recorded image is data?
>
> > > Of course, so long as I know it's an image. If its just ones and
> > > zero's stored in a computer, without anyway of telling they represent
> > > a picture, then it is simply noise.
>
> > Let's indeed assume we know how to interpret the 1's and 0's as an
> > image.  So what have we got?  Nothing but a *value*.
>
> No, you now have a value with applied context. That creates a fact.
> You now therefore have data. It's simple to show - consider "1000001".
> Thats currently a value, but its not data. Its only data when I store
> it, and state one of the following:
>
> "100001" is a text string
> "100001" is an integer (i.e. 65)
> "100001" is an ascii character (i.e. A)
> etc..

These "facts" are all tautologies that are true whether you record
them or not.  I dispute your premise that the purpose of the data in
this case is to state a fact that is known a-priori to be true.   If
that is its purpose then it conveys precisely zero information.

> > We can display
> > it.  We can comment on whether we like it - even if we haven't a clue
> > where it came from.  But I don't see any sense in which the image
> > value gives us any statements of fact beyond the specification of a
> > value.  A value simply "is".
>
> > I would suggest that a lot of the data in the world is characterised
> > more closely as "interesting values" than collections of
> > propositions.
>
> You cannot store these interesting values without implicitly stating
> some fact about them.

By definition, when a value is specified, its type is specified as
well (except possibly if type inheritance is supported).

C. Date states the following in "Introduction to Database Systems",
section 5.2, and subsection titled "Values and Variables are typed":

    "Every value has ... some type...Note that,
    by definition, a given value always has
    exactly one type, which never changes.
    [footnote:  except possibly if type
    inheritance is supported]"

When a particular value like the integer 73 is specified, there is no
implicit fact being specified.   The statement that the integer 73
exists in any absolute sense is entirely metaphysical and meaningless
within computer science.

0
davidbl (206)
2/11/2008 4:10:53 PM
On 2008-02-07 14:35:26 -0600, Victor Porton <porton@narod.ru> said:

> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?

The concepts are orthogonal.  Objects are not tables.  Tables are not 
objects.  The many efforts to try to force tables and objects together 
always cause trouble.  Things work better when you recognize the 
benefits of tables, and the benefits of objects, and use each where 
they belong rather than try to force one to use the other.

Tables expose data and have no behavior.  Objects hide data and expose 
behavior.  These two descriptions are very nearly opposites of each 
other.  OO is a technique for organizing the dependencies between 
source code modules in order to minimize the impact of change.  DBs are 
a technique for representing data in a formal and consistent fashion.

Learn each.  Appreciate each.  Apply each.  Keep each where it belongs.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/11/2008 4:11:12 PM
On 2008-02-07 15:00:15 -0600, Tegiri Nenashi <TegiriNenashi@gmail.com> said:

> I suggest that OO ideas are too naive to continue influence
> programming.

OO is not rocket science.  It's a very simple, very pragmatic, and very 
useful technique for managing source code dependencies.  Don't try to 
make more out of it than that.  OO is not a deep philosophy, nor an all 
encompasing world view.  It's just a clever syntax for jump 
indirection, and some rules for grouping data and functions together.

In one sense I agree with you.  I think OO has had the maximum 
influence it can have.  I don't expect any more deep thoughts about OO, 
nor any further revelations about it's implications.  OO has run it's 
course and has become throroghly insinuated into our programming 
culture.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/11/2008 4:15:58 PM
Tegiri Nenashi wrote:

> On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:

SP>For me, the big problem has always been the following :

SP>SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)

SP>s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;

SP>In the OO world, the problem is that for each instance of SomeType held
SP>in Somewhere, the *implementation* of the property 'x' could be merely
SP>an actual data value, or a serious computation process. That is the ADT/OO
SP>way.

> If x is computed, then why don't you introduce a function that computes it?

We have.
A function whose implementation may be different for every instance of
Sometype that is contained by Somewhere.


> In relational world a function call is a join.

A join on what specifically ??


> If this function is not known at runtime
> then what logic is involved in selecting it?

You will have to clarify what you mean here.


> Can't the problem solved by dynamically constructing this query?

The time of query construction is irrelevant.


>>I see it different. First the above should be decomposed into primitive
>>operations over the types involved. There is at least the type of the table
>>and one of the cell. If SELECT were doubly dispatching, then one could
>>certainly provide different implementations for different combinations of
>>types.

> What is SELECT? The whole query? The projection part? You OO guys
> perfected the art speaking gibberish.

As in the SQL construct ??

Or if you prefer ... s = { e IN Somewhere : e.x = 123 }


SP>It is because of this that I believe that the only paradigm that is capable
SP>of providing the true engine for a relational info base that caters for
SP>both OO and current RDBMS, is Functional programming (data values and
SP>computation entities - functions - are treated the same, techniques such as
SP>lazy evaluation, "copy on write" behaviour etc) .

> Function is just a relation with functional dependency. It works
> pretty much like an index. When a function is called from a query, it
> is essentially a join, although there is no ambiguity which order this
> join is evaluated.

The "order" of evaluation is an *implementation* decision.


> Therefore, in principle, FP is too weak to embrace
> relational. It is more likely to happen the other way.

FP is perfectly capable of accommodating RA.
Because RA is based on mathematical concepts, as is FP.

Therefore any computable predicate expressible in RA, can be expressed in
FP.


> Relational programing has its weaknesses, but they are not what OO
> propellerheads think.

The weakness, as with all things, is in the *implementation* of the
concept. No better demonstrated than SQL for databases, and C++ for OO prog 
langs.


> One missing part in the relational is formal
> grammars and languages. The underlying theory of grammars and language
> theory is Kleene algebra which is incompatible with RA. Witness how
> regular expressions are integrated into SQL

SQL is a *specific implementation* of the relational model is it not.

There is nothing inherent in the relational model, or regexps, that prevent
the latter being defined in terms of the former (ie confirming my comment
above about implementations) .


Regards,
Steven Perryman
0
S
2/11/2008 4:30:19 PM
On 2008-02-08 11:17:54 -0600, Jan Hidders <hidders@gmail.com> said:

> They asked Bjarne Stroustrup? Why??
> 
>   "I invented the term Object-Oriented, and I can tell you I did not
> have C++ in mind."
>   - Alan Kay

I don't wish to minimize the contribution that Kay made.  It has been 
enormous.  The undercurrents he started with Smalltalk continue to 
pervade our industry, subsuming it from the bottom up.  Revolutions in 
our thought such as Design Patterns, Agile Development, Test Driven 
Development, etc, etc, can all be traced to the Smalltalk community.

Having said that, Kay did not invent OO.  He may have coined the term, 
but the concepts were invented years before by Ole Johan Dahl, and 
Kristian Nygaard in the language Simula-67.  (When they moved the 
calling frame from the stack to the heap.)

Now it happens that both Kay and Stroustrup were influenced by Simula.  
Both came to very different ends.  However, if you were to line up the 
two results and compare them to the parents, you'd find more 
similarities between Simula and C++, than between Simula and Smalltalk. 
 So it is possible to claim (though it would be naive) that Stroustrup 
remained more faithful to the orginal concept.

Stroustrup's contribution was also huge.  But whereas Kay was a 
visionary who created a subculture that has influenced our industry 
from the bottom up, Stroustrup was a pragmatist and a driver who 
changed the industry from the top down.  The evidence of this is in the 
major languages used today (Java, C#).  These languages can be very 
clearly traced to C++.  So in that sense it was Stroustrup who was 
responsible for the fact that the industry has gone OO.

The Smalltalk subculture is still alive and well; and is showing up in 
many interesting new forms.  The Ruby/Rails community can trace its 
roots directly to Smalltalk; and they are currently poised to grab a 
huge chunk of the industry.

So I think we will see these two competing ideas continue to struggle 
with each other, to the benefit of our industry.  And we can thank both 
Kay and Stroustrup for their equal and unique contributions.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/11/2008 4:38:25 PM
On 2008-02-09 04:21:08 -0600, mAsterdam <mAsterdam@vrijdag.org> said:

> Any ideas except 'the other guys are so stupid'?

Yes.  Each group thinks it understands the other.  Both are wrong.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/11/2008 4:40:15 PM
On 2008-02-10 12:29:58 -0600, JOG <jog@cs.nott.ac.uk> said:

> My concern for OO is not that its mechanisms are
> not useful, but that it gives objects primacy before data, instead of
> the other way around as per the definition of the term.

OO gives *behavior* primacy over data.  To say that a different way, OO 
source code is organized around it's behavior, not around the data 
manipulated by those behaviors.

An object is not a container of data.  An object profers behavior.  Any 
data necessary to achieve that behavior is kept hidden.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/11/2008 4:45:04 PM
On 2008-02-09 09:32:13 -0600, "Daniel T." <daniel_t@earthlink.net> said:

> In response to mAsterdam's call for a civilized discussion of the pros
> and cons of both theories, I can't say much because I only know one side
> of the argument.

The most amusing aspect of the "argument" to me is that the two 
"theories" do not compete.  There's nothing to argue about.  It's 
rather like arguing whether desert topings are better than floor waxes.

OO is a technique for organizing and decoupling source code modules.  
RDB is a technique for organizing and representing data.

So the argument goes:

"My way of organizing source code is better than your way of organizing data."

"No, you are naive, you don't understand subsets and algebraic formality."

"You are an idiot, it's about polymorphism and inheritance."

It seems to me that we'd all be a lot better off if we tried very hard 
not to get our peanut butter and chocolate mixed up.  Each has it's 
place.  Each has it's purpose.  Each has it's benefits and costs.  
Neither can replace the other.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/11/2008 4:55:52 PM
On 2008-02-09 09:35:52 -0600, Patrick May <pjm@spe.com> said:

>      I prefer to work with people who understand procedural,
> relational, OO, and functional programming.  The boundaries between
> these paradigms are not sharp -- useful techniques span paradigms.
> Ultimately I'm looking for a gestalt development environment that
> leverages the benefits of the superset of these techniques to deliver
> high quality software.  That's the real goal, after all.

Well said.

It is true that the boundaries can be indistinct; but this happens 
because it is *possible* to specify data within objects; and it is 
*possible* to specify behavior within SQL.

I have consulted for shops in which the DBAs took total control over 
the business rules, reducing the programmers to little more than GUI 
form jockeys.  I have also consulted for shops in which the programmers 
took total control over all the data access, reducing the DBAs to 
little more than DDL clerks.   Neither extreme is appropriate.

There is a place for stored procedures, just as there is a place for 
serialized objects in flat files.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/11/2008 5:01:13 PM
On 2008-02-09 13:37:47 -0600, topmind <topmind@technologist.com> said:

> The problem with paradigm-potpourri is that its more expensive to hire
> people who have sufficient experience in them all. The industry tends
> to force programmers into managers or unemployment after about 15
> years, and 15 years is not enough for most programmers to master that
> many paradigms. And, I don't think the benefits of mixing is strong
> enough to offset that either.

Congratulations Bryce!  THAT was an intelligent point.

You and I come to very different conclusions about it though.  For my 
money, I think we should encourage programmers to mature in their craft 
and become multi-paradigm specialists.  I don't think it's wise to 
throw a bunch of 20somethings into the paradigm mold and try to get 
everything done with the clones that come out.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/11/2008 5:03:48 PM
On 2008-02-09 23:58:27 -0600, topmind <topmind@technologist.com> said:

> But OOP and relational often don't compliment each other, but instead
> fight over territory. Unless clear and logical rules form that tell us
> when to stop one and start the other, this problem is not small.

ANOTHER INTELLIGENT POINT BY BRYCE!  That's two in one day!

I agree, there is conflict at the borders.

Do we create a stored procedure to calculate the pay of the employee?  
Or should we query for the data and write a suite of algorithms in Java?

Which you choose depends on a whole suite of factors.

 - How much will the business rules change?
 - Do the business rules need to be independently deployed?
 - How complex are the business rules?
 - What kind of throughput are we going to need?
 - Is the operation atomic?

etc. etc.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/11/2008 5:08:14 PM
S Perryman wrote:
> Tegiri Nenashi wrote:
> 
>> On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
> 
> SP>For me, the big problem has always been the following :
> 
> SP>SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
> 
> SP>s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
> 
> SP>In the OO world, the problem is that for each instance of SomeType held
> SP>in Somewhere, the *implementation* of the property 'x' could be merely
> SP>an actual data value, or a serious computation process. That is the 
> ADT/OO
> SP>way.
> 
>> If x is computed, then why don't you introduce a function that 
>> computes it?
> 
> We have.
> A function whose implementation may be different for every instance of
> Sometype that is contained by Somewhere.

Instance is just a synonym for variable. The dbms should choose an 
implementation based on value and possibly on optimization hints 
provided by the DBA. See specialization by constraint and generalization 
by constraint.


>> In relational world a function call is a join.
> 
> A join on what specifically ??

One joins relations. Functions are a proper subset of relations.


>> If this function is not known at runtime
>> then what logic is involved in selecting it?
> 
> You will have to clarify what you mean here.
> 
> 
>> Can't the problem solved by dynamically constructing this query?
> 
> The time of query construction is irrelevant.

If you say so.


>>> I see it different. First the above should be decomposed into primitive
>>> operations over the types involved. There is at least the type of the 
>>> table
>>> and one of the cell. If SELECT were doubly dispatching, then one could
>>> certainly provide different implementations for different 
>>> combinations of
>>> types.

Sounds like a horrendous and costly way of dealing with something so simple.


[snip]

> SP>It is because of this that I believe that the only paradigm that is 
> capable
> SP>of providing the true engine for a relational info base that caters for
> SP>both OO and current RDBMS, is Functional programming (data values and
> SP>computation entities - functions - are treated the same, techniques 
> such as
> SP>lazy evaluation, "copy on write" behaviour etc) .
> 
>> Function is just a relation with functional dependency. It works
>> pretty much like an index. When a function is called from a query, it
>> is essentially a join, although there is no ambiguity which order this
>> join is evaluated.
> 
> The "order" of evaluation is an *implementation* decision.

Um, sometimes. If the order of evaluation affects the result, it becomes 
a logical decision that the user must understand.


>> Therefore, in principle, FP is too weak to embrace
>> relational. It is more likely to happen the other way.
> 
> FP is perfectly capable of accommodating RA.
> Because RA is based on mathematical concepts, as is FP.
> 
> Therefore any computable predicate expressible in RA, can be expressed in
> FP.

But why would one want to?


>> Relational programing has its weaknesses, but they are not what OO
>> propellerheads think.
> 
> The weakness, as with all things, is in the *implementation* of the
> concept. No better demonstrated than SQL for databases, and C++ for OO 
> prog langs.

I disagree. The weakness of graph based logical data models is in the 
model itself.


>> One missing part in the relational is formal
>> grammars and languages. The underlying theory of grammars and language
>> theory is Kleene algebra which is incompatible with RA. Witness how
>> regular expressions are integrated into SQL
> 
> SQL is a *specific implementation* of the relational model is it not.

Not really. It is a whole class of implementations based on something 
somewhat similar to the relational model. It is the only commercially 
successful language based on any relational principles, however.


> There is nothing inherent in the relational model, or regexps, that prevent
> the latter being defined in terms of the former (ie confirming my comment
> above about implementations) .
> 
> Regards,
> Steven Perryman
0
bbadour (434)
2/11/2008 5:42:56 PM

Robert Martin wrote:
> On 2008-02-09 13:37:47 -0600, topmind <topmind@technologist.com> said:
>
> > The problem with paradigm-potpourri is that its more expensive to hire
> > people who have sufficient experience in them all. The industry tends
> > to force programmers into managers or unemployment after about 15
> > years, and 15 years is not enough for most programmers to master that
> > many paradigms. And, I don't think the benefits of mixing is strong
> > enough to offset that either.
>
> Congratulations Bryce!  THAT was an intelligent point.
>
> You and I come to very different conclusions about it though.  For my
> money, I think we should encourage programmers to mature in their craft
> and become multi-paradigm specialists.  I don't think it's wise to
> throw a bunch of 20somethings into the paradigm mold and try to get
> everything done with the clones that come out.

Okay, but I don't understand how we can encourage them to mature their
craft if they will be moving on to different pastures soon? Software
development has far less stability than say a medical doctor: it's a
burn-and-churn industry, and not getting any slower. And hiring is
usually done based on how well one knows a specific tool, not how many
paradigms they have mastered. And we are being told to become domain
specialists to help resolve and communicate "business needs" rather
than be merely "bit-heads".

Something has to give.

>
> --
> Robert C. Martin (Uncle Bob)=EF=BF=BD=EF=BF=BD| email: unclebob@objectment=
or.com

-T-
0
topmind (2124)
2/11/2008 6:29:36 PM

Robert Martin wrote:
> On 2008-02-09 23:58:27 -0600, topmind <topmind@technologist.com> said:
>
> > But OOP and relational often don't compliment each other, but instead
> > fight over territory. Unless clear and logical rules form that tell us
> > when to stop one and start the other, this problem is not small.
>
> ANOTHER INTELLIGENT POINT BY BRYCE!  That's two in one day!
>
> I agree, there is conflict at the borders.
>
> Do we create a stored procedure to calculate the pay of the employee?
> Or should we query for the data and write a suite of algorithms in Java?
>
> Which you choose depends on a whole suite of factors.
>
>  - How much will the business rules change?
>  - Do the business rules need to be independently deployed?
>  - How complex are the business rules?
>  - What kind of throughput are we going to need?
>  - Is the operation atomic?
>
> etc. etc.

I think there is more too it than stored-procedures versus Java
methods. A stored procedure is often just a subroutine written in
Oracle's app language.

A bigger issue is how to manage "variations on a theme". OOP tends to
use polymorphism and object pointers, while a data-centric approach
tends to use set theory and attributes (meta data). I much prefer the
second. I won't claim it objectively better, but to my mind it is a
lot nicer, more flexible, and easier to report/study/sift via query
and table browsers. And more cross-app-language-friendly. It is just
easier to get my head around sets than graphs of object pointers. Sets
are a higher-level abstraction than graphs of object pointers IMO.
(Data-centric approaches are almost like building a domain-specific
interpreter.)

Another way of saying almost the same thing is that managing
relationships BETWEEN objects is a dark-grey art, while in data-
centric approaches relationship management is a light-grey art because
it was invented for mass relationship managment.

>
>
> --
> Robert C. Martin (Uncle Bob)=EF=BF=BD=EF=BF=BD| email: unclebob@objectment=
or.com

-T-
0
topmind (2124)
2/11/2008 6:44:28 PM
On Feb 11, 8:30 am, S Perryman <q...@q.com> wrote:
> Tegiri Nenashi wrote:
> > On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
>
> SP>For me, the big problem has always been the following :
>
> SP>SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
>
> SP>s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
>
> SP>In the OO world, the problem is that for each instance of SomeType held
> SP>in Somewhere, the *implementation* of the property 'x' could be merely
> SP>an actual data value, or a serious computation process. That is the ADT/OO
> SP>way.

(removed confusing exchange)
Unless you state your problem in more detail -- I suggest one page
description -- I fail to understand it.

> FP is perfectly capable of accommodating RA.
> Because RA is based on mathematical concepts, as is FP.
>
> Therefore any computable predicate expressible in RA, can be expressed in
> FP.

This argument is too weak. There are plently of incompatible
mathematical models.

> There is nothing inherent in the relational model, or regexps, that prevent
> the latter being defined in terms of the former (ie confirming my comment
> above about implementations) .

No, one fundamental difference between the two models is the
properties of the join operation. In regular expressions join is not
commutative. For example the result of concatenating "ab" with "cde"
depends on the order. In relational algebra join is commutative. The
other huge difference is that in RA join is compatible with set
intersection; basically intersection is a join. In regular expressions
algebra intersection can't be expressed via join.
0
2/11/2008 7:02:06 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:200802111038258930-unclebob@objectmentorcom...
> On 2008-02-08 11:17:54 -0600, Jan Hidders <hidders@gmail.com> said:
>
> > They asked Bjarne Stroustrup? Why??
> >
> >   "I invented the term Object-Oriented, and I can tell you I did not
> > have C++ in mind."
> >   - Alan Kay
>
> I don't wish to minimize the contribution that Kay made.  It has been
> enormous.  The undercurrents he started with Smalltalk continue to
> pervade our industry, subsuming it from the bottom up.  Revolutions in
> our thought such as Design Patterns, Agile Development, Test Driven
> Development, etc, etc, can all be traced to the Smalltalk community.
>
> Having said that, Kay did not invent OO.  He may have coined the term,
> but the concepts were invented years before by Ole Johan Dahl, and
> Kristian Nygaard in the language Simula-67.  (When they moved the
> calling frame from the stack to the heap.)
>
> Now it happens that both Kay and Stroustrup were influenced by Simula.

As I said some ways back in this topic,  OO had its origins in simulation.
Thank you for making the heritage more explicit.



0
cressey73 (124)
2/11/2008 9:16:56 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2008021110401511272-unclebob@objectmentorcom...
> On 2008-02-09 04:21:08 -0600, mAsterdam <mAsterdam@vrijdag.org> said:
>
> > Any ideas except 'the other guys are so stupid'?
>
> Yes.  Each group thinks it understands the other.  Both are wrong.
>
I can't speak for comp.object.  In c.d.t.  the regulars often label as
"stupid" people who combine a certain stubbornness with a certain ignorance.
With regard to databases,  a large number of newcomers come in with the
notion that,  "I know next to nothing about databases,  but I'm pretty
certain that there isn't much of importance to know."

For those of us who have studied databases for years either in theory or in
practice or both,  and think we have learned a great deal in that time,
this attitude seems singularly counterproductive when it comes to learning
anything new.


We regulars also have our own habits of thought and communication,  that
tend to shut down useful dialogue with many newcomers. You can judge for
yourself, based on this topic.

I think that if you are going to find any useful confluence betwen the
theory of DB and the theory of OO,  you going to have to find it in the way
each of them deals with the theory of data.  We do both deal with data,
don't we?

Speaking just for myself,  I had been programming for some 20 years when I
began to "do databases",  some 23 years ago now.  I would say that the
cutover from process centered thinking to data centered thinking was much
more profound than the cutover from structured programming to object
oriented programming.

And I realize that OO is not just OOP.





0
cressey73 (124)
2/11/2008 9:28:39 PM

David Cressey wrote:
> "Robert Martin" <unclebob@objectmentor.com> wrote in message
> news:200802111038258930-unclebob@objectmentorcom...
> > On 2008-02-08 11:17:54 -0600, Jan Hidders <hidders@gmail.com> said:
> >
> > > They asked Bjarne Stroustrup? Why??
> > >
> > >   "I invented the term Object-Oriented, and I can tell you I did not
> > > have C++ in mind."
> > >   - Alan Kay
> >
> > I don't wish to minimize the contribution that Kay made.  It has been
> > enormous.  The undercurrents he started with Smalltalk continue to
> > pervade our industry, subsuming it from the bottom up.  Revolutions in
> > our thought such as Design Patterns, Agile Development, Test Driven
> > Development, etc, etc, can all be traced to the Smalltalk community.
> >
> > Having said that, Kay did not invent OO.  He may have coined the term,
> > but the concepts were invented years before by Ole Johan Dahl, and
> > Kristian Nygaard in the language Simula-67.  (When they moved the
> > calling frame from the stack to the heap.)

A bit backtracking here, but if he coined the term, then wouldn't that
mean that he gets to define what is and isn't "OOP"?  Even though
*some* features (at least) of OO were in earlier languages, that does
not mean the *entire* earlier language was OO.  In other words, he
gets to decide what belongs to "OO" and what doesn't, in this view.

Unless, one argues that "common usage" trumps Kay, which is a
legitimate claim. But either way, Simula is not really the key factor.

> >
> > Now it happens that both Kay and Stroustrup were influenced by Simula.
>
> As I said some ways back in this topic,  OO had its origins in simulation.
> Thank you for making the heritage more explicit.

-T-
0
topmind (2124)
2/11/2008 9:38:08 PM
David Cressey wrote:

> "Robert Martin" <unclebob@objectmentor.com> wrote in message
> news:2008021110401511272-unclebob@objectmentorcom...
> 
>>On 2008-02-09 04:21:08 -0600, mAsterdam <mAsterdam@vrijdag.org> said:
>>
>>>Any ideas except 'the other guys are so stupid'?
>>
>>Yes.  Each group thinks it understands the other.  Both are wrong.

Martin is an idiot. I have been doing OO for 20 years and doing it very 
well. My interest in OO pre-dates my interest in data management theory.

I call the comp.object folks ignorant and stupid because they are. 
Martin more so than most. He is a self-aggrandizing ignorant.

[snip]
0
bbadour (434)
2/11/2008 10:14:10 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2008021110111250073-unclebob@objectmentorcom...
> On 2008-02-07 14:35:26 -0600, Victor Porton <porton@narod.ru> said:
>
> > I know both object oriented programming and DB (SQL). But it seems
> > that these are incompatible. Or may somebody advice how to meddle them
> > together?
>
> The concepts are orthogonal.  Objects are not tables.  Tables are not
> objects.  The many efforts to try to force tables and objects together
> always cause trouble.  Things work better when you recognize the
> benefits of tables, and the benefits of objects, and use each where
> they belong rather than try to force one to use the other.
>
> Tables expose data and have no behavior.  Objects hide data and expose
> behavior.

I have a different understanding.

Objects do not always hide data.  Specifically,  they pass messages to each
other in the form of data.  Going further, objects do not "see" the behavior
of other objects.  What they see is the data, written into messages, that is
the result of behavior.  Seeing the result of behavior is not the same thing
as seeing the behavior itself.

One could do a data centric analysis of an object world, by analyzing the
data passed among the objects in that world.  Such an analysis would be much
more like the kind of analysis one makes of a database.  Or, perhaps more
likely,  analysis of a set of information requirements that is to be filled
by a database not yet designed.



0
cressey73 (124)
2/11/2008 10:21:12 PM
Bob Badour wrote:

> Martin is an idiot.

Sure, but I trust him on OO over you. I trust TopMind over you.
0
phlip2005 (2215)
2/11/2008 11:22:31 PM
On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
> On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
>
>
> > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > > > > wrote:
> > > > > > > [What is data, in your opinion?
>
> > > > > > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > > > > > and value in FOL.  A value without description is of course just
> > > > > > noise.
>
> > > > > Latin datum is past participle of dare, "to give".  What make you say
> > > > > data is necessarily a set of propositions?
>
> > > > The OED. "Facts, esp. numerical facts, collected together for
> > > > reference or information." The etymology stems from 'dare', because
> > > > facts are always communicated or "given". I understand of course that
> > > > the term is thrown around wantonly and ambiguosly nowadays, but as
> > > > data theorists, we shouldn't be party to that imo ;)
> > > > > Are you suggesting a value
> > > > > is meaningless without a proposition?  Why can't a datum just be a
> > > > > value?
>
> > > > Because ta value has to be associated with something. Hofstadter gave
> > > > a good example of this with the groove modulations on a vinyl record.
> > > > To us they are (musical) data, to an alien not knowing their context,
> > > > it is not. You need the context.
>
> > > > > Wouldn't you say a recorded image is data?
>
> > > > Of course, so long as I know it's an image. If its just ones and
> > > > zero's stored in a computer, without anyway of telling they represent
> > > > a picture, then it is simply noise.
>
> > > Let's indeed assume we know how to interpret the 1's and 0's as an
> > > image.  So what have we got?  Nothing but a *value*.
>
> > No, you now have a value with applied context. That creates a fact.
> > You now therefore have data. It's simple to show - consider "1000001".
> > Thats currently a value, but its not data. Its only data when I store
> > it, and state one of the following:
>
> > "100001" is a text string
> > "100001" is an integer (i.e. 65)
> > "100001" is an ascii character (i.e. A)
> > etc..
>
> These "facts" are all tautologies that are true whether you record
> them or not.

I'm not seeing whats so controversial or difficult about the fact that
"10001" is just a meaningless binary value until you give it a
context. It seems somewhat obvious to me.

> I dispute your premise that the purpose of the data in
> this case is to state a fact that is known a-priori to be true.

A Datum is a given fact. That's what the word means formally. I have
said nothing more, and I have no idea what you are on about talking
about "the purpose of data".

> If that is its purpose then it conveys precisely zero information.
>
> > > We can display
> > > it.  We can comment on whether we like it - even if we haven't a clue
> > > where it came from.  But I don't see any sense in which the image
> > > value gives us any statements of fact beyond the specification of a
> > > value.  A value simply "is".
>
> > > I would suggest that a lot of the data in the world is characterised
> > > more closely as "interesting values" than collections of
> > > propositions.
>
> > You cannot store these interesting values without implicitly stating
> > some fact about them.
>
> By definition, when a value is specified, its type is specified as
> well (except possibly if type inheritance is supported).
>
> C. Date states the following in "Introduction to Database Systems",
> section 5.2, and subsection titled "Values and Variables are typed":
>
>     "Every value has ... some type...Note that,
>     by definition, a given value always has
>     exactly one type, which never changes.
>     [footnote:  except possibly if type
>     inheritance is supported]"
>
> When a particular value like the integer 73 is specified, there is no
> implicit fact being specified.   The statement that the integer 73
> exists in any absolute sense is entirely metaphysical and meaningless
> within computer science.

So you just wriite "73" down and are telling me its a datum? I'm
pretty sure that's what we call a "value", not data. I'm wondering if
you are misconstruing my point - "73" is only data when you apply some
context to it, like saying this its someones room number, or today's
average temperature, or the amount of red in a certain pixel of an
image (and yes, those are then facts).
0
jog (83)
2/12/2008 1:01:48 AM
On Feb 12, 1:01 am, JOG <j...@cs.nott.ac.uk> wrote:
> On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>
>
>
> > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > > > > > wrote:
> > > > > > > > [What is data, in your opinion?
>
> > > > > > > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > > > > > > and value in FOL.  A value without description is of course just
> > > > > > > noise.
>
> > > > > > Latin datum is past participle of dare, "to give".  What make you say
> > > > > > data is necessarily a set of propositions?
>
> > > > > The OED. "Facts, esp. numerical facts, collected together for
> > > > > reference or information." The etymology stems from 'dare', because
> > > > > facts are always communicated or "given". I understand of course that
> > > > > the term is thrown around wantonly and ambiguosly nowadays, but as
> > > > > data theorists, we shouldn't be party to that imo ;)
> > > > > > Are you suggesting a value
> > > > > > is meaningless without a proposition?  Why can't a datum just be a
> > > > > > value?
>
> > > > > Because ta value has to be associated with something. Hofstadter gave
> > > > > a good example of this with the groove modulations on a vinyl record.
> > > > > To us they are (musical) data, to an alien not knowing their context,
> > > > > it is not. You need the context.
>
> > > > > > Wouldn't you say a recorded image is data?
>
> > > > > Of course, so long as I know it's an image. If its just ones and
> > > > > zero's stored in a computer, without anyway of telling they represent
> > > > > a picture, then it is simply noise.
>
> > > > Let's indeed assume we know how to interpret the 1's and 0's as an
> > > > image.  So what have we got?  Nothing but a *value*.
>
> > > No, you now have a value with applied context. That creates a fact.
> > > You now therefore have data. It's simple to show - consider "1000001".
> > > Thats currently a value, but its not data. Its only data when I store
> > > it, and state one of the following:
>
> > > "100001" is a text string
> > > "100001" is an integer (i.e. 65)
> > > "100001" is an ascii character (i.e. A)
> > > etc..
>
> > These "facts" are all tautologies that are true whether you record
> > them or not.
>
> I'm not seeing whats so controversial or difficult about the fact that
> "10001" is just a meaningless binary value until you give it a
> context. It seems somewhat obvious to me.
>
> > I dispute your premise that the purpose of the data in
> > this case is to state a fact that is known a-priori to be true.
>
> A Datum is a given fact. That's what the word means formally. I have
> said nothing more, and I have no idea what you are on about talking
> about "the purpose of data".
>
>
>
> > If that is its purpose then it conveys precisely zero information.
>
> > > > We can display
> > > > it.  We can comment on whether we like it - even if we haven't a clue
> > > > where it came from.  But I don't see any sense in which the image
> > > > value gives us any statements of fact beyond the specification of a
> > > > value.  A value simply "is".
>
> > > > I would suggest that a lot of the data in the world is characterised
> > > > more closely as "interesting values" than collections of
> > > > propositions.
>
> > > You cannot store these interesting values without implicitly stating
> > > some fact about them.
>
> > By definition, when a value is specified, its type is specified as
> > well (except possibly if type inheritance is supported).
>
> > C. Date states the following in "Introduction to Database Systems",
> > section 5.2, and subsection titled "Values and Variables are typed":
>
> >     "Every value has ... some type...Note that,
> >     by definition, a given value always has
> >     exactly one type, which never changes.
> >     [footnote:  except possibly if type
> >     inheritance is supported]"
>
> > When a particular value like the integer 73 is specified, there is no
> > implicit fact being specified.   The statement that the integer 73
> > exists in any absolute sense is entirely metaphysical and meaningless
> > within computer science.
>
> So you just wriite "73" down and are telling me its a datum? I'm
> pretty sure that's what we call a "value", not data. I'm wondering if
> you are misconstruing my point - "73" is only data when you apply some
> context to it, like saying this its someones room number, or today's
> average temperature, or the amount of red in a certain pixel of an
> image (and yes, those are then facts).

Let me clarify the distinction I'm making David:
"RED" is a value.
"The first pixel in the image is RED" is a datum.

That can't be that contentious...can it?
0
jog (83)
2/12/2008 1:14:05 AM
"JOG" <jog@cs.nott.ac.uk> wrote in message 
news:27321846-87df-4f21-a7bd-382d8b7d6605@m34g2000hsf.googlegroups.com...
> On Feb 12, 1:01 am, JOG <j...@cs.nott.ac.uk> wrote:
>> On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>>
>>
>>
>> > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>
>> > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>>
>> > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>
>> > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>>
>> > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>>
>> > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" 
>> > > > > > > <mail...@dmitry-kazakov.de>
>> > > > > > > wrote:
>> > > > > > > > [What is data, in your opinion?
>>
>> > > > > > > Data. Lots of datum - from latin, meaning statement of fact. 
>> > > > > > > Predicate
>> > > > > > > and value in FOL.  A value without description is of course 
>> > > > > > > just
>> > > > > > > noise.
>>
>> > > > > > Latin datum is past participle of dare, "to give".  What make 
>> > > > > > you say
>> > > > > > data is necessarily a set of propositions?
>>
>> > > > > The OED. "Facts, esp. numerical facts, collected together for
>> > > > > reference or information." The etymology stems from 'dare', 
>> > > > > because
>> > > > > facts are always communicated or "given". I understand of course 
>> > > > > that
>> > > > > the term is thrown around wantonly and ambiguosly nowadays, but 
>> > > > > as
>> > > > > data theorists, we shouldn't be party to that imo ;)
>> > > > > > Are you suggesting a value
>> > > > > > is meaningless without a proposition?  Why can't a datum just 
>> > > > > > be a
>> > > > > > value?
>>
>> > > > > Because ta value has to be associated with something. Hofstadter 
>> > > > > gave
>> > > > > a good example of this with the groove modulations on a vinyl 
>> > > > > record.
>> > > > > To us they are (musical) data, to an alien not knowing their 
>> > > > > context,
>> > > > > it is not. You need the context.
>>
>> > > > > > Wouldn't you say a recorded image is data?
>>
>> > > > > Of course, so long as I know it's an image. If its just ones and
>> > > > > zero's stored in a computer, without anyway of telling they 
>> > > > > represent
>> > > > > a picture, then it is simply noise.
>>
>> > > > Let's indeed assume we know how to interpret the 1's and 0's as an
>> > > > image.  So what have we got?  Nothing but a *value*.
>>
>> > > No, you now have a value with applied context. That creates a fact.
>> > > You now therefore have data. It's simple to show - consider 
>> > > "1000001".
>> > > Thats currently a value, but its not data. Its only data when I store
>> > > it, and state one of the following:
>>
>> > > "100001" is a text string
>> > > "100001" is an integer (i.e. 65)
>> > > "100001" is an ascii character (i.e. A)
>> > > etc..
>>
>> > These "facts" are all tautologies that are true whether you record
>> > them or not.
>>
>> I'm not seeing whats so controversial or difficult about the fact that
>> "10001" is just a meaningless binary value until you give it a
>> context. It seems somewhat obvious to me.
>>
>> > I dispute your premise that the purpose of the data in
>> > this case is to state a fact that is known a-priori to be true.
>>
>> A Datum is a given fact. That's what the word means formally. I have
>> said nothing more, and I have no idea what you are on about talking
>> about "the purpose of data".
>>
>>
>>
>> > If that is its purpose then it conveys precisely zero information.
>>
>> > > > We can display
>> > > > it.  We can comment on whether we like it - even if we haven't a 
>> > > > clue
>> > > > where it came from.  But I don't see any sense in which the image
>> > > > value gives us any statements of fact beyond the specification of a
>> > > > value.  A value simply "is".
>>
>> > > > I would suggest that a lot of the data in the world is 
>> > > > characterised
>> > > > more closely as "interesting values" than collections of
>> > > > propositions.
>>
>> > > You cannot store these interesting values without implicitly stating
>> > > some fact about them.
>>
>> > By definition, when a value is specified, its type is specified as
>> > well (except possibly if type inheritance is supported).
>>
>> > C. Date states the following in "Introduction to Database Systems",
>> > section 5.2, and subsection titled "Values and Variables are typed":
>>
>> >     "Every value has ... some type...Note that,
>> >     by definition, a given value always has
>> >     exactly one type, which never changes.
>> >     [footnote:  except possibly if type
>> >     inheritance is supported]"
>>
>> > When a particular value like the integer 73 is specified, there is no
>> > implicit fact being specified.   The statement that the integer 73
>> > exists in any absolute sense is entirely metaphysical and meaningless
>> > within computer science.
>>
>> So you just wriite "73" down and are telling me its a datum? I'm
>> pretty sure that's what we call a "value", not data. I'm wondering if
>> you are misconstruing my point - "73" is only data when you apply some
>> context to it, like saying this its someones room number, or today's
>> average temperature, or the amount of red in a certain pixel of an
>> image (and yes, those are then facts).
>
> Let me clarify the distinction I'm making David:
> "RED" is a value.
> "The first pixel in the image is RED" is a datum.
>
> That can't be that contentious...can it?

Isn't a datum an atomic value?  I think I remember reading somewhere, "Each 
and every datum (atomic value)...."

I think the distinction you want to make is whether or not some individual 
that is represented by the value 73 actually exists.  For that there needs 
to be a context.  If the value 73 from the domain of integers is named in a 
tuple in a relation in a database, then clearly that particular instance of 
the value 73 has a context and thus maps to an actual individual in the 
picture of the universe of discourse that is the database.  Clearly the act 
of storing the value 73 gives it context.  Without context, 73 is a possible 
value, not an actual value.



0
brian8537 (72)
2/12/2008 1:49:58 AM
David Cressey wrote:
....
> As I said some ways back in this topic,  OO had its origins in simulation.
> Thank you for making the heritage more explicit.


Too right.  Can't be said often enough, at least in this group.
0
paul
2/12/2008 2:44:41 AM
On Feb 12, 10:01 am, JOG <j...@cs.nott.ac.uk> wrote:
> On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>
>
>
>
>
> > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > > > > > wrote:
> > > > > > > > [What is data, in your opinion?
>
> > > > > > > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > > > > > > and value in FOL.  A value without description is of course just
> > > > > > > noise.
>
> > > > > > Latin datum is past participle of dare, "to give".  What make you say
> > > > > > data is necessarily a set of propositions?
>
> > > > > The OED. "Facts, esp. numerical facts, collected together for
> > > > > reference or information." The etymology stems from 'dare', because
> > > > > facts are always communicated or "given". I understand of course that
> > > > > the term is thrown around wantonly and ambiguosly nowadays, but as
> > > > > data theorists, we shouldn't be party to that imo ;)
> > > > > > Are you suggesting a value
> > > > > > is meaningless without a proposition?  Why can't a datum just be a
> > > > > > value?
>
> > > > > Because ta value has to be associated with something. Hofstadter gave
> > > > > a good example of this with the groove modulations on a vinyl record.
> > > > > To us they are (musical) data, to an alien not knowing their context,
> > > > > it is not. You need the context.
>
> > > > > > Wouldn't you say a recorded image is data?
>
> > > > > Of course, so long as I know it's an image. If its just ones and
> > > > > zero's stored in a computer, without anyway of telling they represent
> > > > > a picture, then it is simply noise.
>
> > > > Let's indeed assume we know how to interpret the 1's and 0's as an
> > > > image.  So what have we got?  Nothing but a *value*.
>
> > > No, you now have a value with applied context. That creates a fact.
> > > You now therefore have data. It's simple to show - consider "1000001".
> > > Thats currently a value, but its not data. Its only data when I store
> > > it, and state one of the following:
>
> > > "100001" is a text string
> > > "100001" is an integer (i.e. 65)
> > > "100001" is an ascii character (i.e. A)
> > > etc..
>
> > These "facts" are all tautologies that are true whether you record
> > them or not.
>
> I'm not seeing whats so controversial or difficult about the fact that
> "10001" is just a meaningless binary value until you give it a
> context. It seems somewhat obvious to me.

When you say "meaningless binary value", are you suggesting a value
can exist independently of its type?


> > I dispute your premise that the purpose of the data in
> > this case is to state a fact that is known a-priori to be true.
>
> A Datum is a given fact. That's what the word means formally. I have
> said nothing more, and I have no idea what you are on about talking
> about "the purpose of data".

Let me use an example:  I give you a disk with some data, tell you a-
priori that it records a string, describe the format and you are able
to determine that the recorded value is a poem

    "Is it binary or is it data?
     Is it info or knowledge,
     or is it wisdom -
     the whole enchilada?"

Note that no additional context has been provided.  I would say the
purpose of the data was to convey a value, but not to convey a fact.


> > If that is its purpose then it conveys precisely zero information.
>
> > > > We can display
> > > > it.  We can comment on whether we like it - even if we haven't a clue
> > > > where it came from.  But I don't see any sense in which the image
> > > > value gives us any statements of fact beyond the specification of a
> > > > value.  A value simply "is".
>
> > > > I would suggest that a lot of the data in the world is characterised
> > > > more closely as "interesting values" than collections of
> > > > propositions.
>
> > > You cannot store these interesting values without implicitly stating
> > > some fact about them.
>
> > By definition, when a value is specified, its type is specified as
> > well (except possibly if type inheritance is supported).
>
> > C. Date states the following in "Introduction to Database Systems",
> > section 5.2, and subsection titled "Values and Variables are typed":
>
> >     "Every value has ... some type...Note that,
> >     by definition, a given value always has
> >     exactly one type, which never changes.
> >     [footnote:  except possibly if type
> >     inheritance is supported]"
>
> > When a particular value like the integer 73 is specified, there is no
> > implicit fact being specified.   The statement that the integer 73
> > exists in any absolute sense is entirely metaphysical and meaningless
> > within computer science.
>
> So you just wriite "73" down and are telling me its a datum? I'm
> pretty sure that's what we call a "value", not data.

C.Date distinguishes between a value (that by definition doesn't exist
in time and space), versus the *appearance* of a value which appears
in time and space and is encoded in a particular way.

I would suggest that data should by definition be regarded as
synonymous with the appearance of a value.

If you don't agree with that, then let's treat it as a definitional
matter.  However I'm curious to know what you would say is the
distinction.

> I'm wondering if
> you are misconstruing my point - "73" is only data when you apply some
> context to it, like saying this its someones room number, or today's
> average temperature, or the amount of red in a certain pixel of an
> image (and yes, those are then facts).

I don't agree with that definition of "data".  Particular integers
don't tend to be interesting in their own right, so we never record
them without a context.   However that is not true for more complex
value types, such as strings or images.
0
davidbl (206)
2/12/2008 5:37:47 AM
On Feb 12, 10:14 am, JOG <j...@cs.nott.ac.uk> wrote:
> On Feb 12, 1:01 am, JOG <j...@cs.nott.ac.uk> wrote:
>
>
>
>
>
> > On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> > > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > > > > > > wrote:
> > > > > > > > > [What is data, in your opinion?
>
> > > > > > > > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > > > > > > > and value in FOL.  A value without description is of course just
> > > > > > > > noise.
>
> > > > > > > Latin datum is past participle of dare, "to give".  What make you say
> > > > > > > data is necessarily a set of propositions?
>
> > > > > > The OED. "Facts, esp. numerical facts, collected together for
> > > > > > reference or information." The etymology stems from 'dare', because
> > > > > > facts are always communicated or "given". I understand of course that
> > > > > > the term is thrown around wantonly and ambiguosly nowadays, but as
> > > > > > data theorists, we shouldn't be party to that imo ;)
> > > > > > > Are you suggesting a value
> > > > > > > is meaningless without a proposition?  Why can't a datum just be a
> > > > > > > value?
>
> > > > > > Because ta value has to be associated with something. Hofstadter gave
> > > > > > a good example of this with the groove modulations on a vinyl record.
> > > > > > To us they are (musical) data, to an alien not knowing their context,
> > > > > > it is not. You need the context.
>
> > > > > > > Wouldn't you say a recorded image is data?
>
> > > > > > Of course, so long as I know it's an image. If its just ones and
> > > > > > zero's stored in a computer, without anyway of telling they represent
> > > > > > a picture, then it is simply noise.
>
> > > > > Let's indeed assume we know how to interpret the 1's and 0's as an
> > > > > image.  So what have we got?  Nothing but a *value*.
>
> > > > No, you now have a value with applied context. That creates a fact.
> > > > You now therefore have data. It's simple to show - consider "1000001".
> > > > Thats currently a value, but its not data. Its only data when I store
> > > > it, and state one of the following:
>
> > > > "100001" is a text string
> > > > "100001" is an integer (i.e. 65)
> > > > "100001" is an ascii character (i.e. A)
> > > > etc..
>
> > > These "facts" are all tautologies that are true whether you record
> > > them or not.
>
> > I'm not seeing whats so controversial or difficult about the fact that
> > "10001" is just a meaningless binary value until you give it a
> > context. It seems somewhat obvious to me.
>
> > > I dispute your premise that the purpose of the data in
> > > this case is to state a fact that is known a-priori to be true.
>
> > A Datum is a given fact. That's what the word means formally. I have
> > said nothing more, and I have no idea what you are on about talking
> > about "the purpose of data".
>
> > > If that is its purpose then it conveys precisely zero information.
>
> > > > > We can display
> > > > > it.  We can comment on whether we like it - even if we haven't a clue
> > > > > where it came from.  But I don't see any sense in which the image
> > > > > value gives us any statements of fact beyond the specification of a
> > > > > value.  A value simply "is".
>
> > > > > I would suggest that a lot of the data in the world is characterised
> > > > > more closely as "interesting values" than collections of
> > > > > propositions.
>
> > > > You cannot store these interesting values without implicitly stating
> > > > some fact about them.
>
> > > By definition, when a value is specified, its type is specified as
> > > well (except possibly if type inheritance is supported).
>
> > > C. Date states the following in "Introduction to Database Systems",
> > > section 5.2, and subsection titled "Values and Variables are typed":
>
> > >     "Every value has ... some type...Note that,
> > >     by definition, a given value always has
> > >     exactly one type, which never changes.
> > >     [footnote:  except possibly if type
> > >     inheritance is supported]"
>
> > > When a particular value like the integer 73 is specified, there is no
> > > implicit fact being specified.   The statement that the integer 73
> > > exists in any absolute sense is entirely metaphysical and meaningless
> > > within computer science.
>
> > So you just wriite "73" down and are telling me its a datum? I'm
> > pretty sure that's what we call a "value", not data. I'm wondering if
> > you are misconstruing my point - "73" is only data when you apply some
> > context to it, like saying this its someones room number, or today's
> > average temperature, or the amount of red in a certain pixel of an
> > image (and yes, those are then facts).
>
> Let me clarify the distinction I'm making David:
> "RED" is a value.
> "The first pixel in the image is RED" is a datum.
>
> That can't be that contentious...can it?

I assume this is an image with enumerated colour values for pixels,
and first pixel means "top,left" or something like that.

I'm a little suspicious of "the image".  An image is a value and
values are self identifying.

Anyway, I don't understand the point you are making.  I think of an
image as a value, and one can state all sorts of tautologies about
values.  Eg

	The string "hello" is a prefix of the string "hello world"

0
davidbl (206)
2/12/2008 6:02:41 AM
On Feb 12, 10:49 am, "Brian Selzer" <br...@selzer-software.com> wrote:
> "JOG" <j...@cs.nott.ac.uk> wrote in message
>
> news:27321846-87df-4f21-a7bd-382d8b7d6605@m34g2000hsf.googlegroups.com...
>
>
>
>
>
> > On Feb 12, 1:01 am, JOG <j...@cs.nott.ac.uk> wrote:
> >> On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>
> >> > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> >> > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>
> >> > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> >> > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> >> > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> >> > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov"
> >> > > > > > > <mail...@dmitry-kazakov.de>
> >> > > > > > > wrote:
> >> > > > > > > > [What is data, in your opinion?
>
> >> > > > > > > Data. Lots of datum - from latin, meaning statement of fact.
> >> > > > > > > Predicate
> >> > > > > > > and value in FOL.  A value without description is of course
> >> > > > > > > just
> >> > > > > > > noise.
>
> >> > > > > > Latin datum is past participle of dare, "to give".  What make
> >> > > > > > you say
> >> > > > > > data is necessarily a set of propositions?
>
> >> > > > > The OED. "Facts, esp. numerical facts, collected together for
> >> > > > > reference or information." The etymology stems from 'dare',
> >> > > > > because
> >> > > > > facts are always communicated or "given". I understand of course
> >> > > > > that
> >> > > > > the term is thrown around wantonly and ambiguosly nowadays, but
> >> > > > > as
> >> > > > > data theorists, we shouldn't be party to that imo ;)
> >> > > > > > Are you suggesting a value
> >> > > > > > is meaningless without a proposition?  Why can't a datum just
> >> > > > > > be a
> >> > > > > > value?
>
> >> > > > > Because ta value has to be associated with something. Hofstadter
> >> > > > > gave
> >> > > > > a good example of this with the groove modulations on a vinyl
> >> > > > > record.
> >> > > > > To us they are (musical) data, to an alien not knowing their
> >> > > > > context,
> >> > > > > it is not. You need the context.
>
> >> > > > > > Wouldn't you say a recorded image is data?
>
> >> > > > > Of course, so long as I know it's an image. If its just ones and
> >> > > > > zero's stored in a computer, without anyway of telling they
> >> > > > > represent
> >> > > > > a picture, then it is simply noise.
>
> >> > > > Let's indeed assume we know how to interpret the 1's and 0's as an
> >> > > > image.  So what have we got?  Nothing but a *value*.
>
> >> > > No, you now have a value with applied context. That creates a fact.
> >> > > You now therefore have data. It's simple to show - consider
> >> > > "1000001".
> >> > > Thats currently a value, but its not data. Its only data when I store
> >> > > it, and state one of the following:
>
> >> > > "100001" is a text string
> >> > > "100001" is an integer (i.e. 65)
> >> > > "100001" is an ascii character (i.e. A)
> >> > > etc..
>
> >> > These "facts" are all tautologies that are true whether you record
> >> > them or not.
>
> >> I'm not seeing whats so controversial or difficult about the fact that
> >> "10001" is just a meaningless binary value until you give it a
> >> context. It seems somewhat obvious to me.
>
> >> > I dispute your premise that the purpose of the data in
> >> > this case is to state a fact that is known a-priori to be true.
>
> >> A Datum is a given fact. That's what the word means formally. I have
> >> said nothing more, and I have no idea what you are on about talking
> >> about "the purpose of data".
>
> >> > If that is its purpose then it conveys precisely zero information.
>
> >> > > > We can display
> >> > > > it.  We can comment on whether we like it - even if we haven't a
> >> > > > clue
> >> > > > where it came from.  But I don't see any sense in which the image
> >> > > > value gives us any statements of fact beyond the specification of a
> >> > > > value.  A value simply "is".
>
> >> > > > I would suggest that a lot of the data in the world is
> >> > > > characterised
> >> > > > more closely as "interesting values" than collections of
> >> > > > propositions.
>
> >> > > You cannot store these interesting values without implicitly stating
> >> > > some fact about them.
>
> >> > By definition, when a value is specified, its type is specified as
> >> > well (except possibly if type inheritance is supported).
>
> >> > C. Date states the following in "Introduction to Database Systems",
> >> > section 5.2, and subsection titled "Values and Variables are typed":
>
> >> >     "Every value has ... some type...Note that,
> >> >     by definition, a given value always has
> >> >     exactly one type, which never changes.
> >> >     [footnote:  except possibly if type
> >> >     inheritance is supported]"
>
> >> > When a particular value like the integer 73 is specified, there is no
> >> > implicit fact being specified.   The statement that the integer 73
> >> > exists in any absolute sense is entirely metaphysical and meaningless
> >> > within computer science.
>
> >> So you just wriite "73" down and are telling me its a datum? I'm
> >> pretty sure that's what we call a "value", not data. I'm wondering if
> >> you are misconstruing my point - "73" is only data when you apply some
> >> context to it, like saying this its someones room number, or today's
> >> average temperature, or the amount of red in a certain pixel of an
> >> image (and yes, those are then facts).
>
> > Let me clarify the distinction I'm making David:
> > "RED" is a value.
> > "The first pixel in the image is RED" is a datum.
>
> > That can't be that contentious...can it?
>
> Isn't a datum an atomic value?  I think I remember reading somewhere, "Each
> and every datum (atomic value)...."
>
> I think the distinction you want to make is whether or not some individual
> that is represented by the value 73 actually exists.  For that there needs
> to be a context.  If the value 73 from the domain of integers is named in a
> tuple in a relation in a database, then clearly that particular instance of
> the value 73 has a context and thus maps to an actual individual in the
> picture of the universe of discourse that is the database.  Clearly the act
> of storing the value 73 gives it context.  Without context, 73 is a possible
> value, not an actual value.

Instance of a value? Context of a value?  Possible value?  Actual
value?  I cannot make sense of that.  There is a theorem that states
that the integers are unique up to isomorphism. It is customary to say
there is only one integer with the value 73.

Rather than "instance of value", I think you mean "appearance of
value".  However I still can't follow the rest.

0
davidbl (206)
2/12/2008 6:21:33 AM
"David Cressey" <cressey73@verizon.net> writes:
> "Robert Martin" <unclebob@objectmentor.com> wrote:
>> Tables expose data and have no behavior.  Objects hide data and
>> expose behavior.
>
> I have a different understanding.
>
> Objects do not always hide data.  Specifically,  they pass messages to each
> other in the form of data.

     Some messages may contain data, but many do not.  Consider this,
for example:

  Thread someThread = new SomeThreadImplementation();
  someThread.run();

Unless you're considering the name of the class and/or the name of the
method to be data, the message is solely about behavior.

> Going further, objects do not "see" the behavior of other objects.
> What they see is the data, written into messages, that is the result
> of behavior.

     Objects can invoke the behaviors of other objects without needing
to monitor for any results.

> One could do a data centric analysis of an object world, by
> analyzing the data passed among the objects in that world.

     That would miss a great deal of information in a behavior-centric
system.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/12/2008 12:01:32 PM
"David Cressey" <cressey73@verizon.net> writes:
> I think that if you are going to find any useful confluence betwen
> the theory of DB and the theory of OO, you going to have to find it
> in the way each of them deals with the theory of data.  We do both
> deal with data, don't we?

     That's a very c.d.t. view of the world.  ;-)

     OO is much more focused on behavior than on data.  Behavior must
be considered when discussing any confluence.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/12/2008 12:08:21 PM
On Feb 12, 5:37 am, David BL <davi...@iinet.net.au> wrote:
> On Feb 12, 10:01 am, JOG <j...@cs.nott.ac.uk> wrote:
>
>
>
> > On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> > > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > > > > > > wrote:
> > > > > > > > > [What is data, in your opinion?
>
> > > > > > > > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > > > > > > > and value in FOL.  A value without description is of course just
> > > > > > > > noise.
>
> > > > > > > Latin datum is past participle of dare, "to give".  What make you say
> > > > > > > data is necessarily a set of propositions?
>
> > > > > > The OED. "Facts, esp. numerical facts, collected together for
> > > > > > reference or information." The etymology stems from 'dare', because
> > > > > > facts are always communicated or "given". I understand of course that
> > > > > > the term is thrown around wantonly and ambiguosly nowadays, but as
> > > > > > data theorists, we shouldn't be party to that imo ;)
> > > > > > > Are you suggesting a value
> > > > > > > is meaningless without a proposition?  Why can't a datum just be a
> > > > > > > value?
>
> > > > > > Because ta value has to be associated with something. Hofstadter gave
> > > > > > a good example of this with the groove modulations on a vinyl record.
> > > > > > To us they are (musical) data, to an alien not knowing their context,
> > > > > > it is not. You need the context.
>
> > > > > > > Wouldn't you say a recorded image is data?
>
> > > > > > Of course, so long as I know it's an image. If its just ones and
> > > > > > zero's stored in a computer, without anyway of telling they represent
> > > > > > a picture, then it is simply noise.
>
> > > > > Let's indeed assume we know how to interpret the 1's and 0's as an
> > > > > image.  So what have we got?  Nothing but a *value*.
>
> > > > No, you now have a value with applied context. That creates a fact.
> > > > You now therefore have data. It's simple to show - consider "1000001".
> > > > Thats currently a value, but its not data. Its only data when I store
> > > > it, and state one of the following:
>
> > > > "100001" is a text string
> > > > "100001" is an integer (i.e. 65)
> > > > "100001" is an ascii character (i.e. A)
> > > > etc..
>
> > > These "facts" are all tautologies that are true whether you record
> > > them or not.
>
> > I'm not seeing whats so controversial or difficult about the fact that
> > "10001" is just a meaningless binary value until you give it a
> > context. It seems somewhat obvious to me.
>
> When you say "meaningless binary value", are you suggesting a value
> can exist independently of its type?

I am suggesting that 10001 is a binary number, no more and no less,
until you apply some meaning to it and hence turn it into data. Same
with a picture. Until you say something about it, its just a picture
value.

Consider /unallocated/ RAM in your PC. Look at 5 contiguous bits at
random. Are you telling me that the binary number you are looking at
is "data"? I'd accept that it is a value (albeit a meaningless one)
but "data"? You really think that?

>
> > > I dispute your premise that the purpose of the data in
> > > this case is to state a fact that is known a-priori to be true.
>
> > A Datum is a given fact. That's what the word means formally. I have
> > said nothing more, and I have no idea what you are on about talking
> > about "the purpose of data".
>
> Let me use an example:  I give you a disk with some data, tell you a-
> priori that it records a string, describe the format and you are able
> to determine that the recorded value is a poem
>
>     "Is it binary or is it data?
>      Is it info or knowledge,
>      or is it wisdom -
>      the whole enchilada?"
>

Thats a value imo, and its only data if we say "The file myPoem.txt
contains 'Is it binary or is it...'". I do realise that the
definitions I am suggesting as formal are at odds to the handy wavy,
nebulous way we throw around terms such as 'data', 'data model', etc.

As proof (!) consider your above example if you placed the poem
written on paper in front of me. Are you telling me that is data?
Course not, its just a poem written down - a value. So then what is
the difference between this and your example on a disk? That its
encoded in binary?


> Note that no additional context has been provided.  I would say the
> purpose of the data was to convey a value, but not to convey a fact.
>
>
>
> > > If that is its purpose then it conveys precisely zero information.
>
> > > > > We can display
> > > > > it.  We can comment on whether we like it - even if we haven't a clue
> > > > > where it came from.  But I don't see any sense in which the image
> > > > > value gives us any statements of fact beyond the specification of a
> > > > > value.  A value simply "is".
>
> > > > > I would suggest that a lot of the data in the world is characterised
> > > > > more closely as "interesting values" than collections of
> > > > > propositions.
>
> > > > You cannot store these interesting values without implicitly stating
> > > > some fact about them.
>
> > > By definition, when a value is specified, its type is specified as
> > > well (except possibly if type inheritance is supported).
>
> > > C. Date states the following in "Introduction to Database Systems",
> > > section 5.2, and subsection titled "Values and Variables are typed":
>
> > >     "Every value has ... some type...Note that,
> > >     by definition, a given value always has
> > >     exactly one type, which never changes.
> > >     [footnote:  except possibly if type
> > >     inheritance is supported]"
>
> > > When a particular value like the integer 73 is specified, there is no
> > > implicit fact being specified.   The statement that the integer 73
> > > exists in any absolute sense is entirely metaphysical and meaningless
> > > within computer science.
>
> > So you just wriite "73" down and are telling me its a datum? I'm
> > pretty sure that's what we call a "value", not data.
>
> C.Date distinguishes between a value (that by definition doesn't exist
> in time and space), versus the *appearance* of a value which appears
> in time and space and is encoded in a particular way.

Is this what your view of the terms is based upon?

>
> I would suggest that data should by definition be regarded as
> synonymous with the appearance of a value.
>
> If you don't agree with that, then let's treat it as a definitional
> matter.  However I'm curious to know what you would say is the
> distinction.

Yes, sure,  this is just definitional. However I am on the side of
traditional scientific notion of data ("On the third experiment the
electrical current was x amps"), as well as Codds! Regards, J.

>
> > I'm wondering if
> > you are misconstruing my point - "73" is only data when you apply some
> > context to it, like saying this its someones room number, or today's
> > average temperature, or the amount of red in a certain pixel of an
> > image (and yes, those are then facts).
>
> I don't agree with that definition of "data".  Particular integers
> don't tend to be interesting in their own right, so we never record
> them without a context.   However that is not true for more complex
> value types, such as strings or images.

0
jog (83)
2/12/2008 12:53:20 PM
On Feb 12, 6:02 am, David BL <davi...@iinet.net.au> wrote:
> On Feb 12, 10:14 am, JOG <j...@cs.nott.ac.uk> wrote:
>
>
>
> > On Feb 12, 1:01 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> > > > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > > > > > > > wrote:
> > > > > > > > > > [What is data, in your opinion?
>
> > > > > > > > > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > > > > > > > > and value in FOL.  A value without description is of course just
> > > > > > > > > noise.
>
> > > > > > > > Latin datum is past participle of dare, "to give".  What make you say
> > > > > > > > data is necessarily a set of propositions?
>
> > > > > > > The OED. "Facts, esp. numerical facts, collected together for
> > > > > > > reference or information." The etymology stems from 'dare', because
> > > > > > > facts are always communicated or "given". I understand of course that
> > > > > > > the term is thrown around wantonly and ambiguosly nowadays, but as
> > > > > > > data theorists, we shouldn't be party to that imo ;)
> > > > > > > > Are you suggesting a value
> > > > > > > > is meaningless without a proposition?  Why can't a datum just be a
> > > > > > > > value?
>
> > > > > > > Because ta value has to be associated with something. Hofstadter gave
> > > > > > > a good example of this with the groove modulations on a vinyl record.
> > > > > > > To us they are (musical) data, to an alien not knowing their context,
> > > > > > > it is not. You need the context.
>
> > > > > > > > Wouldn't you say a recorded image is data?
>
> > > > > > > Of course, so long as I know it's an image. If its just ones and
> > > > > > > zero's stored in a computer, without anyway of telling they represent
> > > > > > > a picture, then it is simply noise.
>
> > > > > > Let's indeed assume we know how to interpret the 1's and 0's as an
> > > > > > image.  So what have we got?  Nothing but a *value*.
>
> > > > > No, you now have a value with applied context. That creates a fact.
> > > > > You now therefore have data. It's simple to show - consider "1000001".
> > > > > Thats currently a value, but its not data. Its only data when I store
> > > > > it, and state one of the following:
>
> > > > > "100001" is a text string
> > > > > "100001" is an integer (i.e. 65)
> > > > > "100001" is an ascii character (i.e. A)
> > > > > etc..
>
> > > > These "facts" are all tautologies that are true whether you record
> > > > them or not.
>
> > > I'm not seeing whats so controversial or difficult about the fact that
> > > "10001" is just a meaningless binary value until you give it a
> > > context. It seems somewhat obvious to me.
>
> > > > I dispute your premise that the purpose of the data in
> > > > this case is to state a fact that is known a-priori to be true.
>
> > > A Datum is a given fact. That's what the word means formally. I have
> > > said nothing more, and I have no idea what you are on about talking
> > > about "the purpose of data".
>
> > > > If that is its purpose then it conveys precisely zero information.
>
> > > > > > We can display
> > > > > > it.  We can comment on whether we like it - even if we haven't a clue
> > > > > > where it came from.  But I don't see any sense in which the image
> > > > > > value gives us any statements of fact beyond the specification of a
> > > > > > value.  A value simply "is".
>
> > > > > > I would suggest that a lot of the data in the world is characterised
> > > > > > more closely as "interesting values" than collections of
> > > > > > propositions.
>
> > > > > You cannot store these interesting values without implicitly stating
> > > > > some fact about them.
>
> > > > By definition, when a value is specified, its type is specified as
> > > > well (except possibly if type inheritance is supported).
>
> > > > C. Date states the following in "Introduction to Database Systems",
> > > > section 5.2, and subsection titled "Values and Variables are typed":
>
> > > >     "Every value has ... some type...Note that,
> > > >     by definition, a given value always has
> > > >     exactly one type, which never changes.
> > > >     [footnote:  except possibly if type
> > > >     inheritance is supported]"
>
> > > > When a particular value like the integer 73 is specified, there is no
> > > > implicit fact being specified.   The statement that the integer 73
> > > > exists in any absolute sense is entirely metaphysical and meaningless
> > > > within computer science.
>
> > > So you just wriite "73" down and are telling me its a datum? I'm
> > > pretty sure that's what we call a "value", not data. I'm wondering if
> > > you are misconstruing my point - "73" is only data when you apply some
> > > context to it, like saying this its someones room number, or today's
> > > average temperature, or the amount of red in a certain pixel of an
> > > image (and yes, those are then facts).
>
> > Let me clarify the distinction I'm making David:
> > "RED" is a value.
> > "The first pixel in the image is RED" is a datum.
>
> > That can't be that contentious...can it?
>
> I assume this is an image with enumerated colour values for pixels,
> and first pixel means "top,left" or something like that.
>
> I'm a little suspicious of "the image".  An image is a value and
> values are self identifying.
>
> Anyway, I don't understand the point you are making.  I think of an
> image as a value, and one can state all sorts of tautologies about
> values.  Eg
>
>         The string "hello" is a prefix of the string "hello world"

Red was the value being discussed in the example, not the image.
Here's another example if it helps:

":-)" is an image value.
"A smile is denoted on usenet by :-)" is a datum.
0
jog (83)
2/12/2008 1:01:13 PM
"JOG" <jog@cs.nott.ac.uk> wrote in message
news:9ee041b4-9546-40b0-81fe-54445a216b97@d21g2000prf.googlegroups.com...
> I am suggesting that 10001 is a binary number, no more and no less,

How do you say the number "ten thousand and one" in ordinary decimal
numbers?


0
cressey73 (124)
2/12/2008 2:19:02 PM
On Feb 12, 2:19 pm, "David Cressey" <cresse...@verizon.net> wrote:
> "JOG" <j...@cs.nott.ac.uk> wrote in message
>
> news:9ee041b4-9546-40b0-81fe-54445a216b97@d21g2000prf.googlegroups.com...
>
> > I am suggesting that 10001 is a binary number, no more and no less,

grrr, this is from a continuing example cressey! The ones and noughts
are simply ons or offs.

>
> How do you say the number "ten thousand and one" in ordinary decimal
> numbers?

10001with a subscript 10 after it :P Anyhow what makes you think
binary isn't "ordinary"? If were all from the simpsons we'd be
counting in base8 right?
0
jog (83)
2/12/2008 2:52:02 PM
Patrick May <pjm@spe.com> writes:
>Thread someThread = new SomeThreadImplementation();
>someThread.run();
>Unless you're considering the name of the class and/or the name of the
>method to be data, the message is solely about behavior.

  I believe that in the general case object-oriented programs
  will also have to use argument values within messages.

  If the argument values are objects, some might not deem them
  to be "data", but at least numerical literals and string
  literals will be considered to be data (even if they refer to
  objects) and hardly can be avoided.

  Which brings up the idea, that it would help to define the
  meaning of �data� first.

  I'd say, when one selects (i.e., �specifies�) a value from a
  range of several values that are possible within a certain
  context, he specifies a datum. �data� then is the plural of
  �datum�.

  For example, �2� selects the value �2� from the range of
  permissible int values, e.g., -32768..+32767.

>>Going further, objects do not "see" the behavior of other
>>objects.  What they see is the data, written into messages,
>>that is the result of behavior.

  One can sometimes hide data at some of the places.

  For example, instead of

System.out.println( "Hello world!" );

  One can write

HelloWorldWriter.writeTo( System.out );

  Or even

HelloWorldToSystemOutWriter.run();

  But one can not hide data all of the time. For example, when
  using �HelloWorldWriter�, somewhere there will be a string
  �Hello world!� or equivalent data.

  So the goal then might be not to get rid of data everywhere,
  but to get ride of data at those places, where it is not 
  appropriate to have data.

0
ram (2986)
2/12/2008 4:27:35 PM
Stefan Ram wrote:

> Patrick May <pjm@spe.com> writes:
> 
>>Thread someThread = new SomeThreadImplementation();
>>someThread.run();

Which is semantically equal to run(someThread)

>>Unless you're considering the name of the class and/or the name of the
>>method to be data, the message is solely about behavior.

The value of the variable, someThread, is data.

[snip]
0
bbadour (434)
2/12/2008 4:42:40 PM
"JOG" <jog@cs.nott.ac.uk> wrote in message
news:0aa50aa4-db76-40ce-89f0-495ad28d12b5@u10g2000prn.googlegroups.com...
> On Feb 12, 2:19 pm, "David Cressey" <cresse...@verizon.net> wrote:
> > "JOG" <j...@cs.nott.ac.uk> wrote in message
> >
> >
news:9ee041b4-9546-40b0-81fe-54445a216b97@d21g2000prf.googlegroups.com...
> >
> > > I am suggesting that 10001 is a binary number, no more and no less,
>
> grrr, this is from a continuing example cressey! The ones and noughts
> are simply ons or offs.
>

Yes, and that's my point, in case you missed it.  Data is passed between a
sender and a receiver in the context of a continuing exchange of  meaningful
signals.  Destroy enough context, and you render the interpretation of the
received data ambiguous.

The best exmple of this is the SETI project.  Are those people decoding
data,  or just listening to noise?


> >
> > How do you say the number "ten thousand and one" in ordinary decimal
> > numbers?
>
> 10001with a subscript 10 after it :P Anyhow what makes you think
> binary isn't "ordinary"? If were all from the simpsons we'd be
> counting in base8 right?



0
cressey73 (124)
2/12/2008 4:46:32 PM
Bob Badour <bbadour@pei.sympatico.ca> writes:
> Stefan Ram wrote:
>> Patrick May <pjm@spe.com> writes:
>>
>>>Thread someThread = new SomeThreadImplementation();
>>>someThread.run();
>
> Which is semantically equal to run(someThread)

     Only if the context of the run() function is the same as that of
the SomeThreadImplementation instance at the time the run() method is
invoked.

     You can't define away the differences between OO and other
techniques that easily.

>>>Unless you're considering the name of the class and/or the name of
>>>the method to be data, the message is solely about behavior.
>
> The value of the variable, someThread, is data.

     It does not, however, enable the type of analysis the orignal
poster was suggesting might be possible.  Because of the OO focus on
behavior, data-only analysis is not able to provide a full view of an
OO system.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/12/2008 4:53:25 PM
"Patrick May" <pjm@spe.com> wrote in message news:m24pce1izn.fsf@spe.com...
> "David Cressey" <cressey73@verizon.net> writes:
> > "Robert Martin" <unclebob@objectmentor.com> wrote:
> >> Tables expose data and have no behavior.  Objects hide data and
> >> expose behavior.
> >
> > I have a different understanding.
> >
> > Objects do not always hide data.  Specifically,  they pass messages to
each
> > other in the form of data.
>
>      Some messages may contain data, but many do not.  Consider this,
> for example:
>
>   Thread someThread = new SomeThreadImplementation();
>   someThread.run();
>
> Unless you're considering the name of the class and/or the name of the
> method to be data, the message is solely about behavior.
>

The stuff that's being passed from one side of the assignment to the other
is data.
What else would it be?

> > Going further, objects do not "see" the behavior of other objects.
> > What they see is the data, written into messages, that is the result
> > of behavior.
>
>      Objects can invoke the behaviors of other objects without needing
> to monitor for any results.
>

I didn't say anything about what they need to monitor or don't need to
monitor.  I only stated what they see and what they do not see.  All they
see is data.



> > One could do a data centric analysis of an object world, by
> > analyzing the data passed among the objects in that world.
>
>      That would miss a great deal of information in a behavior-centric
> system.
>

How does one express information without using data?


0
cressey73 (124)
2/12/2008 5:04:23 PM
"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:data-20080212172448@ram.dialup.fu-berlin.de...
> Patrick May <pjm@spe.com> writes:
> >Thread someThread = new SomeThreadImplementation();
> >someThread.run();
> >Unless you're considering the name of the class and/or the name of the
> >method to be data, the message is solely about behavior.
>
>   I believe that in the general case object-oriented programs
>   will also have to use argument values within messages.
>
>   If the argument values are objects, some might not deem them
>   to be "data", but at least numerical literals and string
>   literals will be considered to be data (even if they refer to
>   objects) and hardly can be avoided.
>
>   Which brings up the idea, that it would help to define the
>   meaning of �data� first.
>
>   I'd say, when one selects (i.e., �specifies�) a value from a
>   range of several values that are possible within a certain
>   context, he specifies a datum. �data� then is the plural of
>   �datum�.
>
>   For example, �2� selects the value �2� from the range of
>   permissible int values, e.g., -32768..+32767.
>
> >>Going further, objects do not "see" the behavior of other
> >>objects.  What they see is the data, written into messages,
> >>that is the result of behavior.
>
>   One can sometimes hide data at some of the places.

Agreed.

What I was disputing is whether all data can be hidden.
If all data is hidden,  there is nothing left with which to express
behavior.


0
cressey73 (124)
2/12/2008 5:06:51 PM
"Patrick May" <pjm@spe.com> wrote in message news:m2prv2m7zu.fsf@spe.com...
> Bob Badour <bbadour@pei.sympatico.ca> writes:
> > Stefan Ram wrote:
> >> Patrick May <pjm@spe.com> writes:
> >>
> >>>Thread someThread = new SomeThreadImplementation();
> >>>someThread.run();
> >
> > Which is semantically equal to run(someThread)
>
>      Only if the context of the run() function is the same as that of
> the SomeThreadImplementation instance at the time the run() method is
> invoked.
>
>      You can't define away the differences between OO and other
> techniques that easily.
>
> >>>Unless you're considering the name of the class and/or the name of
> >>>the method to be data, the message is solely about behavior.
> >
> > The value of the variable, someThread, is data.
>
>      It does not, however, enable the type of analysis the orignal
> poster was suggesting might be possible.  Because of the OO focus on
> behavior, data-only analysis is not able to provide a full view of an
> OO system.
>

Agreed.

However, it's also the case that you can't provide a full view of an OO
system without understanding what's going on inside the capsules.  In short,
encapsulation interferes with full system understanding.



0
cressey73 (124)
2/12/2008 5:09:54 PM
David Cressey wrote:
> "Patrick May" <pjm@spe.com> wrote in message news:m24pce1izn.fsf@spe.com...
> 
>>"David Cressey" <cressey73@verizon.net> writes:
>>
>>>"Robert Martin" <unclebob@objectmentor.com> wrote:
>>>
>>>>Tables expose data and have no behavior.  Objects hide data and
>>>>expose behavior.
>>>
>>>I have a different understanding.
>>>
>>>Objects do not always hide data.  Specifically,  they pass messages to
> 
> each
> 
>>>other in the form of data.
>>
>>     Some messages may contain data, but many do not.  Consider this,
>>for example:
>>
>>  Thread someThread = new SomeThreadImplementation();
>>  someThread.run();
>>
>>Unless you're considering the name of the class and/or the name of the
>>method to be data, the message is solely about behavior.
> 
> The stuff that's being passed from one side of the assignment to the other
> is data.
> What else would it be?

And the stuff before the . is data. Changing the syntax by which one 
passes a reference parameter doesn't change a reference parameter into 
anything else.


>>>Going further, objects do not "see" the behavior of other objects.
>>>What they see is the data, written into messages, that is the result
>>>of behavior.
>>
>>     Objects can invoke the behaviors of other objects without needing
>>to monitor for any results.
> 
> I didn't say anything about what they need to monitor or don't need to
> monitor.  I only stated what they see and what they do not see.  All they
> see is data.
> 
> 
>>>One could do a data centric analysis of an object world, by
>>>analyzing the data passed among the objects in that world.
>>
>>     That would miss a great deal of information in a behavior-centric
>>system.
> 
> How does one express information without using data?

David, you are wasting your time. Unless the idgit defines what he means 
by "object" he is talking nonsense. Is it an object instance (ie. a 
variable) ? An object class (ie. a data type)? An object value?

If he means an object instance (ie. variable) or an object value, the 
object itself is data.
0
bbadour (434)
2/12/2008 5:23:37 PM
David Cressey wrote:

> "Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
> news:data-20080212172448@ram.dialup.fu-berlin.de...
>=20
>>Patrick May <pjm@spe.com> writes:
>>
>>>Thread someThread =3D new SomeThreadImplementation();
>>>someThread.run();
>>>Unless you're considering the name of the class and/or the name of the=

>>>method to be data, the message is solely about behavior.
>>
>>  I believe that in the general case object-oriented programs
>>  will also have to use argument values within messages.
>>
>>  If the argument values are objects, some might not deem them
>>  to be "data", but at least numerical literals and string
>>  literals will be considered to be data (even if they refer to
>>  objects) and hardly can be avoided.
>>
>>  Which brings up the idea, that it would help to define the
>>  meaning of =EF=BF=BDdata=EF=BF=BD first.

Already done. See the ISO/IEC 2382 Standard Vocabularies. Data is=20
information suitably encoded for machine processing. Information and=20
data are the two most fundamental definitions in the standards.

[confusion with literals snipped]


>>>>Going further, objects do not "see" the behavior of other
>>>>objects.  What they see is the data, written into messages,
>>>>that is the result of behavior.
>>
>>  One can sometimes hide data at some of the places.

Information hiding and data hiding are two very different things. Sadly, =

the OO camp has confused them.

[snip]

0
bbadour (434)
2/12/2008 5:27:24 PM
David Cressey wrote:

> "Patrick May" <pjm@spe.com> wrote in message news:m2prv2m7zu.fsf@spe.com...
> 
>>Bob Badour <bbadour@pei.sympatico.ca> writes:
>>
>>>Stefan Ram wrote:
>>>
>>>>Patrick May <pjm@spe.com> writes:
>>>>
>>>>
>>>>>Thread someThread = new SomeThreadImplementation();
>>>>>someThread.run();
>>>
>>>Which is semantically equal to run(someThread)
>>
>>     Only if the context of the run() function is the same as that of
>>the SomeThreadImplementation instance at the time the run() method is
>>invoked.

You are talking nonsense. The context is just data.

I strongly suggest you read _The Third Manifesto_. Otherwise, you are 
arguing from a position of abject ignorance.


>>     You can't define away the differences between OO and other
>>techniques that easily.

What difference? Frankly, there is little difference between OO and any 
other low-level computational model. From a higher-level perspective, 
the only really useful ideas in it are type inheritance and polymorphism.


>>>>>Unless you're considering the name of the class and/or the name of
>>>>>the method to be data, the message is solely about behavior.
>>>
>>>The value of the variable, someThread, is data.
>>
>>     It does not, however, enable the type of analysis the orignal
>>poster was suggesting might be possible.  Because of the OO focus on
>>behavior, data-only analysis is not able to provide a full view of an
>>OO system.
> 
> Agreed.
> 
> However, it's also the case that you can't provide a full view of an OO
> system without understanding what's going on inside the capsules.  In short,
> encapsulation interferes with full system understanding.

Encapsulation is a piss-poor way to achieve information hiding. Physical 
independence and logical independence are so much better.
0
bbadour (434)
2/12/2008 5:38:49 PM
David Cressey wrote:

> "Robert Martin" <unclebob@objectmentor.com> wrote in message
> news:2008021110111250073-unclebob@objectmentorcom...
> 
>>On 2008-02-07 14:35:26 -0600, Victor Porton <porton@narod.ru> said:
>>
>>>I know both object oriented programming and DB (SQL). But it seems
>>>that these are incompatible. Or may somebody advice how to meddle them
>>>together?
>>
>>The concepts are orthogonal.  Objects are not tables.  Tables are not
>>objects.  The many efforts to try to force tables and objects together
>>always cause trouble.  Things work better when you recognize the
>>benefits of tables, and the benefits of objects, and use each where
>>they belong rather than try to force one to use the other.
>>
>>Tables expose data and have no behavior.  Objects hide data and expose
>>behavior.
> 
> I have a different understanding.
> 
> Objects do not always hide data.

First, define what you mean by "object"? Object class? Object instance? 
Object value?

Object classes are data types. Object instances are data variables. 
Object values are data values.

In general, objects are data.

[message/method gobbledygook snipped]
0
bbadour (434)
2/12/2008 5:40:31 PM
Bob Badour <bbadour@pei.sympatico.ca> writes:
>Already done. See the ISO/IEC 2382 Standard Vocabularies.
>Data is information suitably encoded for machine processing.

  Parties are free to choose or not to choose to include the ISO
  vocabulary into their contracts. For research in computer
  science, using ISO vocabularies might not always be appropriate.

  Alan Kay coined the term �objec-oriented programming�,
  and he wanted �get rid of data� in 1967:

      �It was probably in 1967 when someone asked me what I was
      doing, and I said: "It's object-oriented programming".

      The original conception of it had the following parts. [...]

        - I wanted to get rid of data.�

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

  The ISO vocabulary might not be what he had in mind.

  �Information suitably encoded for machine processing�
  might include too many things (like objects and programs).

0
ram (2986)
2/12/2008 5:44:59 PM
"David Cressey" <cressey73@verizon.net> writes:
> "Patrick May" <pjm@spe.com> wrote in message news:m24pce1izn.fsf@spe.com...
>> "David Cressey" <cressey73@verizon.net> writes:
>> > "Robert Martin" <unclebob@objectmentor.com> wrote:
>> >> Tables expose data and have no behavior.  Objects hide data and
>> >> expose behavior.
>> >
>> > I have a different understanding.
>> >
>> > Objects do not always hide data.  Specifically, they pass
> messages to each > > other in the form of data.
>>
>>      Some messages may contain data, but many do not.  Consider
>> this, for example:
>>
>>   Thread someThread = new SomeThreadImplementation();
>>   someThread.run();
>>
>> Unless you're considering the name of the class and/or the name of
>> the method to be data, the message is solely about behavior.
>
> The stuff that's being passed from one side of the assignment to the
> other is data.
> What else would it be?

     The assignment is of a class instance to a variable.  That's
certainly a form of data.  I'm referring to the invocation of the
run() method.  No data is passed explicitly there.  Ultimately data is
passed around in registers to pass control to the appropriate memory
location, but I didn't have the impression that you were referring to
that.

>> > Going further, objects do not "see" the behavior of other
>> > objects.  What they see is the data, written into messages, that
>> > is the result of behavior.
>>
>>      Objects can invoke the behaviors of other objects without
>> needing to monitor for any results.
>
> I didn't say anything about what they need to monitor or don't need
> to monitor.  I only stated what they see and what they do not see.
> All they see is data.

     My point is that a particular object may be completely
uninterested in seeing anything.  It just invokes a behavior and
continues on its way.

>> > One could do a data centric analysis of an object world, by
>> > analyzing the data passed among the objects in that world.
>>
>>      That would miss a great deal of information in a
>> behavior-centric system.
>
> How does one express information without using data?

     How does one obtain data that is encapsulated in objects only by
examining the "data passed among the objects"?

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/12/2008 5:57:56 PM
Bob Badour <bbadour@pei.sympatico.ca> writes:
> David, you are wasting your time. Unless the idgit...

     Ah, I remember you now.  The last time someone cross-posted
between these two groups you showed yourself incapable of discussing
the actual issues, instead retreating to name-calling and accusations
of incompetence against anyone who disagreed with you.

     That may work well as a psychological coping strategy within your
little hothouse of c.d.t., but in the real world where we take
advantage of OO and other techniques to build real, working systems,
your empty bluster doesn't add any more value than your useless
data-centric navel-gazing.

     I shan't waste my time with you further.  Please feel free to
return to your delusions of adequacy.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/12/2008 6:05:39 PM
Stefan Ram wrote:

> Bob Badour <bbadour@pei.sympatico.ca> writes:
>=20
>>Already done. See the ISO/IEC 2382 Standard Vocabularies.
>>Data is information suitably encoded for machine processing.
>=20
>   Parties are free to choose or not to choose to include the ISO
>   vocabulary into their contracts. For research in computer
>   science, using ISO vocabularies might not always be appropriate.

For research in computer science, I expect to see a full definition of=20
every significant term. In general, for example, I would not expect to=20
see a research paper make heavy use of a term like 'object'. Instead, I=20
would expect it to define the computational model and demonstrate=20
properties of that model.


>   Alan Kay coined the term =C2=BBobjec-oriented programming=C2=AB,
>   and he wanted =C2=BBget rid of data=C2=AB in 1967:
>=20
>       =C2=BBIt was probably in 1967 when someone asked me what I was
>       doing, and I said: "It's object-oriented programming".
>=20
>       The original conception of it had the following parts. [...]
>=20
>         - I wanted to get rid of data.=C2=AB

Good for him. Calling data something else doesn't really get rid of it,=20
though.


> http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
>=20
>   The ISO vocabulary might not be what he had in mind.

And since he didn't bother to define what he had in mind, his statement=20
is essentially meaningless. I fail to see the point in directing=20
attention to that which is meaningless.


>   =C2=BBInformation suitably encoded for machine processing=C2=AB
>   might include too many things (like objects and programs).

As Mr. Jones, my high school french teacher, was fond of observing: "You =

have a fine grasp of the obvious."

Program texts are data. The term "object" is essentially meaningless and =

ridiculously overloaded. Whether one means object class, object instance =

or object state, objects are data nevertheless.

0
bbadour (434)
2/12/2008 8:34:45 PM
Bob Badour <bbadour@pei.sympatico.ca> wrote:

[snip]

>As Mr. Jones, my high school french teacher, was fond of observing: "You 
>have a fine grasp of the obvious."

     Hey!  Fundamentals are important!

>Program texts are data. The term "object" is essentially meaningless and 
>ridiculously overloaded. Whether one means object class, object instance 
>or object state, objects are data nevertheless.

     And Bob (and others, such as I) object^Whave differences with
regard to the ridiculous overloading of "object".

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.
0
genew (1214)
2/12/2008 11:30:36 PM
Patrick May <pjm@spe.com> wrote:

>Bob Badour <bbadour@pei.sympatico.ca> writes:
>> David, you are wasting your time. Unless the idgit...
>
>     Ah, I remember you now.  The last time someone cross-posted
>between these two groups you showed yourself incapable of discussing
>the actual issues, instead retreating to name-calling and accusations
>of incompetence against anyone who disagreed with you.
>
>     That may work well as a psychological coping strategy within your
>little hothouse of c.d.t., but in the real world where we take
>advantage of OO and other techniques to build real, working systems,
>your empty bluster doesn't add any more value than your useless
>data-centric navel-gazing.
>
>     I shan't waste my time with you further.  Please feel free to
>return to your delusions of adequacy.

     Wow!  A hattrick (triplet) of bluster.

     You really did skewer Bob.  I can see that your experience in the
area of bluster really helps.  *Your* post is full of namecalling.

     Hint: How about trying again, this time without your nose in the
stratosphere and your writing near the gutter?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.
0
genew (1214)
2/12/2008 11:35:14 PM
Gene Wirchenko wrote:

> Patrick May <pjm@spe.com> wrote:
> 
>>Bob Badour <bbadour@pei.sympatico.ca> writes:
>>
>>>David, you are wasting your time. Unless the idgit...
>>
>>    Ah, I remember you now.  The last time someone cross-posted
>>between these two groups you showed yourself incapable of discussing
>>the actual issues, instead retreating to name-calling and accusations
>>of incompetence against anyone who disagreed with you.
>>
>>    That may work well as a psychological coping strategy within your
>>little hothouse of c.d.t., but in the real world where we take
>>advantage of OO and other techniques to build real, working systems,
>>your empty bluster doesn't add any more value than your useless
>>data-centric navel-gazing.
>>
>>    I shan't waste my time with you further.  Please feel free to
>>return to your delusions of adequacy.
> 
>      Wow!  A hattrick (triplet) of bluster.
> 
>      You really did skewer Bob.  I can see that your experience in the
> area of bluster really helps.  *Your* post is full of namecalling.
> 
>      Hint: How about trying again, this time without your nose in the
> stratosphere and your writing near the gutter?

Don't hold your breath. He wouldn't recognize an actual issue if it bit 
him on the ass.

With few notable exceptions, the folks at comp.objects are all 
self-aggrandizing ignorants who take comfort in the essential void of 
meaning in the words they use. They repeatedly prove themselves 
incapable of understanding the simplest and clearest of concepts.

Patrick has been at the bottom of my twit filter for ages. You and David 
are just trying to torture me by excerpting this nonsense.
0
bbadour (434)
2/12/2008 11:47:41 PM
Bob Badour <bbadour@pei.sympatico.ca> wrote:

[snip]

>Don't hold your breath. He wouldn't recognize an actual issue if it bit 
>him on the ass.

     I am a Rat (Chinese calendar).  I can bite.  I prefer to start
gently.

     I post in the hope that someone speaking up will indicate to him
that his behaviour is less than acceptable and that he will take
appropriate action.  I do not expect it, but it would be nice.  He has
the opportunity now.

>With few notable exceptions, the folks at comp.objects are all 
>self-aggrandizing ignorants who take comfort in the essential void of 
>meaning in the words they use. They repeatedly prove themselves 
>incapable of understanding the simplest and clearest of concepts.
>
>Patrick has been at the bottom of my twit filter for ages. You and David 
>are just trying to torture me by excerpting this nonsense.

     It appears that we are succeeding beyond our wildest dreams.  It
is certainly the case with me as my wildest dreams do not include
Badour torture, not even if you are a small animal.  (Being a Rat, I
am an honorary, small animal.)

Sincerely,

Gene "My Year" Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.
0
genew (1214)
2/13/2008 12:33:30 AM
Gene Wirchenko wrote:

> Bob Badour <bbadour@pei.sympatico.ca> wrote:
> 
> [snip]
> 
>>Don't hold your breath. He wouldn't recognize an actual issue if it bit 
>>him on the ass.
> 
>      I am a Rat (Chinese calendar).  I can bite.  I prefer to start
> gently.
> 
>      I post in the hope that someone speaking up will indicate to him
> that his behaviour is less than acceptable and that he will take
> appropriate action.  I do not expect it, but it would be nice.  He has
> the opportunity now.
> 
> 
>>With few notable exceptions, the folks at comp.objects are all 
>>self-aggrandizing ignorants who take comfort in the essential void of 
>>meaning in the words they use. They repeatedly prove themselves 
>>incapable of understanding the simplest and clearest of concepts.
>>
>>Patrick has been at the bottom of my twit filter for ages. You and David 
>>are just trying to torture me by excerpting this nonsense.
> 
>      It appears that we are succeeding beyond our wildest dreams.  It
> is certainly the case with me as my wildest dreams do not include
> Badour torture, not even if you are a small animal.  (Being a Rat, I
> am an honorary, small animal.)

I am a crab and a snake. Make of that what you will.
0
Bob
2/13/2008 12:47:42 AM
"Gene Wirchenko" wrote:
>
>     I post in the hope that someone speaking up will indicate to him
> that his behaviour is less than acceptable and that he will take
> appropriate action.

What would be acceptable behaviour in response to being called an "idgit"? 


0
2/13/2008 1:06:20 AM
Dmitry A. Kazakov schreef:
> mAsterdam wrote:
>> Dmitry A. Kazakov wrote:
>>> mAsterdam wrote:
>>>
>>>> In your extension, you appear to map your slaves to data.
>>>> Slaves behave, objects do. Data doesn't.
>>> If data did not behave how would it be possible to use data?
>> Being active is not, as your question presupposes,
>> a prerequisite to being used.
> No, I didn't meant that. Behavior is independent on who acts on whom.
> Consider it as a list of all things you could ever do with data.

It is not clear what you are asking with
"If data did not behave how would it be possible to use data?"
Please rephrase.

>>> [What is data, in your opinion? 
>> Recorded facts.
>>
>> In the context of electronic dataprocessing
>> it only makes sense to talk about data when the medium on
>> which they are recorded is readable by some mechanism to
>> achieve electronic representation, but that is not inherent
>> to data.
> 
> True. Inherent is presence of some reading device.
> 
> But why is recording essential? 

To facilitate the sharing of observations.

> It throws in many things which seem unrelated 
> or constraining, such as time aspect and physical presence. 

Features, not bugs :-)

> Or to put it otherwise, can you consider unrecorded,
> not memorized data? 

No.

> May I translate data into a different
> representation and then erase the original record? 
> Will data still be there?

Iff it conveys the same facts as the original record, sure.
As we can't verify the accuracy of the translation in this
instance because the original record is erased, we'll have
to find a way to trust it.

>>> On my side: data are values semantically
>>> bound to some entities from the problem space. 
>> The one recording the facts (or the designer of the datacapture)
>> will have some entities in mind when recording/capturing the data.
>> To make sure that the interpretation won't be far off, a
>> description in terms of entities (from the problem space) helps.
>>
>> This does not garantee that the interpretation in terms of entities
>> of formerly collected facts will stay the same.
> 
> Yes. That cannot be guaranteed.
> 
>> "semantically bound" suggests a formalism.
>> Did you intend that? If so which one?
> 
> Actually it suggests absence of formalism. 

In that case it begins to look like something we could agree on.

> A formal system operates on data
> without any clue of the meaning of.

I think that is to crude.
The meaning itself is informal, hence inherently impossible to fully
access from within the formal system (I think we agree on that).
However, without meaning to associate it with, a formalism is useless.
(grep -i /Coffee machine/ in a recent cdt thread on PoOD.)

>>> (The type of values describes the behavior of data.)]
>> How? I don't understand what you are saying here -
>> this may be a language thing, though.
>> An example might clarify.
> 
> Consider the value 1. It has no behavior (and no use) so long you don't
> tell us its type. It you say that 1 is an integer, then its behavior will
> include "has negative inverse." If the type is Positive, then the behavior
> will be "no negative inverse", "can be squared in R" etc.

Is this what you mean: All operations for which the set is closed?
If so - how is this behaviour of the data itself?

> (Behavior does not presume anything like tiny cogwheels hidden inside 1.
> The cogwheels are rather big and all outside (:-))
> 
>>> If the ultimate goal is same, then managing the thing called data is mere
>>> one possible thread of the process.
>> That does not follow.
>> Furthermore: after the process stops, the data remains.
> 
> Really? You wrote just above:
> 
> "it only makes sense to talk about data when the medium on
> which they are recorded is readable by some mechanism to
> achieve electronic representation, but that is not inherent
> to data."
> 
> Which is all true. So let you have a medium without a process that can read
> it, what did remain of data? It what sense do data remain? As a possibility
> to start a process by some other process which still runs? Consider it on
> the example with 1.

In that sense all phonographs are part of the same process.
It's process, Jim, but not as we know it. Define process.

>>>> Please describe the fence as seen from your side.
>>> In short and technically, it is refusal to view tables as typed values.
>>>
>>>> I see the same DB/DBMS conflation as Patrick made.
>>>> I asked Patrick, and I'm asking you:
>>>> Do you need that?
>>> Yes, I do, especially when talking about a common ground.
>> Patrick May considered his DB/DBMS conflation just sloppy,
>> you need it.
> 
> No, his first, maybe unconscious, reaction was right. DB in interesting to
> us part is software, or else we should have been in sci.physics.

Your trackrecord on stating others peoples opinion suggests
I wait for Patrick to join in.




--
What you see depends on where you stand.
0
mAsterdam (155)
2/13/2008 1:25:15 AM
David Cressey wrote:
> Robert Martin wrote:
>> Victor Porton said:
>>
>>> I know both object oriented programming and DB (SQL). But it seems
>>> that these are incompatible. Or may somebody advice how to meddle them
>>> together?
>> The concepts are orthogonal.  Objects are not tables.  Tables are not
>> objects.  The many efforts to try to force tables and objects together
>> always cause trouble.  Things work better when you recognize the
>> benefits of tables, and the benefits of objects, and use each where
>> they belong rather than try to force one to use the other.
>>
>> Tables expose data and have no behavior.  Objects hide data and expose
>> behavior.
> 
> I have a different understanding.
> 
> Objects do not always hide data.  Specifically,  they pass messages to each
> other in the form of data.  Going further, objects do not "see" the behavior
> of other objects.  What they see is the data, written into messages, that is
> the result of behavior.  Seeing the result of behavior is not the same thing
> as seeing the behavior itself.
> 
> One could do a data centric analysis of an object world, by analyzing the
> data passed among the objects in that world.  Such an analysis would be much
> more like the kind of analysis one makes of a database.  Or, perhaps more
> likely,  analysis of a set of information requirements that is to be filled
> by a database not yet designed.

In ISAC (Information Systems Analysis of Change, an originally
Swedish school on Informatics, late 70's) there is a useful technique
called "precedence analysis", with 'Y'-diagrams (like genealogy
trees).

It disregards all computations except as confluence nodes for data.
It goes backwards. Not "where does it go to", but "where does it come 
from". Very push-through in situations with mutliple interacting (say 
semi-autonomous) systems. I have never seen a tool supporting this - 
it would come in handy sometimes.
0
mAsterdam (155)
2/13/2008 1:59:47 AM
Stefan Ram wrote:
> http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
HTTP/1.1 403 Access Denied.
0
mAsterdam (155)
2/13/2008 2:02:37 AM
"Leslie Sanford" <jabberdabber@bitemehotmail.com> wrote:

>"Gene Wirchenko" wrote:
>>
>>     I post in the hope that someone speaking up will indicate to him
>> that his behaviour is less than acceptable and that he will take
>> appropriate action.
>
>What would be acceptable behaviour in response to being called an "idgit"? 

     Depends.  If one is one, giving up being one is a good choice.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.
0
genew (1214)
2/13/2008 2:02:39 AM
On Feb 12, 9:53 pm, JOG <j...@cs.nott.ac.uk> wrote:
> On Feb 12, 5:37 am, David BL <davi...@iinet.net.au> wrote:
>
>
>
>
>
> > On Feb 12, 10:01 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>
> > > > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> > > > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> > > > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > > > > > > > > wrote:
> > > > > > > > > > [What is data, in your opinion?
>
> > > > > > > > > Data. Lots of datum - from latin, meaning statement of fact. Predicate
> > > > > > > > > and value in FOL.  A value without description is of course just
> > > > > > > > > noise.
>
> > > > > > > > Latin datum is past participle of dare, "to give".  What make you say
> > > > > > > > data is necessarily a set of propositions?
>
> > > > > > > The OED. "Facts, esp. numerical facts, collected together for
> > > > > > > reference or information." The etymology stems from 'dare', because
> > > > > > > facts are always communicated or "given". I understand of course that
> > > > > > > the term is thrown around wantonly and ambiguosly nowadays, but as
> > > > > > > data theorists, we shouldn't be party to that imo ;)
> > > > > > > > Are you suggesting a value
> > > > > > > > is meaningless without a proposition?  Why can't a datum just be a
> > > > > > > > value?
>
> > > > > > > Because ta value has to be associated with something. Hofstadter gave
> > > > > > > a good example of this with the groove modulations on a vinyl record.
> > > > > > > To us they are (musical) data, to an alien not knowing their context,
> > > > > > > it is not. You need the context.
>
> > > > > > > > Wouldn't you say a recorded image is data?
>
> > > > > > > Of course, so long as I know it's an image. If its just ones and
> > > > > > > zero's stored in a computer, without anyway of telling they represent
> > > > > > > a picture, then it is simply noise.
>
> > > > > > Let's indeed assume we know how to interpret the 1's and 0's as an
> > > > > > image.  So what have we got?  Nothing but a *value*.
>
> > > > > No, you now have a value with applied context. That creates a fact.
> > > > > You now therefore have data. It's simple to show - consider "1000001".
> > > > > Thats currently a value, but its not data. Its only data when I store
> > > > > it, and state one of the following:
>
> > > > > "100001" is a text string
> > > > > "100001" is an integer (i.e. 65)
> > > > > "100001" is an ascii character (i.e. A)
> > > > > etc..
>
> > > > These "facts" are all tautologies that are true whether you record
> > > > them or not.
>
> > > I'm not seeing whats so controversial or difficult about the fact that
> > > "10001" is just a meaningless binary value until you give it a
> > > context. It seems somewhat obvious to me.
>
> > When you say "meaningless binary value", are you suggesting a value
> > can exist independently of its type?
>
> I am suggesting that 10001 is a binary number, no more and no less,
> until you apply some meaning to it and hence turn it into data. Same
> with a picture. Until you say something about it, its just a picture
> value.

I'm having a lot of trouble with your terminology.  I don't even know
what you mean by "binary number".

An integer value like 65 can be encoded in binary.  It is the encoding
that is binary, not the value being encoded.


> Consider /unallocated/ RAM in your PC. Look at 5 contiguous bits at
> random. Are you telling me that the binary number you are looking at
> is "data"? I'd accept that it is a value (albeit a meaningless one)
> but "data"? You really think that?

No I don't.

When data is recorded on some medium there is a lot of implicit
*knowledge* about how it has been encoded.  This knowledge has to
account for all sorts of details, such as what designates a 1 versus a
0.   How many bits in a word?  What order do they appear in?  Is there
an address bus?  How is the address bus organised?  The binary
encoding is only a tiny part of it.  Obviously we both agree that all
that knowledge is implicit in correctly decoding the data.

Our point of contention is rather that I suggest that most generally
the data is nothing other than encoded values, and doesn't necessarily
convey any facts.   I'm assuming that the knowledge implicit in the
encoding of the data is by definition not part of the data itself,
whereas I think you are suggesting it is part of the data.

I would prefer to say that the knowledge of the encoding (the
"protocol") exists independently of the recorded data (or even the
particular instance of the media it is recorded on).   For example I
don't want to create a new file format for every file.


> > > > I dispute your premise that the purpose of the data in
> > > > this case is to state a fact that is known a-priori to be true.
>
> > > A Datum is a given fact. That's what the word means formally. I have
> > > said nothing more, and I have no idea what you are on about talking
> > > about "the purpose of data".
>
> > Let me use an example:  I give you a disk with some data, tell you a-
> > priori that it records a string, describe the format and you are able
> > to determine that the recorded value is a poem
>
> >     "Is it binary or is it data?
> >      Is it info or knowledge,
> >      or is it wisdom -
> >      the whole enchilada?"
>
> Thats a value imo, and its only data if we say "The file myPoem.txt
> contains 'Is it binary or is it...'".

I don't know what that means or what distinction you are making.   I'm
very suspicious of introducing a proposition that is referring by name
to the file.  Names don't have absolute meaning.  What is the context
for this proposition?


> I do realise that the
> definitions I am suggesting as formal are at odds to the handy wavy,
> nebulous way we throw around terms such as 'data', 'data model', etc.
>
> As proof (!) consider your above example if you placed the poem
> written on paper in front of me. Are you telling me that is data?
> Course not, its just a poem written down - a value. So then what is
> the difference between this and your example on a disk? That its
> encoded in binary?

Since this is a computer science discussion group I'm happy to narrow
the definition of data to encodings of values that are intended for
both reading and writing by a computer.


> > Note that no additional context has been provided.  I would say the
> > purpose of the data was to convey a value, but not to convey a fact.
>
> > > > If that is its purpose then it conveys precisely zero information.
>
> > > > > > We can display
> > > > > > it.  We can comment on whether we like it - even if we haven't a clue
> > > > > > where it came from.  But I don't see any sense in which the image
> > > > > > value gives us any statements of fact beyond the specification of a
> > > > > > value.  A value simply "is".
>
> > > > > > I would suggest that a lot of the data in the world is characterised
> > > > > > more closely as "interesting values" than collections of
> > > > > > propositions.
>
> > > > > You cannot store these interesting values without implicitly stating
> > > > > some fact about them.
>
> > > > By definition, when a value is specified, its type is specified as
> > > > well (except possibly if type inheritance is supported).
>
> > > > C. Date states the following in "Introduction to Database Systems",
> > > > section 5.2, and subsection titled "Values and Variables are typed":
>
> > > >     "Every value has ... some type...Note that,
> > > >     by definition, a given value always has
> > > >     exactly one type, which never changes.
> > > >     [footnote:  except possibly if type
> > > >     inheritance is supported]"
>
> > > > When a particular value like the integer 73 is specified, there is no
> > > > implicit fact being specified.   The statement that the integer 73
> > > > exists in any absolute sense is entirely metaphysical and meaningless
> > > > within computer science.
>
> > > So you just wriite "73" down and are telling me its a datum? I'm
> > > pretty sure that's what we call a "value", not data.
>
> > C.Date distinguishes between a value (that by definition doesn't exist
> > in time and space), versus the *appearance* of a value which appears
> > in time and space and is encoded in a particular way.
>
> Is this what your view of the terms is based upon?

These definitions seems reasonable to me.

I don't agree with everything Date says.  For example Date defines
"data" in the same way you do!


> > I would suggest that data should by definition be regarded as
> > synonymous with the appearance of a value.
>
> > If you don't agree with that, then let's treat it as a definitional
> > matter.  However I'm curious to know what you would say is the
> > distinction.
>
> Yes, sure,  this is just definitional. However I am on the side of
> traditional scientific notion of data ("On the third experiment the
> electrical current was x amps"), as well as Codds! Regards, J.

I agree that most scientific data consists of facts.  However you seem
to have agreed that a poem is a value, and that a poem encoded on a
disk can be regarded as data.  I realise that skips past the point you
want to make, but I thought it had nothing to do with the difference
between scientific or poetry application domains.

0
davidbl (206)
2/13/2008 2:06:55 AM
Gene Wirchenko <genew@ocis.net> writes:
> Patrick May <pjm@spe.com> wrote:
>>Bob Badour <bbadour@pei.sympatico.ca> writes:
>>> David, you are wasting your time. Unless the idgit...
>>
>>     Ah, I remember you now.  The last time someone cross-posted
>>between these two groups you showed yourself incapable of discussing
>>the actual issues, instead retreating to name-calling and
>>accusations of incompetence against anyone who disagreed with you.
>>
>>     That may work well as a psychological coping strategy within
>>your little hothouse of c.d.t., but in the real world where we take
>>advantage of OO and other techniques to build real, working systems,
>>your empty bluster doesn't add any more value than your useless
>>data-centric navel-gazing.
>>
>>     I shan't waste my time with you further.  Please feel free to
>>return to your delusions of adequacy.
>
>      Wow!  A hattrick (triplet) of bluster.
>
>      You really did skewer Bob.  I can see that your experience in
> the area of bluster really helps.  *Your* post is full of
> namecalling.

     Darn, I intended for it to be fairly pure flaming.

>      Hint: How about trying again, this time without your nose in
> the stratosphere and your writing near the gutter?

     You seem to be mistaking my purpose.  I see no value in
attempting to engage in reasonable conversation with a self-important
bloviator.  I was merely signing off from that subthread.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/13/2008 2:23:36 AM
On 2008-02-11 12:44:28 -0600, topmind <topmind@technologist.com> said:

> A bigger issue is how to manage "variations on a theme". OOP tends to
> use polymorphism and object pointers, while a data-centric approach
> tends to use set theory and attributes (meta data). I much prefer the
> second. I won't claim it objectively better, but to my mind it is a
> lot nicer, more flexible, and easier to report/study/sift via query
> and table browsers.

I won't disagree with any of that.  I will say, however, that I can 
manage the dependencies between source code modules with OO, and I 
can't with data.  There are other dependencies I can manage with data, 
that I can't with OO.  Both are useful.  Neither is better than the 
other.  They are orthogonal and complementary.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/13/2008 2:49:28 AM
On 2008-02-11 15:28:39 -0600, "David Cressey" <cressey73@verizon.net> said:

> We do both deal with data,
> don't we?

Yes, but in very different ways, and with very different emphasis.

OO is about structuring modules around behavior and hiding data.  The 
structure and form of the data is hidden as deeply as possible, so that 
no other behaviors depend upon it.

DBs are about structuring data, and the access to that data.  Behaviors 
are secondary, and often hidden.  One of the goals of a good data model 
is to facilitate as many behaviors as possible; and to depend on none 
of them.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/13/2008 2:54:05 AM
On 2008-02-11 16:21:12 -0600, "David Cressey" <cressey73@verizon.net> said:

> Objects do not always hide data.  Specifically,  they pass messages to each
> other in the form of data.

True, but the recipient has no guarantee that the data recieved was 
stored anywhere. Nor can the recipient be sure that the recieved data 
originated in the recieved form.   Moreover, the sender expects the 
recipient to do something with the data.  All messages connote action 
of some kind.

> Going further, objects do not "see" the behavior
> of other objects.  What they see is the data, written into messages, that is
> the result of behavior.  Seeing the result of behavior is not the same thing
> as seeing the behavior itself.

Granted, but the dependencies between objects are created by designers 
in pursuit of behaviors.  The reason that one object talks to another 
can be found in the behaviors sought by the designers.  The reason 
messages are sent, and the reason messages have benavior, is behavior.

> 
> One could do a data centric analysis of an object world, by analyzing the
> data passed among the objects in that world.  Such an analysis would be much
> more like the kind of analysis one makes of a database.  Or, perhaps more
> likely,  analysis of a set of information requirements that is to be filled
> by a database not yet designed.

Yes, of course.  It's much like the difference bewteen a Mealy state 
machine and a Moore state machine.  You can prove that they are 
equivalent forms; but they emphasize different things.  Every program 
is a mix of both behavior and data.  You can't have one without the 
other.  But you *can* use different emphases.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/13/2008 3:01:06 AM
Patrick May <pjm@spe.com> wrote:

[snip]

>     You seem to be mistaking my purpose.  I see no value in
>attempting to engage in reasonable conversation with a self-important
>bloviator.  I was merely signing off from that subthread.

     Bob Badour is not a bloviator.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.
0
genew (1214)
2/13/2008 3:02:39 AM
On Feb 12, 5:27 pm, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> [snip]
> [in] the ISO/IEC 2382 Standard Vocabularies. Data is
> information suitably encoded for machine processing.

While I obviously see the need for standardized vocabularies, I just
hate this particular ISO definition. Long before the ISO existed and
before computers were even a twinkle in babbages eye, scientist were
avidly collecting "data". Reams and Reams of it in fact. To say data
is only information suitable for machine processing is simply crap,
surely?

Its a good job I'm pretty lazy, or I'd have a good mind to tell the
ISO what I thought via the sharp end of a strongly worded facebook
wall-post.
0
jog (83)
2/13/2008 3:19:21 AM
"David Cressey" <cressey73@verizon.net> writes:
>Objects do not always hide data.
>Specifically, they pass messages to each other in the form of data. 

  One might say that the core of object-oriented expressions
  is the verb (selector). For example,

      shirt.makeSelfClean()
      car.makeSelfClean()

  The message �makeSelfClean()� will invoke different behavior
  on a shirt than on a car, because a shirt uses other means
  to clean (wash) itself than a car, but both fullfil the
  meaning of the English expression �to make oneself clean�.

  Now, data might be an argument of a verb, as in:

#define FAST_MODE 1

      shirt.makeSelfClean( FAST_MODE )
      car.makeSelfClean( FAST_MODE )

  Here, the value �1� means to wash in a fast mode, which might 
  removed less dirt. �1� is data, but here it appears only in
  subordination to the verb - not in isolation.

  Does this make a big difference?

  Possibly so, because /the behavioral interpretation of the
  argument data is given by the specification of the verb/,
  while isolated data does not have a behavioral interpretation.

  (The /specification/ of a verb (message selector) and its
  parameters possibly is the most underestimated part of
  (object-oriented) programming. I consider it to be an integral
  part of the paradigm. For example, my variant of the LSP
  (liskov-substitution principle) refers to it. JavaDoc is
  something that Java has done right, even if one could imagine
  even more elements from DBC (design by contract), but there
  still are many languages caring much less for documentation.
  Documentation of declared identifiers should be part of
  programming language design, from the very moment a new
  language is being designed.)

0
ram (2986)
2/13/2008 3:25:00 AM
Stefan Ram wrote:
> "David Cressey" <cressey73@verizon.net> writes:
>=20
>>Objects do not always hide data.
>>Specifically, they pass messages to each other in the form of data.=20
>=20
>   One might say that the core of object-oriented expressions
>   is the verb (selector). For example,
>=20
>       shirt.makeSelfClean()
>       car.makeSelfClean()
>=20
>   The message =C2=BBmakeSelfClean()=C2=AB will invoke different behavio=
r
>   on a shirt than on a car, because a shirt uses other means
>   to clean (wash) itself than a car, but both fullfil the
>   meaning of the English expression =C2=BBto make oneself clean=C2=AB.

You seem to have completely missed the point that shirt and car are data =

too. Specifically, they are variables used as reference parameters.

[irrelevancies snipped]
0
bbadour (434)
2/13/2008 3:37:25 AM
"Gene Wirchenko" <genew@ocis.net> wrote in message 
news:adn4r3d82gmulnlt8m2hucnvi7pg67at29@4ax.com...
> Patrick May <pjm@spe.com> wrote:
>
> [snip]
>
>>     You seem to be mistaking my purpose.  I see no value in
>>attempting to engage in reasonable conversation with a self-important
>>bloviator.  I was merely signing off from that subthread.
>
>     Bob Badour is not a bloviator.
>

That's actually true.  He's not a bloviator; he's a blowhard--a loud, 
arrogant windbag who acts like he knows everything.

> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
>     I have preferences.
>     You have biases.
>     He/She has prejudices. 


0
brian8537 (72)
2/13/2008 4:05:06 AM
On Feb 13, 2:40 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:

> Object classes are data types. Object instances are data variables.
> Object values are data values.
>
> In general, objects are data.

In the following, object means object instance, and class means object
class.

AFAIK Bob subscribes to the definitions of variable, value and type
described by C.J. Date.

Accordingly a variable is something that can be assigned a value.  In
the following C++ code

    void foo()
    {
        int* p = new int;
    }

Bob would say there are *two* variables - a pointer named p on the
frame, and an (unnamed) heap allocated int variable.

I think in Bob's view, we have some reasonably clear terminology here
(type, variable and value),  so why would anyone want to come in with
all these silly terms like 'object' or 'class'.

However Bob makes a serious blunder here.   He doesn't seem to realise
the fact that many objects do not actually represent a variable that
can be assigned a value.  ie only a subset of classes can be deemed
value-types (or just types as Date describes them).

Here are some examples of classes that are value-types:

    Point, Rectangle, Circle, String, Matrix, TriSurface, Colour

Here are some classes that aren't

    Thread, ThreadPool, Mutex,  TextButton,  PrinterProxy


Objects are said to have identity, state and behavior.   The idea that
an object can (always) be thought of as a (data) variable that can be
assigned a (data) value reveals a complete lack of understanding of
OO.

Bob's confusion between the concepts of object state versus object
value also leads him to misunderstand the significance of
encapsulation in the context of OO.
0
davidbl (206)
2/13/2008 4:48:47 AM
"Patrick May" <pjm@spe.com> wrote in message news:m24pce1izn.fsf@spe.com...
> "David Cressey" <cressey73@verizon.net> writes:
> > "Robert Martin" <unclebob@objectmentor.com> wrote:
> >> Tables expose data and have no behavior.  Objects hide data and
> >> expose behavior.
> >
> > I have a different understanding.
> >
> > Objects do not always hide data.  Specifically,  they pass messages to
each
> > other in the form of data.
>
>      Some messages may contain data, but many do not.  Consider this,
> for example:
>
>   Thread someThread = new SomeThreadImplementation();
>   someThread.run();
>
> Unless you're considering the name of the class and/or the name of the
> method to be data, the message is solely about behavior.
>

On taking a second look there is something of interest to me in the example
you gave.

As an aside,  I'm not sure what the word "behavior" actually means in the OO
world.  So, in what follows,  I'm going to use the two words "data" and
"program",  two concepts I think I do understand.  What I call "program" may
or may not be the same thing that you call "behavior".  I don't know, but
I'm prepared to learn.

In the first step of your example,  what's being conveyed from the
expression to the variable is definitely data.  The message is,  as you said
"about behavior".  But regardless of what it's about,  it's still data.  I
already pointed this out in a previous reply.  As Bob Badour pointed out,
it's still data when it's being conveyed by the variable from the first step
to the second step.  You may choose to think of it as something other than
data,  but perception is not always reality.

However,  in the second step something happens that's of interest to me.
The value in the variable is employed as if it were "program".  I apologize
to the OO crowd if the use of the word "program" is merely extraneous here.
The word "behavior" might or might not be what I really mean.

There are only two environments I'm familiar with where "stuff"  can be
manipulated as though it were "data" in one step,  and then evaluated as if
it were "program" in a subsequent step.  One is machine language and the
other is lisp.  Both Von Neumann and McCarthy intended this consequence of
their respective designs.

One of the features of the classical procedural languages is the rigid
separation of "program" and "data".  In Pascal, for instance, one can create
some new Pascal code, in the form of text,  manipulating it as though it
were data (which it is).  But in order to "execute" it,  one needs to pass
it through the compiler,  and from there to the run time system.  Once it's
"program"  it can't be seen as "data" anymore.  A program cannot examine
itself.

Now the ability to switch back and forth between manipulating something the
way one manipulates data  and evaluating something the way one evaluates
program is full of power, and full of risk.  The people who separated
program from data in languages like Pascal were not fools.

But Von Neumann and McCarthy were not fools either.

It may be that, if I am to understand OOP any better than I do,  I'm going
to have to pursue this thought a little further.

It may also be that, if those of you who know OO but do not know DB want to
learn anything,  you may have to learn something about data that OO thinking
has trained you to overlook.  You aren't really going to get rid of data.

What you store in a database is data.  Elsewhere in this discussion,  people
are bloviating to beat the band about the definition of "data".  To
paraphrase a supreme court justice,  "I may not be able to define data, but
I know it when I see it." To the extent that OO is about "getting rid of
data",  the term "OODB" is self-contradictory.

That's as far as I've gotten with this line of thought for now.  I'll have
more later.





0
cressey73 (124)
2/13/2008 11:38:32 AM
"Gene Wirchenko" <genew@ocis.net> wrote in message
news:4sj4r3huqrprlmg19abqsk0gdus6bd23nu@4ax.com...
> "Leslie Sanford" <jabberdabber@bitemehotmail.com> wrote:
>
> >"Gene Wirchenko" wrote:
> >>
> >>     I post in the hope that someone speaking up will indicate to him
> >> that his behaviour is less than acceptable and that he will take
> >> appropriate action.
> >
> >What would be acceptable behaviour in response to being called an
"idgit"?
>
>      Depends.  If one is one, giving up being one is a good choice.
>

If one gives up in this discussion,  the only response one supplies is the
equivalent of the SQL NULL.  Interpreting the failure to respond is like
interpreting the failure of the dog to bark in the night.


0
cressey73 (124)
2/13/2008 11:41:30 AM
"mAsterdam" <mAsterdam@vrijdag.org> wrote in message
news:47b24622$0$85781$e4fe514c@news.xs4all.nl...
> Dmitry A. Kazakov schreef:
> > mAsterdam wrote:
> >> Dmitry A. Kazakov wrote:
> >>> mAsterdam wrote:
> >>>
> >>>> In your extension, you appear to map your slaves to data.
> >>>> Slaves behave, objects do. Data doesn't.
> >>> If data did not behave how would it be possible to use data?
> >> Being active is not, as your question presupposes,
> >> a prerequisite to being used.
> > No, I didn't meant that. Behavior is independent on who acts on whom.
> > Consider it as a list of all things you could ever do with data.
>
> It is not clear what you are asking with
> "If data did not behave how would it be possible to use data?"
> Please rephrase.
>
> >>> [What is data, in your opinion?
> >> Recorded facts.
> >>
> >> In the context of electronic dataprocessing
> >> it only makes sense to talk about data when the medium on
> >> which they are recorded is readable by some mechanism to
> >> achieve electronic representation, but that is not inherent
> >> to data.
> >
> > True. Inherent is presence of some reading device.
> >
> > But why is recording essential?
>
> To facilitate the sharing of observations.
>
> > It throws in many things which seem unrelated
> > or constraining, such as time aspect and physical presence.
>
> Features, not bugs :-)
>
> > Or to put it otherwise, can you consider unrecorded,
> > not memorized data?
>
> No.
>
> > May I translate data into a different
> > representation and then erase the original record?
> > Will data still be there?
>
> Iff it conveys the same facts as the original record, sure.
> As we can't verify the accuracy of the translation in this
> instance because the original record is erased, we'll have
> to find a way to trust it.
>
> >>> On my side: data are values semantically
> >>> bound to some entities from the problem space.
> >> The one recording the facts (or the designer of the datacapture)
> >> will have some entities in mind when recording/capturing the data.
> >> To make sure that the interpretation won't be far off, a
> >> description in terms of entities (from the problem space) helps.
> >>
> >> This does not garantee that the interpretation in terms of entities
> >> of formerly collected facts will stay the same.
> >
> > Yes. That cannot be guaranteed.
> >
> >> "semantically bound" suggests a formalism.
> >> Did you intend that? If so which one?
> >
> > Actually it suggests absence of formalism.
>
> In that case it begins to look like something we could agree on.
>
> > A formal system operates on data
> > without any clue of the meaning of.
>
> I think that is to crude.
> The meaning itself is informal, hence inherently impossible to fully
> access from within the formal system (I think we agree on that).
> However, without meaning to associate it with, a formalism is useless.
> (grep -i /Coffee machine/ in a recent cdt thread on PoOD.)
>
> >>> (The type of values describes the behavior of data.)]
> >> How? I don't understand what you are saying here -
> >> this may be a language thing, though.
> >> An example might clarify.
> >
> > Consider the value 1. It has no behavior (and no use) so long you don't
> > tell us its type. It you say that 1 is an integer, then its behavior
will
> > include "has negative inverse." If the type is Positive, then the
behavior
> > will be "no negative inverse", "can be squared in R" etc.
>
> Is this what you mean: All operations for which the set is closed?
> If so - how is this behaviour of the data itself?
>
> > (Behavior does not presume anything like tiny cogwheels hidden inside 1.
> > The cogwheels are rather big and all outside (:-))
> >
> >>> If the ultimate goal is same, then managing the thing called data is
mere
> >>> one possible thread of the process.
> >> That does not follow.
> >> Furthermore: after the process stops, the data remains.
> >
> > Really? You wrote just above:
> >
> > "it only makes sense to talk about data when the medium on
> > which they are recorded is readable by some mechanism to
> > achieve electronic representation, but that is not inherent
> > to data."
> >
> > Which is all true. So let you have a medium without a process that can
read
> > it, what did remain of data? It what sense do data remain? As a
possibility
> > to start a process by some other process which still runs? Consider it
on
> > the example with 1.
>
> In that sense all phonographs are part of the same process.
> It's process, Jim, but not as we know it. Define process.
>
> >>>> Please describe the fence as seen from your side.
> >>> In short and technically, it is refusal to view tables as typed
values.
> >>>
> >>>> I see the same DB/DBMS conflation as Patrick made.
> >>>> I asked Patrick, and I'm asking you:
> >>>> Do you need that?
> >>> Yes, I do, especially when talking about a common ground.
> >> Patrick May considered his DB/DBMS conflation just sloppy,
> >> you need it.
> >
> > No, his first, maybe unconscious, reaction was right. DB in interesting
to
> > us part is software, or else we should have been in sci.physics.
>
> Your trackrecord on stating others peoples opinion suggests
> I wait for Patrick to join in.
>

Can we simplify this whole thing a little bit?

There are three things you can do with data:

1.  You can store data.
2.  You can convey data.
3.  You can transform data.

Those three things add value to data in very different ways.

Almost all useful manipulations of data involve sub-steps that do each of
these three things to data.


0
cressey73 (124)
2/13/2008 11:45:48 AM
"mAsterdam" <mAsterdam@vrijdag.org> wrote in message
news:47b24e69$0$85790$e4fe514c@news.xs4all.nl...
> David Cressey wrote:
> > Robert Martin wrote:
> >> Victor Porton said:
> >>
> >>> I know both object oriented programming and DB (SQL). But it seems
> >>> that these are incompatible. Or may somebody advice how to meddle them
> >>> together?
> >> The concepts are orthogonal.  Objects are not tables.  Tables are not
> >> objects.  The many efforts to try to force tables and objects together
> >> always cause trouble.  Things work better when you recognize the
> >> benefits of tables, and the benefits of objects, and use each where
> >> they belong rather than try to force one to use the other.
> >>
> >> Tables expose data and have no behavior.  Objects hide data and expose
> >> behavior.
> >
> > I have a different understanding.
> >
> > Objects do not always hide data.  Specifically,  they pass messages to
each
> > other in the form of data.  Going further, objects do not "see" the
behavior
> > of other objects.  What they see is the data, written into messages,
that is
> > the result of behavior.  Seeing the result of behavior is not the same
thing
> > as seeing the behavior itself.
> >
> > One could do a data centric analysis of an object world, by analyzing
the
> > data passed among the objects in that world.  Such an analysis would be
much
> > more like the kind of analysis one makes of a database.  Or, perhaps
more
> > likely,  analysis of a set of information requirements that is to be
filled
> > by a database not yet designed.
>
> In ISAC (Information Systems Analysis of Change, an originally
> Swedish school on Informatics, late 70's) there is a useful technique
> called "precedence analysis", with 'Y'-diagrams (like genealogy
> trees).
>
> It disregards all computations except as confluence nodes for data.
> It goes backwards. Not "where does it go to", but "where does it come
> from". Very push-through in situations with mutliple interacting (say
> semi-autonomous) systems. I have never seen a tool supporting this -
> it would come in handy sometimes.

Your description reminds me very much of something I saw years and years
ago.  It was in the area of field service engineers diagnosing a
malfunctioning system down to a single board or a single component on a
board.  The documentation of the signals being passed around by the board or
backplane were always organized by "where does the signal come from"  and
gave information about "where does the signal go?"

But the field service engineers nearly always traced signals "backwards".
That is,  they would start from the place where the malfunction was
observed,  and work their way upstream back to the point where the
malfunctioning component had first injected a bad signal into the system.

The way the documenters had organized the signal documentation was almost
worthless to them.  And the way the FSEs worked was incomprehensible to the
documenters.

Perhaps precedence analysis is likewise more useful for determining why a
given system does not work  than it is for synthesizing a system that will
work.



0
cressey73 (124)
2/13/2008 11:54:26 AM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2008021220540582327-unclebob@objectmentorcom...
> On 2008-02-11 15:28:39 -0600, "David Cressey" <cressey73@verizon.net>
said:
>
> > We do both deal with data,
> > don't we?
>
> Yes, but in very different ways, and with very different emphasis.
>
> OO is about structuring modules around behavior and hiding data.  The
> structure and form of the data is hidden as deeply as possible, so that
> no other behaviors depend upon it.
>

If you can disregard Bob's rude tone without disregarding the content of his
response,  I ask you to do so.

Bob has pointed out that data independence is a stronger concept than data
hiding.

I lean towards the idea that he is right,  although I'm prepared to learn
something new.  (If it's really new, it will be surprising (see Shannon).

The one thing that, in my previous discussions with OO folks,  I think the
OO people have missed, it's the extent to which data independence renders
encapuslation unnecessary.



> DBs are about structuring data, and the access to that data.  Behaviors
> are secondary, and often hidden.  One of the goals of a good data model
> is to facilitate as many behaviors as possible; and to depend on none
> of them.

Well put.


0
cressey73 (124)
2/13/2008 12:01:02 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2008021221010631729-unclebob@objectmentorcom...
> On 2008-02-11 16:21:12 -0600, "David Cressey" <cressey73@verizon.net>
said:
>
> > Objects do not always hide data.  Specifically,  they pass messages to
each
> > other in the form of data.
>
> True, but the recipient has no guarantee that the data recieved was
> stored anywhere. Nor can the recipient be sure that the recieved data
> originated in the recieved form.   Moreover, the sender expects the
> recipient to do something with the data.  All messages connote action
> of some kind.
>

It's the recipient's job to store the data, in general.  One fairly
important exception:  if the sender is a DBMS,  the recipient has the
guarantee that,  if needed,  the same value can be conveyed again.  One area
that confuses some people is who the "recipient" of a database query is.  In
many contexts,  we like to think of the recipient of a query as the client
process that partners with the DBMS as a server process.  In reality,  the
receiver is a transaction, not a process.   When the recieving process
commits a transaction,  and starts a new one,  the guarantee of isolation
from intervening transactions does not span the two transactions.  More than
one bug is a consequence of flawed thinking in this area.


> > Going further, objects do not "see" the behavior
> > of other objects.  What they see is the data, written into messages,
that is
> > the result of behavior.  Seeing the result of behavior is not the same
thing
> > as seeing the behavior itself.
>
> Granted, but the dependencies between objects are created by designers
> in pursuit of behaviors.  The reason that one object talks to another
> can be found in the behaviors sought by the designers.  The reason
> messages are sent, and the reason messages have benavior, is behavior.
>
> >
> > One could do a data centric analysis of an object world, by analyzing
the
> > data passed among the objects in that world.  Such an analysis would be
much
> > more like the kind of analysis one makes of a database.  Or, perhaps
more
> > likely,  analysis of a set of information requirements that is to be
filled
> > by a database not yet designed.
>
> Yes, of course.  It's much like the difference bewteen a Mealy state
> machine and a Moore state machine.  You can prove that they are
> equivalent forms; but they emphasize different things.  Every program
> is a mix of both behavior and data.  You can't have one without the
> other.  But you *can* use different emphases.
>
>
> -- 
> Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
> Object Mentor Inc. | blog: www.butunclebob.com
> The Agile Transition Experts | web: www.objectmentor.com
> 800-338-6716 |
>
>
>


0
cressey73 (124)
2/13/2008 12:07:58 PM
"David BL" <davidbl@iinet.net.au> wrote in message 
news:8c33acce-694e-4edf-8758-7b296ea59557@s8g2000prg.googlegroups.com...
> On Feb 12, 10:49 am, "Brian Selzer" <br...@selzer-software.com> wrote:
>> "JOG" <j...@cs.nott.ac.uk> wrote in message
>>
>> news:27321846-87df-4f21-a7bd-382d8b7d6605@m34g2000hsf.googlegroups.com...
>>
>>
>>
>>
>>
>> > On Feb 12, 1:01 am, JOG <j...@cs.nott.ac.uk> wrote:
>> >> On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>>
>> >> > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>
>> >> > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>>
>> >> > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>
>> >> > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>>
>> >> > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>>
>> >> > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov"
>> >> > > > > > > <mail...@dmitry-kazakov.de>
>> >> > > > > > > wrote:
>> >> > > > > > > > [What is data, in your opinion?
>>
>> >> > > > > > > Data. Lots of datum - from latin, meaning statement of 
>> >> > > > > > > fact.
>> >> > > > > > > Predicate
>> >> > > > > > > and value in FOL.  A value without description is of 
>> >> > > > > > > course
>> >> > > > > > > just
>> >> > > > > > > noise.
>>
>> >> > > > > > Latin datum is past participle of dare, "to give".  What 
>> >> > > > > > make
>> >> > > > > > you say
>> >> > > > > > data is necessarily a set of propositions?
>>
>> >> > > > > The OED. "Facts, esp. numerical facts, collected together for
>> >> > > > > reference or information." The etymology stems from 'dare',
>> >> > > > > because
>> >> > > > > facts are always communicated or "given". I understand of 
>> >> > > > > course
>> >> > > > > that
>> >> > > > > the term is thrown around wantonly and ambiguosly nowadays, 
>> >> > > > > but
>> >> > > > > as
>> >> > > > > data theorists, we shouldn't be party to that imo ;)
>> >> > > > > > Are you suggesting a value
>> >> > > > > > is meaningless without a proposition?  Why can't a datum 
>> >> > > > > > just
>> >> > > > > > be a
>> >> > > > > > value?
>>
>> >> > > > > Because ta value has to be associated with something. 
>> >> > > > > Hofstadter
>> >> > > > > gave
>> >> > > > > a good example of this with the groove modulations on a vinyl
>> >> > > > > record.
>> >> > > > > To us they are (musical) data, to an alien not knowing their
>> >> > > > > context,
>> >> > > > > it is not. You need the context.
>>
>> >> > > > > > Wouldn't you say a recorded image is data?
>>
>> >> > > > > Of course, so long as I know it's an image. If its just ones 
>> >> > > > > and
>> >> > > > > zero's stored in a computer, without anyway of telling they
>> >> > > > > represent
>> >> > > > > a picture, then it is simply noise.
>>
>> >> > > > Let's indeed assume we know how to interpret the 1's and 0's as 
>> >> > > > an
>> >> > > > image.  So what have we got?  Nothing but a *value*.
>>
>> >> > > No, you now have a value with applied context. That creates a 
>> >> > > fact.
>> >> > > You now therefore have data. It's simple to show - consider
>> >> > > "1000001".
>> >> > > Thats currently a value, but its not data. Its only data when I 
>> >> > > store
>> >> > > it, and state one of the following:
>>
>> >> > > "100001" is a text string
>> >> > > "100001" is an integer (i.e. 65)
>> >> > > "100001" is an ascii character (i.e. A)
>> >> > > etc..
>>
>> >> > These "facts" are all tautologies that are true whether you record
>> >> > them or not.
>>
>> >> I'm not seeing whats so controversial or difficult about the fact that
>> >> "10001" is just a meaningless binary value until you give it a
>> >> context. It seems somewhat obvious to me.
>>
>> >> > I dispute your premise that the purpose of the data in
>> >> > this case is to state a fact that is known a-priori to be true.
>>
>> >> A Datum is a given fact. That's what the word means formally. I have
>> >> said nothing more, and I have no idea what you are on about talking
>> >> about "the purpose of data".
>>
>> >> > If that is its purpose then it conveys precisely zero information.
>>
>> >> > > > We can display
>> >> > > > it.  We can comment on whether we like it - even if we haven't a
>> >> > > > clue
>> >> > > > where it came from.  But I don't see any sense in which the 
>> >> > > > image
>> >> > > > value gives us any statements of fact beyond the specification 
>> >> > > > of a
>> >> > > > value.  A value simply "is".
>>
>> >> > > > I would suggest that a lot of the data in the world is
>> >> > > > characterised
>> >> > > > more closely as "interesting values" than collections of
>> >> > > > propositions.
>>
>> >> > > You cannot store these interesting values without implicitly 
>> >> > > stating
>> >> > > some fact about them.
>>
>> >> > By definition, when a value is specified, its type is specified as
>> >> > well (except possibly if type inheritance is supported).
>>
>> >> > C. Date states the following in "Introduction to Database Systems",
>> >> > section 5.2, and subsection titled "Values and Variables are typed":
>>
>> >> >     "Every value has ... some type...Note that,
>> >> >     by definition, a given value always has
>> >> >     exactly one type, which never changes.
>> >> >     [footnote:  except possibly if type
>> >> >     inheritance is supported]"
>>
>> >> > When a particular value like the integer 73 is specified, there is 
>> >> > no
>> >> > implicit fact being specified.   The statement that the integer 73
>> >> > exists in any absolute sense is entirely metaphysical and 
>> >> > meaningless
>> >> > within computer science.
>>
>> >> So you just wriite "73" down and are telling me its a datum? I'm
>> >> pretty sure that's what we call a "value", not data. I'm wondering if
>> >> you are misconstruing my point - "73" is only data when you apply some
>> >> context to it, like saying this its someones room number, or today's
>> >> average temperature, or the amount of red in a certain pixel of an
>> >> image (and yes, those are then facts).
>>
>> > Let me clarify the distinction I'm making David:
>> > "RED" is a value.
>> > "The first pixel in the image is RED" is a datum.
>>
>> > That can't be that contentious...can it?
>>
>> Isn't a datum an atomic value?  I think I remember reading somewhere, 
>> "Each
>> and every datum (atomic value)...."
>>
>> I think the distinction you want to make is whether or not some 
>> individual
>> that is represented by the value 73 actually exists.  For that there 
>> needs
>> to be a context.  If the value 73 from the domain of integers is named in 
>> a
>> tuple in a relation in a database, then clearly that particular instance 
>> of
>> the value 73 has a context and thus maps to an actual individual in the
>> picture of the universe of discourse that is the database.  Clearly the 
>> act
>> of storing the value 73 gives it context.  Without context, 73 is a 
>> possible
>> value, not an actual value.
>
> Instance of a value? Context of a value?  Possible value?  Actual
> value?  I cannot make sense of that.

Perhaps I should clarify:  A database is a proposition--a picture of the 
universe.  There can be many possible pictures of the universe, but only one 
is supposed to be true.  A value can appear in many possible pictures, so it 
follows that a value can appear in a possible picture that is supposed to be 
true or in a possible picture that is not supposed to be true, /or both/. 
If a value is a fact, how, then, can it be both true and not true?  An 
instance of a value, a value in context--the association of a value with a 
picture of the universe--on the other hand, /can/ be a fact because that 
association can be with a possible picture that is supposed to be true or 
with a possible picture that is not supposed to be true, /but not both/.

A value that appears in any possible picture of the universe is a possible 
value.  A value that appears in the possible picture of the universe that is 
supposed to be true is an actual value.

Thus a value is just a value without some context.  Once a value is given 
context, such as being stored in a database, or written down, or whatever, 
then it can be considered information.  Each atomic value that is in the 
database is a datum simply because it is /in/ the database.

[snip]


0
brian8537 (72)
2/13/2008 12:22:20 PM
On Feb 13, 2:06 am, David BL <davi...@iinet.net.au> wrote:
> On Feb 12, 9:53 pm, JOG <j...@cs.nott.ac.uk> wrote:
> [snip]
> > Consider /unallocated/ RAM in your PC. Look at 5 contiguous bits at
> > random. Are you telling me that the binary number you are looking at
> > is "data"? I'd accept that it is a value (albeit a meaningless one)
> > but "data"? You really think that?
>
> No I don't.
>
> When data is recorded on some medium there is a lot of implicit
> *knowledge* about how it has been encoded.  This knowledge has to
> account for all sorts of details, such as what designates a 1 versus a
> 0.   How many bits in a word?  What order do they appear in?  Is there
> an address bus?  How is the address bus organised?  The binary
> encoding is only a tiny part of it.  Obviously we both agree that all
> that knowledge is implicit in correctly decoding the data.

Yes I broadly agree apart from on one key matter (there's a suprise
eh) - "knowledge is implict". I contend the exact opposite, and this
is my whole point really. The knowledge required must be explicit.
That's what makes otherwise random noise, or values, data.  In the
case of a scientist log book for example what the data means is
explicit in a title at the top of the page or in the scientist's
head.

Another example:
"todays lottery numbers: 23, 34, 17"
"experimental reults: 23, 34, 17"

Same values, different data. If you agree with this statement then
values != data surely?

>
> Our point of contention is rather that I suggest that most generally
> the data is nothing other than encoded values, and doesn't necessarily
> convey any facts.   I'm assuming that the knowledge implicit in the
> encoding of the data is by definition not part of the data itself,
> whereas I think you are suggesting it is part of the data.

Yes I think that's an excellent breakdown. Its all just down to where
we draw the lines I guess...
Brian: Data is encoded values. I need to know externally what they
represent.
Jim: Data is encoded values plus an denotation of what they represent.


>
> I would prefer to say that the knowledge of the encoding (the
> "protocol") exists independently of the recorded data (or even the
> particular instance of the media it is recorded on).   For example I
> don't want to create a new file format for every file.
>
>
>
> > > > > I dispute your premise that the purpose of the data in
> > > > > this case is to state a fact that is known a-priori to be true.
>
> > > > A Datum is a given fact. That's what the word means formally. I have
> > > > said nothing more, and I have no idea what you are on about talking
> > > > about "the purpose of data".
>
> > > Let me use an example:  I give you a disk with some data, tell you a-
> > > priori that it records a string, describe the format and you are able
> > > to determine that the recorded value is a poem
>
> > >     "Is it binary or is it data?
> > >      Is it info or knowledge,
> > >      or is it wisdom -
> > >      the whole enchilada?"
>
> > Thats a value imo, and its only data if we say "The file myPoem.txt
> > contains 'Is it binary or is it...'".
>
> I don't know what that means or what distinction you are making.   I'm
> very suspicious of introducing a proposition that is referring by name
> to the file.  Names don't have absolute meaning.  What is the context
> for this proposition?
>
> > I do realise that the
> > definitions I am suggesting as formal are at odds to the handy wavy,
> > nebulous way we throw around terms such as 'data', 'data model', etc.
>
> > As proof (!) consider your above example if you placed the poem
> > written on paper in front of me. Are you telling me that is data?
> > Course not, its just a poem written down - a value. So then what is
> > the difference between this and your example on a disk? That its
> > encoded in binary?
>
> Since this is a computer science discussion group I'm happy to narrow
> the definition of data to encodings of values that are intended for
> both reading and writing by a computer.
>
>
>
> > > Note that no additional context has been provided.  I would say the
> > > purpose of the data was to convey a value, but not to convey a fact.
>
> > > > > If that is its purpose then it conveys precisely zero information.
>
> > > > > > > We can display
> > > > > > > it.  We can comment on whether we like it - even if we haven't a clue
> > > > > > > where it came from.  But I don't see any sense in which the image
> > > > > > > value gives us any statements of fact beyond the specification of a
> > > > > > > value.  A value simply "is".
>
> > > > > > > I would suggest that a lot of the data in the world is characterised
> > > > > > > more closely as "interesting values" than collections of
> > > > > > > propositions.
>
> > > > > > You cannot store these interesting values without implicitly stating
> > > > > > some fact about them.
>
> > > > > By definition, when a value is specified, its type is specified as
> > > > > well (except possibly if type inheritance is supported).
>
> > > > > C. Date states the following in "Introduction to Database Systems",
> > > > > section 5.2, and subsection titled "Values and Variables are typed":
>
> > > > >     "Every value has ... some type...Note that,
> > > > >     by definition, a given value always has
> > > > >     exactly one type, which never changes.
> > > > >     [footnote:  except possibly if type
> > > > >     inheritance is supported]"
>
> > > > > When a particular value like the integer 73 is specified, there is no
> > > > > implicit fact being specified.   The statement that the integer 73
> > > > > exists in any absolute sense is entirely metaphysical and meaningless
> > > > > within computer science.
>
> > > > So you just wriite "73" down and are telling me its a datum? I'm
> > > > pretty sure that's what we call a "value", not data.
>
> > > C.Date distinguishes between a value (that by definition doesn't exist
> > > in time and space), versus the *appearance* of a value which appears
> > > in time and space and is encoded in a particular way.
>
> > Is this what your view of the terms is based upon?
>
> These definitions seems reasonable to me.

This seem overly philosophical to me. Surely we don't need metaphysics
to know that if someone hands me a bit of paper with: "1.00, 0.376 and
0.904" on it, well that's just a list of values. However if if someone
hands you a bit of paper with "Surface Gravity - Earth:1.00, Mars:
0.376 and Venus:0.904", or tells you those denotations,  then we have
data ;)

>
> I don't agree with everything Date says.  For example Date defines
> "data" in the same way you do!

Lol. And me neither, so that's not a good sign. That whole "a relation
has a header object" m'larkey for a start. Regards, J.

>
> > > I would suggest that data should by definition be regarded as
> > > synonymous with the appearance of a value.
>
> > > If you don't agree with that, then let's treat it as a definitional
> > > matter.  However I'm curious to know what you would say is the
> > > distinction.
>
> > Yes, sure,  this is just definitional. However I am on the side of
> > traditional scientific notion of data ("On the third experiment the
> > electrical current was x amps"), as well as Codds! Regards, J.
>
> I agree that most scientific data consists of facts.  However you seem
> to have agreed that a poem is a value, and that a poem encoded on a
> disk can be regarded as data.
> I realise that skips past the point you
> want to make, but I thought it had nothing to do with the difference
> between scientific or poetry application domains.


0
jog (83)
2/13/2008 12:56:08 PM
"JOG" <jog@cs.nott.ac.uk> wrote in message
news:a9f5a3a7-8330-4831-9f1d-ba16b8ccfdbe@e4g2000hsg.googlegroups.com...
> On Feb 13, 2:06 am, David BL <davi...@iinet.net.au> wrote:
> > On Feb 12, 9:53 pm, JOG <j...@cs.nott.ac.uk> wrote:
> > [snip]

> > Our point of contention is rather that I suggest that most generally
> > the data is nothing other than encoded values, and doesn't necessarily
> > convey any facts.   I'm assuming that the knowledge implicit in the
> > encoding of the data is by definition not part of the data itself,
> > whereas I think you are suggesting it is part of the data.
>
> Yes I think that's an excellent breakdown. Its all just down to where
> we draw the lines I guess...
> Brian: Data is encoded values. I need to know externally what they
> represent.
> Jim: Data is encoded values plus an denotation of what they represent.
>

David:  Data is appearances of encoded values plus a reference to an
understanding of what they represent.

This is a little hazier than Jim's definition above.  The "reference to an
understanding"  might be insufficient for formal analysis of what the data
represents,  but sufficient to persuade all interested parties that they
have a common understanding of the data that's good enough for sharing
purposes.

Our resident court jester, Dawn, no longer posts to this forum.  But I can't
resist quoting one of her (in)famous comments:  "The data means whatever the
programmers want it to mean".

The two problem words in the above are "programmers"  and "want".





0
cressey73 (124)
2/13/2008 1:54:33 PM
"David Cressey" <cressey73@verizon.net> wrote in message 
news:STAsj.5512$J93.5161@trndny08...
>
> "mAsterdam" <mAsterdam@vrijdag.org> wrote in message
> news:47b24e69$0$85790$e4fe514c@news.xs4all.nl...
>> David Cressey wrote:
>> > Robert Martin wrote:
>> >> Victor Porton said:
>> >>
>> >>> I know both object oriented programming and DB (SQL). But it seems
>> >>> that these are incompatible. Or may somebody advice how to meddle 
>> >>> them
>> >>> together?
>> >> The concepts are orthogonal.  Objects are not tables.  Tables are not
>> >> objects.  The many efforts to try to force tables and objects together
>> >> always cause trouble.  Things work better when you recognize the
>> >> benefits of tables, and the benefits of objects, and use each where
>> >> they belong rather than try to force one to use the other.
>> >>
>> >> Tables expose data and have no behavior.  Objects hide data and expose
>> >> behavior.
>> >
>> > I have a different understanding.
>> >
>> > Objects do not always hide data.  Specifically,  they pass messages to
> each
>> > other in the form of data.  Going further, objects do not "see" the
> behavior
>> > of other objects.  What they see is the data, written into messages,
> that is
>> > the result of behavior.  Seeing the result of behavior is not the same
> thing
>> > as seeing the behavior itself.
>> >
>> > One could do a data centric analysis of an object world, by analyzing
> the
>> > data passed among the objects in that world.  Such an analysis would be
> much
>> > more like the kind of analysis one makes of a database.  Or, perhaps
> more
>> > likely,  analysis of a set of information requirements that is to be
> filled
>> > by a database not yet designed.
>>
>> In ISAC (Information Systems Analysis of Change, an originally
>> Swedish school on Informatics, late 70's) there is a useful technique
>> called "precedence analysis", with 'Y'-diagrams (like genealogy
>> trees).
>>
>> It disregards all computations except as confluence nodes for data.
>> It goes backwards. Not "where does it go to", but "where does it come
>> from". Very push-through in situations with mutliple interacting (say
>> semi-autonomous) systems. I have never seen a tool supporting this -
>> it would come in handy sometimes.
>
> Your description reminds me very much of something I saw years and years
> ago.  It was in the area of field service engineers diagnosing a
> malfunctioning system down to a single board or a single component on a
> board.  The documentation of the signals being passed around by the board 
> or
> backplane were always organized by "where does the signal come from"  and
> gave information about "where does the signal go?"
>
> But the field service engineers nearly always traced signals "backwards".
> That is,  they would start from the place where the malfunction was
> observed,  and work their way upstream back to the point where the
> malfunctioning component had first injected a bad signal into the system.
>
> The way the documenters had organized the signal documentation was almost
> worthless to them.  And the way the FSEs worked was incomprehensible to 
> the
> documenters.
>

It's much quicker to use a binary search algorithm to find malfunctions. 
(That's what I did when I was in the military.)  It takes a lot less time to 
probe 5 points than 30.  Of course explaining that to someone who's always 
worked backward is a challenge--especially if it's your supervisor.

> Perhaps precedence analysis is likewise more useful for determining why a
> given system does not work  than it is for synthesizing a system that will
> work.
>
>
> 


0
brian8537 (72)
2/13/2008 2:07:02 PM
"David Cressey" <cressey73@verizon.net> writes:
> "Robert Martin" <unclebob@objectmentor.com> wrote in message
>> > We do both deal with data,
>> > don't we?
>>
>> Yes, but in very different ways, and with very different emphasis.
>>
>> OO is about structuring modules around behavior and hiding data.  The
>> structure and form of the data is hidden as deeply as possible, so that
>> no other behaviors depend upon it.
>
> If you can disregard Bob's rude tone without disregarding the
> content of his response, I ask you to do so.

     I see nothing rude in his post.  Could you please specify exactly
what you find offensive?

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc.  | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
          pjm@spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)
0
pjm (703)
2/13/2008 2:10:27 PM
"Brian Selzer" <brian@selzer-software.com> wrote in message
news:aQCsj.8653$0w.3454@newssvr27.news.prodigy.net...
>
> "David Cressey" <cressey73@verizon.net> wrote in message
> news:STAsj.5512$J93.5161@trndny08...
> >
> > "mAsterdam" <mAsterdam@vrijdag.org> wrote in message
> > news:47b24e69$0$85790$e4fe514c@news.xs4all.nl...
> >> David Cressey wrote:
> >> > Robert Martin wrote:
> >> >> Victor Porton said:
> >> >>
> >> >>> I know both object oriented programming and DB (SQL). But it seems
> >> >>> that these are incompatible. Or may somebody advice how to meddle
> >> >>> them
> >> >>> together?
> >> >> The concepts are orthogonal.  Objects are not tables.  Tables are
not
> >> >> objects.  The many efforts to try to force tables and objects
together
> >> >> always cause trouble.  Things work better when you recognize the
> >> >> benefits of tables, and the benefits of objects, and use each where
> >> >> they belong rather than try to force one to use the other.
> >> >>
> >> >> Tables expose data and have no behavior.  Objects hide data and
expose
> >> >> behavior.
> >> >
> >> > I have a different understanding.
> >> >
> >> > Objects do not always hide data.  Specifically,  they pass messages
to
> > each
> >> > other in the form of data.  Going further, objects do not "see" the
> > behavior
> >> > of other objects.  What they see is the data, written into messages,
> > that is
> >> > the result of behavior.  Seeing the result of behavior is not the
same
> > thing
> >> > as seeing the behavior itself.
> >> >
> >> > One could do a data centric analysis of an object world, by analyzing
> > the
> >> > data passed among the objects in that world.  Such an analysis would
be
> > much
> >> > more like the kind of analysis one makes of a database.  Or, perhaps
> > more
> >> > likely,  analysis of a set of information requirements that is to be
> > filled
> >> > by a database not yet designed.
> >>
> >> In ISAC (Information Systems Analysis of Change, an originally
> >> Swedish school on Informatics, late 70's) there is a useful technique
> >> called "precedence analysis", with 'Y'-diagrams (like genealogy
> >> trees).
> >>
> >> It disregards all computations except as confluence nodes for data.
> >> It goes backwards. Not "where does it go to", but "where does it come
> >> from". Very push-through in situations with mutliple interacting (say
> >> semi-autonomous) systems. I have never seen a tool supporting this -
> >> it would come in handy sometimes.
> >
> > Your description reminds me very much of something I saw years and years
> > ago.  It was in the area of field service engineers diagnosing a
> > malfunctioning system down to a single board or a single component on a
> > board.  The documentation of the signals being passed around by the
board
> > or
> > backplane were always organized by "where does the signal come from"
and
> > gave information about "where does the signal go?"
> >
> > But the field service engineers nearly always traced signals
"backwards".
> > That is,  they would start from the place where the malfunction was
> > observed,  and work their way upstream back to the point where the
> > malfunctioning component had first injected a bad signal into the
system.
> >
> > The way the documenters had organized the signal documentation was
almost
> > worthless to them.  And the way the FSEs worked was incomprehensible to
> > the
> > documenters.
> >
>
> It's much quicker to use a binary search algorithm to find malfunctions.
> (That's what I did when I was in the military.)  It takes a lot less time
to
> probe 5 points than 30.  Of course explaining that to someone who's always
> worked backward is a challenge--especially if it's your supervisor.
>

You missed the major point.



0
cressey73 (124)
2/13/2008 2:15:58 PM
David Cressey wrote:

> "Brian Selzer" <brian@selzer-software.com> wrote in message
> news:aQCsj.8653$0w.3454@newssvr27.news.prodigy.net...
> 
>>"David Cressey" <cressey73@verizon.net> wrote in message
>>news:STAsj.5512$J93.5161@trndny08...
>>
>>>"mAsterdam" <mAsterdam@vrijdag.org> wrote in message
>>>news:47b24e69$0$85790$e4fe514c@news.xs4all.nl...
>>>
>>>>David Cressey wrote:
>>>>
>>>>>Robert Martin wrote:
>>>>>
>>>>>>Victor Porton said:
>>>>>>
>>>>>>
>>>>>>>I know both object oriented programming and DB (SQL). But it seems
>>>>>>>that these are incompatible. Or may somebody advice how to meddle
>>>>>>>them
>>>>>>>together?
>>>>>>
>>>>>>The concepts are orthogonal.  Objects are not tables.  Tables are
> 
> not
> 
>>>>>>objects.  The many efforts to try to force tables and objects
> 
> together
> 
>>>>>>always cause trouble.  Things work better when you recognize the
>>>>>>benefits of tables, and the benefits of objects, and use each where
>>>>>>they belong rather than try to force one to use the other.
>>>>>>
>>>>>>Tables expose data and have no behavior.  Objects hide data and
> 
> expose
> 
>>>>>>behavior.
>>>>>
>>>>>I have a different understanding.
>>>>>
>>>>>Objects do not always hide data.  Specifically,  they pass messages
> 
> to
> 
>>>each
>>>
>>>>>other in the form of data.  Going further, objects do not "see" the
>>>
>>>behavior
>>>
>>>>>of other objects.  What they see is the data, written into messages,
>>>
>>>that is
>>>
>>>>>the result of behavior.  Seeing the result of behavior is not the
> 
> same
> 
>>>thing
>>>
>>>>>as seeing the behavior itself.
>>>>>
>>>>>One could do a data centric analysis of an object world, by analyzing
>>>
>>>the
>>>
>>>>>data passed among the objects in that world.  Such an analysis would
> 
> be
> 
>>>much
>>>
>>>>>more like the kind of analysis one makes of a database.  Or, perhaps
>>>
>>>more
>>>
>>>>>likely,  analysis of a set of information requirements that is to be
>>>
>>>filled
>>>
>>>>>by a database not yet designed.
>>>>
>>>>In ISAC (Information Systems Analysis of Change, an originally
>>>>Swedish school on Informatics, late 70's) there is a useful technique
>>>>called "precedence analysis", with 'Y'-diagrams (like genealogy
>>>>trees).
>>>>
>>>>It disregards all computations except as confluence nodes for data.
>>>>It goes backwards. Not "where does it go to", but "where does it come
>>>>from". Very push-through in situations with mutliple interacting (say
>>>>semi-autonomous) systems. I have never seen a tool supporting this -
>>>>it would come in handy sometimes.
>>>
>>>Your description reminds me very much of something I saw years and years
>>>ago.  It was in the area of field service engineers diagnosing a
>>>malfunctioning system down to a single board or a single component on a
>>>board.  The documentation of the signals being passed around by the
> 
> board
> 
>>>or
>>>backplane were always organized by "where does the signal come from"
> 
> and
> 
>>>gave information about "where does the signal go?"
>>>
>>>But the field service engineers nearly always traced signals
> 
> "backwards".
> 
>>>That is,  they would start from the place where the malfunction was
>>>observed,  and work their way upstream back to the point where the
>>>malfunctioning component had first injected a bad signal into the
> 
> system.
> 
>>>The way the documenters had organized the signal documentation was
> 
> almost
> 
>>>worthless to them.  And the way the FSEs worked was incomprehensible to
>>>the
>>>documenters.
>>>
>>
>>It's much quicker to use a binary search algorithm to find malfunctions.
>>(That's what I did when I was in the military.)  It takes a lot less time
> 
> to
> 
>>probe 5 points than 30.  Of course explaining that to someone who's always
>>worked backward is a challenge--especially if it's your supervisor.
> 
> You missed the major point.

And he ignored the potential for fan-in/fan-out.
0
bbadour (434)
2/13/2008 2:46:42 PM
"JOG" <jog@cs.nott.ac.uk> wrote in message 
news:a9f5a3a7-8330-4831-9f1d-ba16b8ccfdbe@e4g2000hsg.googlegroups.com...
> On Feb 13, 2:06 am, David BL <davi...@iinet.net.au> wrote:

[snip]

>>
>> Our point of contention is rather that I suggest that most generally
>> the data is nothing other than encoded values, and doesn't necessarily
>> convey any facts.   I'm assuming that the knowledge implicit in the
>> encoding of the data is by definition not part of the data itself,
>> whereas I think you are suggesting it is part of the data.
>
> Yes I think that's an excellent breakdown. Its all just down to where
> we draw the lines I guess...
> Brian: Data is encoded values. I need to know externally what they
> represent.
> Jim: Data is encoded values plus an denotation of what they represent.
>

Brian: Data is encoded values in a proposition that is supposed to be true.

I don't think denotation is part of data.  For example, in one year a near 
record snowfall that fell in the northeast is attributed to global warming 
even though the same amount of snow fell 100 years earlier when the globe 
wasn't as warm.

Once you attribute meaning to data, you're on a slippery slope.



0
brian8537 (72)
2/13/2008 3:17:41 PM
"David Cressey" wrote:

<snip>

> As an aside,  I'm not sure what the word "behavior" actually means in the
> OO world.  So, in what follows,  I'm going to use the two words "data" and 
> "program",  two concepts I think I do understand.  What I call "program" 
> may or may not be the same thing that you call "behavior".  I don't know, 
> but I'm prepared to learn.

I prefer the term algorithm. For me, classes are a place to bundle data with
the algorithms that are performed on the data. An instance of a class, an
object, preserves the side-effects of running an algorithm on its data. I
look at this as the object's state, i.e. objects are state machines. So the
"behavior" of an object is whatever results take place when an object runs
its data through one of its algorithms. Classes are blueprints for objects.
They should be designed in such a way so that whatever algorithms are
performed internally by an object of the class maintain the data's
invariants. I guess you could call a class a program; it's the combination
of data and algorithms.

All the above is my rather simple-minded view of things. It may, or may not,
illuminate this discussion.

<snip>

> It may also be that, if those of you who know OO but do not know DB want
> to learn anything,  you may have to learn something about data that OO 
> thinking has trained you to overlook.  You aren't really going to get rid 
> of data.
>
> What you store in a database is data.  Elsewhere in this discussion, 
> people are bloviating to beat the band about the definition of "data".  To 
> paraphrase a supreme court justice,  "I may not be able to define data, 
> but I know it when I see it." To the extent that OO is about "getting rid 
> of data",  the term "OODB" is self-contradictory.
>
> That's as far as I've gotten with this line of thought for now.  I'll have
> more later.

I'm not interested in getting rid of data. I need it! :-) But I need a place
to put the algorithms that process the data with the data itself. Classes
are a convenient place for that. If that's all I were doing, I guess you
wouldn't call it OO, but I take advantage of the facilities my programming
language provides for polymorphism. This let's me decouple objects from one
another so that parts of my applications can vary without effecting other
parts. In other words, I can vary the algorithms performed on data in one
part of my application without it effecting other areas.

At any rate, my area of programming is DSP. I write synthesizers and effect
processors. In my applications I have classes representing "filters,"
"oscillators," "envelopes," etc. Each of these classes has a set of
algorithms that process data. Using polymorphism lets me design these
classes in such a way that objects (instances of the classes) can be
switched out in a modular way, much like changing the patch cords on the old
analog synths. It works for me.



0
2/13/2008 6:25:37 PM
Leslie Sanford wrote:

> "David Cressey" wrote:
> 
> <snip>
> 
>>As an aside,  I'm not sure what the word "behavior" actually means in the
>>OO world.  So, in what follows,  I'm going to use the two words "data" and 
>>"program",  two concepts I think I do understand.  What I call "program" 
>>may or may not be the same thing that you call "behavior".  I don't know, 
>>but I'm prepared to learn.
> 
> I prefer the term algorithm. For me, classes are a place to bundle data with
> the algorithms that are performed on the data. An instance of a class, an
> object, preserves the side-effects of running an algorithm on its data. I
> look at this as the object's state, i.e. objects are state machines.

In other words, objects are variables.


  So the
> "behavior" of an object is whatever results take place when an object runs
> its data through one of its algorithms. Classes are blueprints for objects.

In other words, classes are the data types of variables and "behavior" 
denotes the operations one can perform on values and variables.


> They should be designed in such a way so that whatever algorithms are
> performed internally by an object of the class maintain the data's
> invariants. I guess you could call a class a program; it's the combination
> of data and algorithms.
> 
> All the above is my rather simple-minded view of things. It may, or may not,
> illuminate this discussion.

I think it makes things crystal clear.


> <snip>
> 
>>It may also be that, if those of you who know OO but do not know DB want
>>to learn anything,  you may have to learn something about data that OO 
>>thinking has trained you to overlook.  You aren't really going to get rid 
>>of data.
>>
>>What you store in a database is data.  Elsewhere in this discussion, 
>>people are bloviating to beat the band about the definition of "data".  To 
>>paraphrase a supreme court justice,  "I may not be able to define data, 
>>but I know it when I see it." To the extent that OO is about "getting rid 
>>of data",  the term "OODB" is self-contradictory.
>>
>>That's as far as I've gotten with this line of thought for now.  I'll have
>>more later.
> 
> I'm not interested in getting rid of data. I need it! :-) But I need a place
> to put the algorithms that process the data with the data itself. Classes
> are a convenient place for that.

Why do you assume data types have a physical location?


  If that's all I were doing, I guess you
> wouldn't call it OO, but I take advantage of the facilities my programming
> language provides for polymorphism. This let's me decouple objects from one
> another so that parts of my applications can vary without effecting other
> parts. In other words, I can vary the algorithms performed on data in one
> part of my application without it effecting other areas.
> 
> At any rate, my area of programming is DSP. I write synthesizers and effect
> processors. In my applications I have classes representing "filters,"
> "oscillators," "envelopes," etc. Each of these classes has a set of
> algorithms that process data. Using polymorphism lets me design these
> classes in such a way that objects (instances of the classes) can be
> switched out in a modular way, much like changing the patch cords on the old
> analog synths. It works for me.

Did you see the rough sketch of a circuit simulation I posted a year or 
so ago written in D ?
0
bbadour (434)
2/13/2008 6:47:26 PM
On Feb 13, 10:25=A0am, "Leslie Sanford" <jabberdab...@bitemehotmail.com>
wrote:
> I prefer the term algorithm. For me, classes are a place to bundle data wi=
th
> the algorithms that are performed on the data. An instance of a class, an
> object, preserves the side-effects of running an algorithm on its data.

Algorithm is a function. It might be convenient to split this function
into many, introduce an auxiliary structure that captures
intermediatory steps of the algorithm.  Bundling that structure with
functions is a convenience -- no disagrement there.

> I take advantage of the facilities my programming
> language provides for polymorphism.

In my experience polymorphism ir rare if ever needed. I can't remember
when I wrote a loop that traverses a heterogenous list. In rare cases
when I did it there was something wrong with the design, so that the
code has been refactored and simplified, and plymorphism and abstract
classes were gone. The last example, a parser able to process any
context-free grammar. Natural design: an abstract class with two
implementations: CYK algorithm and Earley. In practice, however, I
never being able to perfect Earley to be able to compete with CYK, so
Earley just become a dead code.

Likewise, I fail to see a really convincing example in the GUI area. A
mosue event is broadcasted to a list of widgets, so that the "right"
widget knows how to respond? Excuse me, but spamming all the widgets
is pretty inefficient way to deliver a message. In most cases it is
pretty clear what widget should respond to a message, and database
area has some pretty advanced methods how to select a set of things
based upon some criteria.

> At any rate, my area of programming is DSP. I write synthesizers and effec=
t
> processors. In my applications I have classes representing "filters,"
> "oscillators," "envelopes," etc. Each of these classes has a set of
> algorithms that process data. Using polymorphism lets me design these
> classes in such a way that objects (instances of the classes) can be
> switched out in a modular way, much like changing the patch cords on the o=
ld
> analog synths. It works for me.

I suggest that abstract classes genesis is a result of poor
abstraction and speculative generality. In DSP area there is plenty of
concrete classes like Matrices, Vectors -- I fail to see what you gain
by making these abstract. Perhaps something more sophisticated like
Wavelet may benefit of abstraction, e.g HaarWavelet,
DebuchetesWavelet? Well, I can't imagine anybody using HaarWavelet for
anything other than textbook example, so the point remains moot.

0
2/13/2008 7:28:06 PM
ram@zedat.fu-berlin.de (Stefan Ram) writes:
>shirt.makeSelfClean()

  Or,

shirt.wash()

  . This is a noun (�shirt�) and a verb (�wash�).

  Could one imagine a world where natural language linguistics
  become so prevalent in user interfaces (because they are so
  natural) that one day computers have a �verb� and a �noun� key?

  This is the keyboard from the Apollo computer panel of 1969:

http://infolab.stanford.edu/pub/voy/museum/pictures/display/0-2-ApolloPanel.jpg

  Commands looked like

      �V21 N27E 10E�

http://www.ibiblio.org/apollo/

  But is this object-oriented at all?

  After all, a classical command like

cat tmp.txt

  also has a verb and a noun. 

  Object-orientation starts when a single verb can be 
  used metaphorically for multiple types of nouns and
  still has the same meaning (as a metaphor).  

  So,

textedit tmp.txt
picedit  tmp.pic
binedit  tmp.bin

  is not object-oriented, while

edit tmp.txt
edit tmp.pic
edit tmp,bin

  is object-oriented if �edit� selects the appropriate editor by
  the file type and can be extended to new types without the
  need to modify existing code.

  So, object-orientation

    0 - decouples verbs from noun types for metaphoric use, and

    1 - splits verb source code units into separate units
        for each noun type, so that they can be changed
        independently.

  In SQL, there is something similar: One can apply the verb
  �SELECT� to any table, whether it is a base table or a view,
  even if the implementation of these two selections differs.

  But this is only �object-based�, as it is sometimes called,
  because it fulfills only �0� (in some case). It can not
  fulfill �1�, because one can not extend verbs in SQL.
  (One can define views, but this are more like nouns.)

  But one can imagine an object-oriented language in a database
  system, where base tables and views are objects and verbs can
  be defined for those. A relation can be regarded as the type
  of its elements (rows).

  An object-oriented database operation:

      for each customer c do sendPresentTo( c );

  , where �customer� is a table containing customers of
  different types (men, women, and children) and �sendPresent�
  has a different implementation for each type of customer.

0
ram (2986)
2/13/2008 8:26:49 PM
On Wed, 13 Feb 2008 02:25:15 +0100, mAsterdam wrote:

> Dmitry A. Kazakov schreef:
>> mAsterdam wrote:
>>> Dmitry A. Kazakov wrote:
>>>> mAsterdam wrote:
>>>>
>>>>> In your extension, you appear to map your slaves to data.
>>>>> Slaves behave, objects do. Data doesn't.
>>>> If data did not behave how would it be possible to use data?
>>> Being active is not, as your question presupposes,
>>> a prerequisite to being used.
>> No, I didn't meant that. Behavior is independent on who acts on whom.
>> Consider it as a list of all things you could ever do with data.
> 
> It is not clear what you are asking with
> "If data did not behave how would it be possible to use data?"
> Please rephrase.

use : data -> something

The mapping "use" is behavior of data x something (=> it is also behaviour
of data.)

>> But why is recording essential? 
> 
> To facilitate the sharing of observations.

So, we have now:

1. observations
2. entities (busy with sharing observations)
3. actions (state?) of sharing something (like observations)
4. identity (of "same" thing being shared/observed)
5. identity (of "different" entities observing "same" thing)
 
Isn't it a bit too much in order to define an allegedly fundamental thing
called data?

This question is only relevant if you are going to define 1-5 within your
formal system, provided that were possible. In case it rather falls under
the category of meaning (=hand waving), then that is exactly same trick I
used in my definition. I just said that in the formal system there are
values with some semantics attached to, which (semantics) lies outside that
system. Call it recording, encoding, observation, sharing whatsoever. All
this is irrelevant to what we are going to do with data.

>> Or to put it otherwise, can you consider unrecorded,
>> not memorized data? 
> 
> No.

Bad. It means that you have to formalize "memorize" in some quite tricky
way. Honestly I don't know what could be the difference between "memorized
Pi", "not-yet-memorized Pi", "once-memorized-but-forgotten-by-now Pi" and
so on.

>> May I translate data into a different
>> representation and then erase the original record? 
>> Will data still be there?
> 
> Iff it conveys the same facts as the original record, sure.

OK, that means that data = facts + record medium of:

D = (F, R)

It also states that

F1 = F2 => D1 = D2

Why should I care about R, then? Pi is Pi and retains all its property
independently on where and how you write it (or not). Let's declare F = D
and forget about R.

(BTW, some of DB people regularly posting to comp.object vehemently denied
that DB is about persistency. Could you clarify it?)

>> A formal system operates on data
>> without any clue of the meaning of.
> 
> I think that is to crude.
> The meaning itself is informal, hence inherently impossible to fully
> access from within the formal system (I think we agree on that).
> However, without meaning to associate it with, a formalism is useless.

It is a tautology. You say that without meaning there is no meaning. Yes,
we cannot reason about meaning while staying within the same formal system.
Because you seem to bind data with a meaning (as I do), that immediately
kicks the notion of data out of the formal system. So data do not exist
there. Which is all my point! No data, nothing to worry about.

>>>> (The type of values describes the behavior of data.)]
>>> How? I don't understand what you are saying here -
>>> this may be a language thing, though.
>>> An example might clarify.
>> 
>> Consider the value 1. It has no behavior (and no use) so long you don't
>> tell us its type. It you say that 1 is an integer, then its behavior will
>> include "has negative inverse." If the type is Positive, then the behavior
>> will be "no negative inverse", "can be squared in R" etc.
> 
> Is this what you mean: All operations for which the set is closed?

All operations at all. Actually all provable predicates involving at leas
one value of the given type.

> If so - how is this behaviour of the data itself?

I don't know what you mean here. What is "data itself"? Or possibly "data
for others"?

>> (Behavior does not presume anything like tiny cogwheels hidden inside 1.
>> The cogwheels are rather big and all outside (:-))
>> 
>>>> If the ultimate goal is same, then managing the thing called data is mere
>>>> one possible thread of the process.
>>> That does not follow.
>>> Furthermore: after the process stops, the data remains.
>> 
>> Really? You wrote just above:
>> 
>> "it only makes sense to talk about data when the medium on
>> which they are recorded is readable by some mechanism to
>> achieve electronic representation, but that is not inherent
>> to data."
>> 
>> Which is all true. So let you have a medium without a process that can read
>> it, what did remain of data? It what sense do data remain? As a possibility
>> to start a process by some other process which still runs? Consider it on
>> the example with 1.
> 
> In that sense all phonographs are part of the same process.
> It's process, Jim, but not as we know it. Define process.

I just took your "readable by some mechanism" and named it "process." I
wanted to know how do you want to distinguish "readable" and "unreadable
data." I concede it was a leading question. The suggested answer is: if the
thing was ever readable, it will ever be. You can always repeat the things
you did once in some equivalent way, at least in mathematics you can.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/13/2008 9:30:17 PM
Stefan Ram wrote:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>=20
>>shirt.makeSelfClean()
>=20
>=20
>   Or,
>=20
> shirt.wash()
>=20
>   . This is a noun (=C2=BBshirt=C2=AB) and a verb (=C2=BBwash=C2=AB).

It is also a verb (shirt) and a noun (wash). A human has experience to=20
suggest that washes do not don shirts on themselves or on others. To the =

formal system, neither is a noun or a verb. Each is a symbol.

Assuming you use more-or-less conventional OO notation, the symbols form =

a pattern of symbol1.symbol2(...) which is syntactically correct=20
provided symbol1 denotes a known variable and symbol2 denotes an=20
operation defined to accept an argument variable of that type in place=20
of its first (implicit) reference parameter.

[remaining nonsense snipped]

0
bbadour (434)
2/13/2008 9:35:04 PM
On Tue, 12 Feb 2008 20:48:47 -0800 (PST), David BL wrote:

> Objects are said to have identity, state and behavior.   The idea that
> an object can (always) be thought of as a (data) variable that can be
> assigned a (data) value reveals a complete lack of understanding of
> OO.

> Bob's confusion between the concepts of object state versus object
> value also leads him to misunderstand the significance of
> encapsulation in the context of OO.

I hate to agree with Bob Badour, but the notion of object is indeed
superfluous. It is enough to have value, type, variable. Type has behavior.
Variable has state. Identity can be attributed to a variable (the name of)
or a value (the type of) or a type (the behavior of, or the name of, if
named). What is specific to OO, that polymorphic values have identities of
the corresponding specific types, which makes dispatch possible.

[ Your note about assignment is IMO absolutely correct. Bob's lack of
understanding lies in considering assignment as something God-given.
Assignment is a part of behavior of a type. A type can lack this behavior.
For example, either a random generator or a real-time clock cannot be
assigned. This is not because some hideous OO guys have hidden assignment
from us. It is because such things fundamentally cannot have any.] 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/13/2008 10:10:59 PM
Dmitry A. Kazakov wrote:
> mAsterdam wrote:
>> Dmitry A. Kazakov wrote:
>>> mAsterdam wrote:
>>>> Dmitry A. Kazakov wrote:
>>>>> mAsterdam wrote:
>>>>>
>>>>>> In your extension, you appear to map your slaves to data.
>>>>>> Slaves behave, objects do. Data doesn't.
>>>>> If data did not behave how would it be possible to use data?
>>>> Being active is not, as your question presupposes,
>>>> a prerequisite to being used.
>>> No, I didn't meant that. Behavior is independent on who acts on whom.
>>> Consider it as a list of all things you could ever do with data.
>> It is not clear what you are asking with
>> "If data did not behave how would it be possible to use data?"
>> Please rephrase.
> 
> use : data -> something
> 
> The mapping "use" is behavior of data x something (=> it is also behaviour
> of data.)

So what is it you are asking? This doesn't even look like a question.
Should I unsnip? Remember that this is about what of objects and data 
is the better map to slaves in your metaphor extension.

Your snipping style is not nice to deal with.

Dmitry, why are you engaging in this thread?

>>> But why is recording essential? 
>> To facilitate the sharing of observations.
> 
> So, we have now:
> 
> 1. observations
> 2. entities (busy with sharing observations)
> 3. actions (state?) of sharing something (like observations)
> 4. identity (of "same" thing being shared/observed)
> 5. identity (of "different" entities observing "same" thing)

No we don't. You don't have anything here, because you reject the 
existence of data. Beyond some agreement on that any attempt at 
formalization of it is futile. You asked my opinion, you reflected it
against some of your preconceptions about what to formalize
and what not, and something comes out.
Now there may be something sensible here, but without something of 
substance I have no way of telling. Seen as a proposal for additional 
shared primitives, add "0. To share." and for now forget about 2, 4 and 5.

> Isn't it a bit too much in order to define an allegedly fundamental thing
> called data?
> 
> This question is only relevant if you are going to define 1-5 within your
> formal system, provided that were possible. 

'your'? No.

Without agreed upon denotation it is just gibberish.
You do not accept that there is data, but you do appear to have enough 
basis to start formalizing.
Which primitive elements does your formal system have?

> In case it rather falls under
> the category of meaning (=hand waving), then that is exactly
> same trick I used in my definition. 

I am trying to uncover, not to cover up.

> I just said that in the formal system there are
> values with some semantics attached to, which (semantics) lies outside that
> system. Call it recording, encoding, observation, sharing whatsoever. All
> this is irrelevant to what we are going to do with data.
> 
>>> Or to put it otherwise, can you consider unrecorded,
>>> not memorized data? 
>> No.
> 
> Bad. It means that you have to formalize "memorize" in some quite tricky
> way. Honestly I don't know what could be the difference between "memorized
> Pi", "not-yet-memorized Pi", "once-memorized-but-forgotten-by-now Pi" and
> so on.

Are you suggesting π is data?

>>> May I translate data into a different
>>> representation and then erase the original record? 
>>> Will data still be there?
>> Iff it conveys the same facts as the original record, sure.
> 
> OK, that means that data = facts + record medium of:
> 
> D = (F, R)

Guessing about your notation as D denotes Data, F denotes Facts, R is 
the requirement that the fact is recorded, R is just 1.

> It also states that
> 
> F1 = F2 => D1 = D2

Almost. Within a shared set of observations,

  F₁=F₂ ⇔ D₁=D₂

..

> Why should I care about R, then? 

Why do you? I don't yet.
For now, I don't care about its internals,
just that it exists so we have a way to record facts.

> Pi is Pi and retains all its property
> independently on where and how you write it (or not). Let's declare F = D
> and forget about R.

For now - ok.

> (BTW, some of DB people regularly posting to comp.object vehemently denied
> that DB is about persistency. Could you clarify it?)

No, not at this point. This is best left to a thread on its own.

Disclosure: I have in the past vehemently denied that DB is about 
persistency, and I have yet to see a coherent argument that
it would be. Assume for now it is a belief I turned to
after experiencing the way the smalltalk system image works and 
Rumbaugh's remarks on persistency.

>>> A formal system operates on data
>>> without any clue of the meaning of.
>> I think that is to crude.
>> The meaning itself is informal, hence inherently impossible to fully
>> access from within the formal system (I think we agree on that).
>> However, without meaning to associate it with, a formalism is useless.
> 
> It is a tautology. You say that without meaning there is no meaning. 

No, though your rephrase is (a tautology).
I'll state it differently.

Without shared, informal denotations, any formalism is useless crap.
I don't want it and you don't want it.

> Yes, we cannot reason about meaning while staying 
> within the same formal system.
> Because you seem to bind data with a meaning (as I do), that immediately
> kicks the notion of data out of the formal system. So data do not exist
> there. Which is all my point! No data, nothing to worry about.

And the result is a hermetic system as useful as solipsism.
Have some fun there! I'm out waiting until you are bored of it.

>>>>> (The type of values describes the behavior of data.)]
>>>> How? I don't understand what you are saying here -
>>>> this may be a language thing, though.
>>>> An example might clarify.
>>> Consider the value 1. It has no behavior (and no use) so long you don't
>>> tell us its type. It you say that 1 is an integer, then its behavior will
>>> include "has negative inverse." If the type is Positive, then the behavior
>>> will be "no negative inverse", "can be squared in R" etc.
>> Is this what you mean: All operations for which the set is closed?
> 
> All operations at all. Actually all provable predicates involving at leas
> one value of the given type.
> 
>> If so - how is this behaviour of the data itself?
> 
> I don't know what you mean here. What is "data itself"? Or possibly "data
> for others"?

requote:
 >>>>> (The type of values describes the behavior of data.)]


>>> (Behavior does not presume anything like tiny cogwheels hidden inside 1.
>>> The cogwheels are rather big and all outside (:-))
>>>
>>>>> If the ultimate goal is same, then managing the thing called data is mere
>>>>> one possible thread of the process.
>>>> That does not follow.
>>>> Furthermore: after the process stops, the data remains.
>>> Really? You wrote just above:
>>>
>>> "it only makes sense to talk about data when the medium on
>>> which they are recorded is readable by some mechanism to
>>> achieve electronic representation, but that is not inherent
>>> to data."
>>>
>>> Which is all true. So let you have a medium without a process that can read
>>> it, what did remain of data? It what sense do data remain? As a possibility
>>> to start a process by some other process which still runs? Consider it on
>>> the example with 1.
>> In that sense all phonographs are part of the same process.
>> It's process, Jim, but not as we know it. Define process.
> 
> I just took your "readable by some mechanism" and named it "process." 

Don't.

> I wanted to know how do you want to distinguish "readable" and "unreadable
> data." I concede it was a leading question. The suggested answer is: if the
> thing was ever readable, it will ever be. You can always repeat the things
> you did once in some equivalent way, at least in mathematics you can.

Is it fun?


--
What you see depends on where you stand.
0
mAsterdam (155)
2/14/2008 12:14:13 AM
On Feb 14, 7:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 12 Feb 2008 20:48:47 -0800 (PST), David BL wrote:
> > Objects are said to have identity, state and behavior.   The idea that
> > an object can (always) be thought of as a (data) variable that can be
> > assigned a (data) value reveals a complete lack of understanding of
> > OO.
> > Bob's confusion between the concepts of object state versus object
> > value also leads him to misunderstand the significance of
> > encapsulation in the context of OO.
>
> I hate to agree with Bob Badour, but the notion of object is indeed
> superfluous. It is enough to have value, type, variable. Type has behavior.
> Variable has state. Identity can be attributed to a variable (the name of)
> or a value (the type of) or a type (the behavior of, or the name of, if
> named). What is specific to OO, that polymorphic values have identities of
> the corresponding specific types, which makes dispatch possible.

You appear to agree with Bob, but nothing could be further from the
truth.

Have you read the characterisations of value, variable and type by
C.Date?  They are very different to your above descriptions.

value :  doesn't exist in time or space.  Immutable
variable : can be assigned a value
type :  set of values plus operations on those values

C.Date ignores the Liskov Substitution Principle (LSP) and states that
a circle is an ellipse, and that a coloured rectangle cannot be a
subtype of a rectangle.

Given Date's definitions of variable and type, his conclusions are
sensible.   I recommend all OO programmers read C.Date's work on sub-
typing.

In my opinion an OO language should properly support value-types in
the way described by Date.   Unfortunately I don't know of any that
do.  Of course it should also support the conventional OO notion of
typing which is based on contractual guarantees of behavior and hence
leads to the LSP for sub-typing.

Date's notion of sub-typing leads to a powerful form of reuse.  In a
language like C++ I can imagine it would allow algorithms to be
compiled into very efficient machine code in a similar manner to
parametric polymorphism.


> [ Your note about assignment is IMO absolutely correct. Bob's lack of
> understanding lies in considering assignment as something God-given.
> Assignment is a part of behavior of a type. A type can lack this behavior.
> For example, either a random generator or a real-time clock cannot be
> assigned. This is not because some hideous OO guys have hidden assignment
> from us. It is because such things fundamentally cannot have any.]

He thinks assignment is God-given because *by definition* a variable
is something that can be assigned a value.


0
davidbl (206)
2/14/2008 1:21:42 AM
On Feb 13, 9:22 pm, "Brian Selzer" <br...@selzer-software.com> wrote:
> "David BL" <davi...@iinet.net.au> wrote in message
>
> news:8c33acce-694e-4edf-8758-7b296ea59557@s8g2000prg.googlegroups.com...
>
>
>
>
>
> > On Feb 12, 10:49 am, "Brian Selzer" <br...@selzer-software.com> wrote:
> >> "JOG" <j...@cs.nott.ac.uk> wrote in message
>
> >>news:27321846-87df-4f21-a7bd-382d8b7d6605@m34g2000hsf.googlegroups.com...
>
> >> > On Feb 12, 1:01 am, JOG <j...@cs.nott.ac.uk> wrote:
> >> >> On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>
> >> >> > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> >> >> > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>
> >> >> > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> >> >> > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>
> >> >> > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> >> >> > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov"
> >> >> > > > > > > <mail...@dmitry-kazakov.de>
> >> >> > > > > > > wrote:
> >> >> > > > > > > > [What is data, in your opinion?
>
> >> >> > > > > > > Data. Lots of datum - from latin, meaning statement of
> >> >> > > > > > > fact.
> >> >> > > > > > > Predicate
> >> >> > > > > > > and value in FOL.  A value without description is of
> >> >> > > > > > > course
> >> >> > > > > > > just
> >> >> > > > > > > noise.
>
> >> >> > > > > > Latin datum is past participle of dare, "to give".  What
> >> >> > > > > > make
> >> >> > > > > > you say
> >> >> > > > > > data is necessarily a set of propositions?
>
> >> >> > > > > The OED. "Facts, esp. numerical facts, collected together for
> >> >> > > > > reference or information." The etymology stems from 'dare',
> >> >> > > > > because
> >> >> > > > > facts are always communicated or "given". I understand of
> >> >> > > > > course
> >> >> > > > > that
> >> >> > > > > the term is thrown around wantonly and ambiguosly nowadays,
> >> >> > > > > but
> >> >> > > > > as
> >> >> > > > > data theorists, we shouldn't be party to that imo ;)
> >> >> > > > > > Are you suggesting a value
> >> >> > > > > > is meaningless without a proposition?  Why can't a datum
> >> >> > > > > > just
> >> >> > > > > > be a
> >> >> > > > > > value?
>
> >> >> > > > > Because ta value has to be associated with something.
> >> >> > > > > Hofstadter
> >> >> > > > > gave
> >> >> > > > > a good example of this with the groove modulations on a vinyl
> >> >> > > > > record.
> >> >> > > > > To us they are (musical) data, to an alien not knowing their
> >> >> > > > > context,
> >> >> > > > > it is not. You need the context.
>
> >> >> > > > > > Wouldn't you say a recorded image is data?
>
> >> >> > > > > Of course, so long as I know it's an image. If its just ones
> >> >> > > > > and
> >> >> > > > > zero's stored in a computer, without anyway of telling they
> >> >> > > > > represent
> >> >> > > > > a picture, then it is simply noise.
>
> >> >> > > > Let's indeed assume we know how to interpret the 1's and 0's as
> >> >> > > > an
> >> >> > > > image.  So what have we got?  Nothing but a *value*.
>
> >> >> > > No, you now have a value with applied context. That creates a
> >> >> > > fact.
> >> >> > > You now therefore have data. It's simple to show - consider
> >> >> > > "1000001".
> >> >> > > Thats currently a value, but its not data. Its only data when I
> >> >> > > store
> >> >> > > it, and state one of the following:
>
> >> >> > > "100001" is a text string
> >> >> > > "100001" is an integer (i.e. 65)
> >> >> > > "100001" is an ascii character (i.e. A)
> >> >> > > etc..
>
> >> >> > These "facts" are all tautologies that are true whether you record
> >> >> > them or not.
>
> >> >> I'm not seeing whats so controversial or difficult about the fact that
> >> >> "10001" is just a meaningless binary value until you give it a
> >> >> context. It seems somewhat obvious to me.
>
> >> >> > I dispute your premise that the purpose of the data in
> >> >> > this case is to state a fact that is known a-priori to be true.
>
> >> >> A Datum is a given fact. That's what the word means formally. I have
> >> >> said nothing more, and I have no idea what you are on about talking
> >> >> about "the purpose of data".
>
> >> >> > If that is its purpose then it conveys precisely zero information.
>
> >> >> > > > We can display
> >> >> > > > it.  We can comment on whether we like it - even if we haven't a
> >> >> > > > clue
> >> >> > > > where it came from.  But I don't see any sense in which the
> >> >> > > > image
> >> >> > > > value gives us any statements of fact beyond the specification
> >> >> > > > of a
> >> >> > > > value.  A value simply "is".
>
> >> >> > > > I would suggest that a lot of the data in the world is
> >> >> > > > characterised
> >> >> > > > more closely as "interesting values" than collections of
> >> >> > > > propositions.
>
> >> >> > > You cannot store these interesting values without implicitly
> >> >> > > stating
> >> >> > > some fact about them.
>
> >> >> > By definition, when a value is specified, its type is specified as
> >> >> > well (except possibly if type inheritance is supported).
>
> >> >> > C. Date states the following in "Introduction to Database Systems",
> >> >> > section 5.2, and subsection titled "Values and Variables are typed":
>
> >> >> >     "Every value has ... some type...Note that,
> >> >> >     by definition, a given value always has
> >> >> >     exactly one type, which never changes.
> >> >> >     [footnote:  except possibly if type
> >> >> >     inheritance is supported]"
>
> >> >> > When a particular value like the integer 73 is specified, there is
> >> >> > no
> >> >> > implicit fact being specified.   The statement that the integer 73
> >> >> > exists in any absolute sense is entirely metaphysical and
> >> >> > meaningless
> >> >> > within computer science.
>
> >> >> So you just wriite "73" down and are telling me its a datum? I'm
> >> >> pretty sure that's what we call a "value", not data. I'm wondering if
> >> >> you are misconstruing my point - "73" is only data when you apply some
> >> >> context to it, like saying this its someones room number, or today's
> >> >> average temperature, or the amount of red in a certain pixel of an
> >> >> image (and yes, those are then facts).
>
> >> > Let me clarify the distinction I'm making David:
> >> > "RED" is a value.
> >> > "The first pixel in the image is RED" is a datum.
>
> >> > That can't be that contentious...can it?
>
> >> Isn't a datum an atomic value?  I think I remember reading somewhere,
> >> "Each
> >> and every datum (atomic value)...."
>
> >> I think the distinction you want to make is whether or not some
> >> individual
> >> that is represented by the value 73 actually exists.  For that there
> >> needs
> >> to be a context.  If the value 73 from the domain of integers is named in
> >> a
> >> tuple in a relation in a database, then clearly that particular instance
> >> of
> >> the value 73 has a context and thus maps to an actual individual in the
> >> picture of the universe of discourse that is the database.  Clearly the
> >> act
> >> of storing the value 73 gives it context.  Without context, 73 is a
> >> possible
> >> value, not an actual value.
>
> > Instance of a value? Context of a value?  Possible value?  Actual
> > value?  I cannot make sense of that.
>
> Perhaps I should clarify:  A database is a proposition--a picture of the
> universe.  There can be many possible pictures of the universe, but only one
> is supposed to be true.  A value can appear in many possible pictures, so it
> follows that a value can appear in a possible picture that is supposed to be
> true or in a possible picture that is not supposed to be true, /or both/.

Yes, a value can appear in many different contexts.   In this
discussion I think we need to be very careful with distinguishing
between a value, and the appearance (ie encoding) of a value in a
particular context.

> If a value is a fact, how, then, can it be both true and not true?

What does it mean to say a value is a fact?

> An
> instance of a value, a value in context--the association of a value with a
> picture of the universe--on the other hand, /can/ be a fact because that
> association can be with a possible picture that is supposed to be true or
> with a possible picture that is not supposed to be true, /but not both/.

I think I understand what you are saying, but I would say it slightly
differently.  Rather than "instance of value" I would say "appearance
of value", but only because I'm so used to seeing "instance" used in
the context of "instance of a type", but maybe that's my OO background
showing through.  Instantiation also makes me think of the terminology
used for binding variables to values such as when one says a
proposition is an instantiation of a predicate.

I also don't see how an appearance of a value itself generally
represents a fact (even though it's tied to a context).   I can see
it's true if you assume the value is a tuple within a relation, but
was that your intention?

> A value that appears in any possible picture of the universe is a possible
> value.  A value that appears in the possible picture of the universe that is
> supposed to be true is an actual value.

You've lost me.

> Thus a value is just a value without some context.  Once a value is given
> context, such as being stored in a database, or written down, or whatever,
> then it can be considered information.

I think I know what you're saying but I don't like the way you say
it.  It doesn't make sense to say a value is given a context.   A
value like the integer 73 doesn't float around and suddenly drop into
your database!  The value just "is".  A database may contain any
number of appearances or encodings of the value 73, but the abstract
number itself doesn't have a context.  It is the appearance of the
value that has a context (and can be considered information within
that context)

> Each atomic value that is in the
> database is a datum simply because it is /in/ the database.

Agreed.  An appearance (ie encoding) of a value has a context and is
data.

0
davidbl (206)
2/14/2008 2:31:32 AM
On Feb 13, 9:56 pm, JOG <j...@cs.nott.ac.uk> wrote:
> On Feb 13, 2:06 am, David BL <davi...@iinet.net.au> wrote:
>
>
>
>
>
> > On Feb 12, 9:53 pm, JOG <j...@cs.nott.ac.uk> wrote:
> > [snip]
> > > Consider /unallocated/ RAM in your PC. Look at 5 contiguous bits at
> > > random. Are you telling me that the binary number you are looking at
> > > is "data"? I'd accept that it is a value (albeit a meaningless one)
> > > but "data"? You really think that?
>
> > No I don't.
>
> > When data is recorded on some medium there is a lot of implicit
> > *knowledge* about how it has been encoded.  This knowledge has to
> > account for all sorts of details, such as what designates a 1 versus a
> > 0.   How many bits in a word?  What order do they appear in?  Is there
> > an address bus?  How is the address bus organised?  The binary
> > encoding is only a tiny part of it.  Obviously we both agree that all
> > that knowledge is implicit in correctly decoding the data.
>
> Yes I broadly agree apart from on one key matter (there's a suprise
> eh) - "knowledge is implict". I contend the exact opposite, and this
> is my whole point really. The knowledge required must be explicit.
> That's what makes otherwise random noise, or values, data.  In the
> case of a scientist log book for example what the data means is
> explicit in a title at the top of the page or in the scientist's
> head.

You can't make the knowledge explicit because you can't formalise it.

> Another example:
> "todays lottery numbers: 23, 34, 17"
> "experimental reults: 23, 34, 17"
>
> Same values, different data. If you agree with this statement then
> values != data surely?

You seem to have forgotten that I said data was associated with the
appearance (ie encoding) of values.   Encodings have a context, and
values do not.  We don't disagree on whether data is associated with
encodings.  Rather we disagree on what is being encoded.  I say data =
encoded values.  (I think) you say data = encoded facts.

> > Our point of contention is rather that I suggest that most generally
> > the data is nothing other than encoded values, and doesn't necessarily
> > convey any facts.   I'm assuming that the knowledge implicit in the
> > encoding of the data is by definition not part of the data itself,
> > whereas I think you are suggesting it is part of the data.
>
> Yes I think that's an excellent breakdown. Its all just down to where
> we draw the lines I guess...
> Brian: Data is encoded values. I need to know externally what they
> represent.
> Jim: Data is encoded values plus an denotation of what they represent.

Did you mean to say Brian?

Do you agree you cannot formalise what the values represent?

> > I would prefer to say that the knowledge of the encoding (the
> > "protocol") exists independently of the recorded data (or even the
> > particular instance of the media it is recorded on).   For example I
> > don't want to create a new file format for every file.
>
> > > > > > I dispute your premise that the purpose of the data in
> > > > > > this case is to state a fact that is known a-priori to be true.
>
> > > > > A Datum is a given fact. That's what the word means formally. I have
> > > > > said nothing more, and I have no idea what you are on about talking
> > > > > about "the purpose of data".
>
> > > > Let me use an example:  I give you a disk with some data, tell you a-
> > > > priori that it records a string, describe the format and you are able
> > > > to determine that the recorded value is a poem
>
> > > >     "Is it binary or is it data?
> > > >      Is it info or knowledge,
> > > >      or is it wisdom -
> > > >      the whole enchilada?"
>
> > > Thats a value imo, and its only data if we say "The file myPoem.txt
> > > contains 'Is it binary or is it...'".
>
> > I don't know what that means or what distinction you are making.   I'm
> > very suspicious of introducing a proposition that is referring by name
> > to the file.  Names don't have absolute meaning.  What is the context
> > for this proposition?
>
> > > I do realise that the
> > > definitions I am suggesting as formal are at odds to the handy wavy,
> > > nebulous way we throw around terms such as 'data', 'data model', etc.
>
> > > As proof (!) consider your above example if you placed the poem
> > > written on paper in front of me. Are you telling me that is data?
> > > Course not, its just a poem written down - a value. So then what is
> > > the difference between this and your example on a disk? That its
> > > encoded in binary?
>
> > Since this is a computer science discussion group I'm happy to narrow
> > the definition of data to encodings of values that are intended for
> > both reading and writing by a computer.
>
> > > > Note that no additional context has been provided.  I would say the
> > > > purpose of the data was to convey a value, but not to convey a fact.
>
> > > > > > If that is its purpose then it conveys precisely zero information.
>
> > > > > > > > We can display
> > > > > > > > it.  We can comment on whether we like it - even if we haven't a clue
> > > > > > > > where it came from.  But I don't see any sense in which the image
> > > > > > > > value gives us any statements of fact beyond the specification of a
> > > > > > > > value.  A value simply "is".
>
> > > > > > > > I would suggest that a lot of the data in the world is characterised
> > > > > > > > more closely as "interesting values" than collections of
> > > > > > > > propositions.
>
> > > > > > > You cannot store these interesting values without implicitly stating
> > > > > > > some fact about them.
>
> > > > > > By definition, when a value is specified, its type is specified as
> > > > > > well (except possibly if type inheritance is supported).
>
> > > > > > C. Date states the following in "Introduction to Database Systems",
> > > > > > section 5.2, and subsection titled "Values and Variables are typed":
>
> > > > > >     "Every value has ... some type...Note that,
> > > > > >     by definition, a given value always has
> > > > > >     exactly one type, which never changes.
> > > > > >     [footnote:  except possibly if type
> > > > > >     inheritance is supported]"
>
> > > > > > When a particular value like the integer 73 is specified, there is no
> > > > > > implicit fact being specified.   The statement that the integer 73
> > > > > > exists in any absolute sense is entirely metaphysical and meaningless
> > > > > > within computer science.
>
> > > > > So you just wriite "73" down and are telling me its a datum? I'm
> > > > > pretty sure that's what we call a "value", not data.
>
> > > > C.Date distinguishes between a value (that by definition doesn't exist
> > > > in time and space), versus the *appearance* of a value which appears
> > > > in time and space and is encoded in a particular way.
>
> > > Is this what your view of the terms is based upon?
>
> > These definitions seems reasonable to me.
>
> This seem overly philosophical to me. Surely we don't need metaphysics
> to know that if someone hands me a bit of paper with: "1.00, 0.376 and
> 0.904" on it, well that's just a list of values. However if if someone
> hands you a bit of paper with "Surface Gravity - Earth:1.00, Mars:
> 0.376 and Venus:0.904", or tells you those denotations,  then we have
> data ;)

You have repeatedly chosen examples that suit your argument, whereas
according to our disagreement only I that have that privilege!

Jim:
    In all examples, data is useful to the recipient and
    represents facts

David:
    1) In all examples, data is useful to the recipient and
       represents values; and
    2) There exists example where data is useful to the recipient
       and doesn't represent facts

Since a tuple of a relation is a value and it also represents a fact
it is clear that my definition of data encompasses yours.

We can both easily think of examples where (so called) data is useless
to the recipient.  Let's agree and say that's not actually data.  That
only leaves one possibility for proof by counter example:  I provide
an example where the data is useful to the recipient yet doesn't
convey any facts.   The sending of a poem or an image without any
additional context is an example.

People download web pages (which are basically just encoded values)
into their WWW browsers all the time without any more context than
following a hyperlink.  They often don't find out whether it's useful
or relevant until they read it.   In many respects the WWW can be
regarded as a big collection of encoded "interesting values" indexed
by content without any additional context.

0
davidbl (206)
2/14/2008 3:52:38 AM
"David BL" <davidbl@iinet.net.au> wrote in message 
news:3f443a68-9822-4099-9b89-e62e76e0d197@d70g2000hsb.googlegroups.com...
> On Feb 13, 9:22 pm, "Brian Selzer" <br...@selzer-software.com> wrote:
>> "David BL" <davi...@iinet.net.au> wrote in message
>>
>> news:8c33acce-694e-4edf-8758-7b296ea59557@s8g2000prg.googlegroups.com...
>>
>>
>>
>>
>>
>> > On Feb 12, 10:49 am, "Brian Selzer" <br...@selzer-software.com> wrote:
>> >> "JOG" <j...@cs.nott.ac.uk> wrote in message
>>
>> >>news:27321846-87df-4f21-a7bd-382d8b7d6605@m34g2000hsf.googlegroups.com...
>>
>> >> > On Feb 12, 1:01 am, JOG <j...@cs.nott.ac.uk> wrote:
>> >> >> On Feb 11, 4:10 pm, David BL <davi...@iinet.net.au> wrote:
>>
>> >> >> > On Feb 11, 11:08 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>
>> >> >> > > On Feb 11, 12:44 pm, David BL <davi...@iinet.net.au> wrote:
>>
>> >> >> > > > On Feb 11, 8:07 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>
>> >> >> > > > > On Feb 11, 2:05 am, David BL <davi...@iinet.net.au> wrote:
>>
>> >> >> > > > > > On Feb 11, 3:29 am, JOG <j...@cs.nott.ac.uk> wrote:
>>
>> >> >> > > > > > > On Feb 10, 5:45 pm, "Dmitry A. Kazakov"
>> >> >> > > > > > > <mail...@dmitry-kazakov.de>
>> >> >> > > > > > > wrote:
>> >> >> > > > > > > > [What is data, in your opinion?
>>
>> >> >> > > > > > > Data. Lots of datum - from latin, meaning statement of
>> >> >> > > > > > > fact.
>> >> >> > > > > > > Predicate
>> >> >> > > > > > > and value in FOL.  A value without description is of
>> >> >> > > > > > > course
>> >> >> > > > > > > just
>> >> >> > > > > > > noise.
>>
>> >> >> > > > > > Latin datum is past participle of dare, "to give".  What
>> >> >> > > > > > make
>> >> >> > > > > > you say
>> >> >> > > > > > data is necessarily a set of propositions?
>>
>> >> >> > > > > The OED. "Facts, esp. numerical facts, collected together 
>> >> >> > > > > for
>> >> >> > > > > reference or information." The etymology stems from 'dare',
>> >> >> > > > > because
>> >> >> > > > > facts are always communicated or "given". I understand of
>> >> >> > > > > course
>> >> >> > > > > that
>> >> >> > > > > the term is thrown around wantonly and ambiguosly nowadays,
>> >> >> > > > > but
>> >> >> > > > > as
>> >> >> > > > > data theorists, we shouldn't be party to that imo ;)
>> >> >> > > > > > Are you suggesting a value
>> >> >> > > > > > is meaningless without a proposition?  Why can't a datum
>> >> >> > > > > > just
>> >> >> > > > > > be a
>> >> >> > > > > > value?
>>
>> >> >> > > > > Because ta value has to be associated with something.
>> >> >> > > > > Hofstadter
>> >> >> > > > > gave
>> >> >> > > > > a good example of this with the groove modulations on a 
>> >> >> > > > > vinyl
>> >> >> > > > > record.
>> >> >> > > > > To us they are (musical) data, to an alien not knowing 
>> >> >> > > > > their
>> >> >> > > > > context,
>> >> >> > > > > it is not. You need the context.
>>
>> >> >> > > > > > Wouldn't you say a recorded image is data?
>>
>> >> >> > > > > Of course, so long as I know it's an image. If its just 
>> >> >> > > > > ones
>> >> >> > > > > and
>> >> >> > > > > zero's stored in a computer, without anyway of telling they
>> >> >> > > > > represent
>> >> >> > > > > a picture, then it is simply noise.
>>
>> >> >> > > > Let's indeed assume we know how to interpret the 1's and 0's 
>> >> >> > > > as
>> >> >> > > > an
>> >> >> > > > image.  So what have we got?  Nothing but a *value*.
>>
>> >> >> > > No, you now have a value with applied context. That creates a
>> >> >> > > fact.
>> >> >> > > You now therefore have data. It's simple to show - consider
>> >> >> > > "1000001".
>> >> >> > > Thats currently a value, but its not data. Its only data when I
>> >> >> > > store
>> >> >> > > it, and state one of the following:
>>
>> >> >> > > "100001" is a text string
>> >> >> > > "100001" is an integer (i.e. 65)
>> >> >> > > "100001" is an ascii character (i.e. A)
>> >> >> > > etc..
>>
>> >> >> > These "facts" are all tautologies that are true whether you 
>> >> >> > record
>> >> >> > them or not.
>>
>> >> >> I'm not seeing whats so controversial or difficult about the fact 
>> >> >> that
>> >> >> "10001" is just a meaningless binary value until you give it a
>> >> >> context. It seems somewhat obvious to me.
>>
>> >> >> > I dispute your premise that the purpose of the data in
>> >> >> > this case is to state a fact that is known a-priori to be true.
>>
>> >> >> A Datum is a given fact. That's what the word means formally. I 
>> >> >> have
>> >> >> said nothing more, and I have no idea what you are on about talking
>> >> >> about "the purpose of data".
>>
>> >> >> > If that is its purpose then it conveys precisely zero 
>> >> >> > information.
>>
>> >> >> > > > We can display
>> >> >> > > > it.  We can comment on whether we like it - even if we 
>> >> >> > > > haven't a
>> >> >> > > > clue
>> >> >> > > > where it came from.  But I don't see any sense in which the
>> >> >> > > > image
>> >> >> > > > value gives us any statements of fact beyond the 
>> >> >> > > > specification
>> >> >> > > > of a
>> >> >> > > > value.  A value simply "is".
>>
>> >> >> > > > I would suggest that a lot of the data in the world is
>> >> >> > > > characterised
>> >> >> > > > more closely as "interesting values" than collections of
>> >> >> > > > propositions.
>>
>> >> >> > > You cannot store these interesting values without implicitly
>> >> >> > > stating
>> >> >> > > some fact about them.
>>
>> >> >> > By definition, when a value is specified, its type is specified 
>> >> >> > as
>> >> >> > well (except possibly if type inheritance is supported).
>>
>> >> >> > C. Date states the following in "Introduction to Database 
>> >> >> > Systems",
>> >> >> > section 5.2, and subsection titled "Values and Variables are 
>> >> >> > typed":
>>
>> >> >> >     "Every value has ... some type...Note that,
>> >> >> >     by definition, a given value always has
>> >> >> >     exactly one type, which never changes.
>> >> >> >     [footnote:  except possibly if type
>> >> >> >     inheritance is supported]"
>>
>> >> >> > When a particular value like the integer 73 is specified, there 
>> >> >> > is
>> >> >> > no
>> >> >> > implicit fact being specified.   The statement that the integer 
>> >> >> > 73
>> >> >> > exists in any absolute sense is entirely metaphysical and
>> >> >> > meaningless
>> >> >> > within computer science.
>>
>> >> >> So you just wriite "73" down and are telling me its a datum? I'm
>> >> >> pretty sure that's what we call a "value", not data. I'm wondering 
>> >> >> if
>> >> >> you are misconstruing my point - "73" is only data when you apply 
>> >> >> some
>> >> >> context to it, like saying this its someones room number, or 
>> >> >> today's
>> >> >> average temperature, or the amount of red in a certain pixel of an
>> >> >> image (and yes, those are then facts).
>>
>> >> > Let me clarify the distinction I'm making David:
>> >> > "RED" is a value.
>> >> > "The first pixel in the image is RED" is a datum.
>>
>> >> > That can't be that contentious...can it?
>>
>> >> Isn't a datum an atomic value?  I think I remember reading somewhere,
>> >> "Each
>> >> and every datum (atomic value)...."
>>
>> >> I think the distinction you want to make is whether or not some
>> >> individual
>> >> that is represented by the value 73 actually exists.  For that there
>> >> needs
>> >> to be a context.  If the value 73 from the domain of integers is named 
>> >> in
>> >> a
>> >> tuple in a relation in a database, then clearly that particular 
>> >> instance
>> >> of
>> >> the value 73 has a context and thus maps to an actual individual in 
>> >> the
>> >> picture of the universe of discourse that is the database.  Clearly 
>> >> the
>> >> act
>> >> of storing the value 73 gives it context.  Without context, 73 is a
>> >> possible
>> >> value, not an actual value.
>>
>> > Instance of a value? Context of a value?  Possible value?  Actual
>> > value?  I cannot make sense of that.
>>
>> Perhaps I should clarify:  A database is a proposition--a picture of the
>> universe.  There can be many possible pictures of the universe, but only 
>> one
>> is supposed to be true.  A value can appear in many possible pictures, so 
>> it
>> follows that a value can appear in a possible picture that is supposed to 
>> be
>> true or in a possible picture that is not supposed to be true, /or both/.
>
> Yes, a value can appear in many different contexts.   In this
> discussion I think we need to be very careful with distinguishing
> between a value, and the appearance (ie encoding) of a value in a
> particular context.
>
>> If a value is a fact, how, then, can it be both true and not true?
>
> What does it mean to say a value is a fact?
>

I think that's my point.

>> An
>> instance of a value, a value in context--the association of a value with 
>> a
>> picture of the universe--on the other hand, /can/ be a fact because that
>> association can be with a possible picture that is supposed to be true or
>> with a possible picture that is not supposed to be true, /but not both/.
>
> I think I understand what you are saying, but I would say it slightly
> differently.  Rather than "instance of value" I would say "appearance
> of value", but only because I'm so used to seeing "instance" used in
> the context of "instance of a type", but maybe that's my OO background
> showing through.  Instantiation also makes me think of the terminology
> used for binding variables to values such as when one says a
> proposition is an instantiation of a predicate.
>

I used the term 'instance' to eliminate confusion when there is more than 
one appearance of a particular value in the same picture of the universe. 
For example,

"Bill Jones married Judy Smith on '1995-06-23' in Cleveland, Ohio."
"Bill Jones married Sally Martin on '2000-03-15' in Akron, Ohio."

Here, the value 'Bill Jones' appears multiple times in the same picture of 
the universe, yet due to Leibniz there can still only be one association 
between the value 'Bill Jones' and that particular picture of the universe. 
So there is only one 'instance' even though there can be more than one 
'appearance.'

> I also don't see how an appearance of a value itself generally
> represents a fact (even though it's tied to a context).   I can see
> it's true if you assume the value is a tuple within a relation, but
> was that your intention?
>

The appearance of a value in a proposition that is supposed to be true 
asserts existence.  Under an interpretation every constant symbol in a 
proposition is mapped to an individual in the Universe of Discourse.  That 
obviously can't happen if any of the individuals do not exist.  So it 
follows that every appearance of a value is a mapping from a constant symbol 
to an individual that actually exists.

>> A value that appears in any possible picture of the universe is a 
>> possible
>> value.  A value that appears in the possible picture of the universe that 
>> is
>> supposed to be true is an actual value.
>
> You've lost me.
>

There can be many possible extensions, but only one, the actual extension, 
represents the current state of affairs.

>> Thus a value is just a value without some context.  Once a value is given
>> context, such as being stored in a database, or written down, or 
>> whatever,
>> then it can be considered information.
>
> I think I know what you're saying but I don't like the way you say
> it.  It doesn't make sense to say a value is given a context.   A
> value like the integer 73 doesn't float around and suddenly drop into
> your database!  The value just "is".  A database may contain any
> number of appearances or encodings of the value 73, but the abstract
> number itself doesn't have a context.  It is the appearance of the
> value that has a context (and can be considered information within
> that context)
>

I think we need to be careful not to mix concepts here.  First, it doesn't 
matter whether something is concrete or abstract.  "Bill Jones" without a 
context is not data even though "Bill Jones" is concrete.  Second, can a 
value be a value if the individual it maps to doesn't exist?  Third, the 
problem is not that the number 73 doesn't have a context--it has many 
contexts, one for each possible picture of the universe in which it appears; 
the problem is that it doesn't have one and only one context.


>> Each atomic value that is in the
>> database is a datum simply because it is /in/ the database.
>
> Agreed.  An appearance (ie encoding) of a value has a context and is
> data.
>

Careful.  Just because a picture is possible doesn't mean that it is 
supposed to be true, so just because an appearance of a value has context 
doesn't mean that it is data:  just because it is possible that I won the 
lotto doesn't mean that I actually did.


0
brian8537 (72)
2/14/2008 4:54:57 AM
On Feb 14, 1:54 pm, "Brian Selzer" <br...@selzer-software.com> wrote:
> "David BL" <davi...@iinet.net.au> wrote in message
> > On Feb 13, 9:22 pm, "Brian Selzer" <br...@selzer-software.com> wrote:
>
> >> Perhaps I should clarify:  A database is a proposition--a picture of the
> >> universe.  There can be many possible pictures of the universe, but only
> >> one
> >> is supposed to be true.  A value can appear in many possible pictures, so
> >> it
> >> follows that a value can appear in a possible picture that is supposed to
> >> be
> >> true or in a possible picture that is not supposed to be true, /or both/.
>
> > Yes, a value can appear in many different contexts.   In this
> > discussion I think we need to be very careful with distinguishing
> > between a value, and the appearance (ie encoding) of a value in a
> > particular context.
>
> >> If a value is a fact, how, then, can it be both true and not true?
>
> > What does it mean to say a value is a fact?
>
> I think that's my point.
>
> >> An
> >> instance of a value, a value in context--the association of a value with
> >> a
> >> picture of the universe--on the other hand, /can/ be a fact because that
> >> association can be with a possible picture that is supposed to be true or
> >> with a possible picture that is not supposed to be true, /but not both/.
>
> > I think I understand what you are saying, but I would say it slightly
> > differently.  Rather than "instance of value" I would say "appearance
> > of value", but only because I'm so used to seeing "instance" used in
> > the context of "instance of a type", but maybe that's my OO background
> > showing through.  Instantiation also makes me think of the terminology
> > used for binding variables to values such as when one says a
> > proposition is an instantiation of a predicate.
>
> I used the term 'instance' to eliminate confusion when there is more than
> one appearance of a particular value in the same picture of the universe.
> For example,
>
> "Bill Jones married Judy Smith on '1995-06-23' in Cleveland, Ohio."
> "Bill Jones married Sally Martin on '2000-03-15' in Akron, Ohio."
>
> Here, the value 'Bill Jones' appears multiple times in the same picture of
> the universe, yet due to Leibniz there can still only be one association
> between the value 'Bill Jones' and that particular picture of the universe.
> So there is only one 'instance' even though there can be more than one
> 'appearance.'

> > I also don't see how an appearance of a value itself generally
> > represents a fact (even though it's tied to a context).   I can see
> > it's true if you assume the value is a tuple within a relation, but
> > was that your intention?
>
> The appearance of a value in a proposition that is supposed to be true
> asserts existence.  Under an interpretation every constant symbol in a
> proposition is mapped to an individual in the Universe of Discourse.  That
> obviously can't happen if any of the individuals do not exist.  So it
> follows that every appearance of a value is a mapping from a constant symbol
> to an individual that actually exists.

For a start that assumes domains are strongly typed.

What about an Age domain?  Are you suggesting that an Age value maps
to an individual in the UoD?  I find that extremely counterintuitive.

Often multiple values are required to identify an individual in the
UoD.

> >> A value that appears in any possible picture of the universe is a
> >> possible
> >> value.  A value that appears in the possible picture of the universe that
> >> is
> >> supposed to be true is an actual value.
>
> > You've lost me.
>
> There can be many possible extensions, but only one, the actual extension,
> represents the current state of affairs.

It doesn't seem worth commenting on this given the more fundamental
issue that I have above.


> >> Thus a value is just a value without some context.  Once a value is given
> >> context, such as being stored in a database, or written down, or
> >> whatever,
> >> then it can be considered information.
>
> > I think I know what you're saying but I don't like the way you say
> > it.  It doesn't make sense to say a value is given a context.   A
> > value like the integer 73 doesn't float around and suddenly drop into
> > your database!  The value just "is".  A database may contain any
> > number of appearances or encodings of the value 73, but the abstract
> > number itself doesn't have a context.  It is the appearance of the
> > value that has a context (and can be considered information within
> > that context)
>
> I think we need to be careful not to mix concepts here.  First, it doesn't
> matter whether something is concrete or abstract.  "Bill Jones" without a
> context is not data even though "Bill Jones" is concrete.

> Second, can a
> value be a value if the individual it maps to doesn't exist?

A value is a value full stop.  It almost sounds like you suggesting
the integers spring into existence as they are needed!


>  Third, the
> problem is not that the number 73 doesn't have a context--it has many
> contexts, one for each possible picture of the universe in which it appears;
> the problem is that it doesn't have one and only one context.

Ok this is better, because in a previous post I thought you were
saying "the context of a value" as if a value only had a single
context.


> >> Each atomic value that is in the
> >> database is a datum simply because it is /in/ the database.
>
> > Agreed.  An appearance (ie encoding) of a value has a context and is
> > data.
>
> Careful.  Just because a picture is possible doesn't mean that it is
> supposed to be true, so just because an appearance of a value has context
> doesn't mean that it is data:  just because it is possible that I won the
> lotto doesn't mean that I actually did.

0
davidbl (206)
2/14/2008 5:44:38 AM
On Thu, 14 Feb 2008 01:14:13 +0100, mAsterdam wrote:

> Dmitry, why are you engaging in this thread?

Don't know, probably it was my mistake. I hoped that there could be some
civilized exchange of meanings rather than usual cursing and calling others
idiots.

>>>> But why is recording essential? 
>>> To facilitate the sharing of observations.
>> 
>> So, we have now:
>> 
>> 1. observations
>> 2. entities (busy with sharing observations)
>> 3. actions (state?) of sharing something (like observations)
>> 4. identity (of "same" thing being shared/observed)
>> 5. identity (of "different" entities observing "same" thing)
> 
> No we don't. You don't have anything here, because you reject the 
> existence of data. Beyond some agreement on that any attempt at 
> formalization of it is futile. You asked my opinion, you reflected it
> against some of your preconceptions about what to formalize
> and what not, and something comes out.

But you certainly should have a mental picture where "data" plays some
role. Let you to tried to formalize it. You would describe some properties
and axioms about "data". You would also like to remove much of unnecessary
and uncertain things (like 1-5 from there). What I tried to say is that
after doing this, you could probably notice that you can remove "data" from
your system without any loss...

> Which primitive elements does your formal system have?

Value, type, variable, operation.
 
>> Bad. It means that you have to formalize "memorize" in some quite tricky
>> way. Honestly I don't know what could be the difference between "memorized
>> Pi", "not-yet-memorized Pi", "once-memorized-but-forgotten-by-now Pi" and
>> so on.
> 
> Are you suggesting π is data?

Yes. But you can take some P(pi)=true instead.

>>>> May I translate data into a different
>>>> representation and then erase the original record? 
>>>> Will data still be there?
>>> Iff it conveys the same facts as the original record, sure.
>> 
>> OK, that means that data = facts + record medium of:
>> 
>> D = (F, R)
> 
> Guessing about your notation as D denotes Data, F denotes Facts, R is 
> the requirement that the fact is recorded, R is just 1.

(A side question, in "R is just 1", were "just 1" data or fact?)

>> It also states that
>> 
>> F1 = F2 => D1 = D2
> 
> Almost. Within a shared set of observations,
> 
>   F₁=F₂ ⇔ D₁=D₂

Even stronger, also.

>> Why should I care about R, then? 
> 
> Why do you? I don't yet.

I order to get rid of it. (It is not only for the sake of reducing the
system. It is also in order to describe R in terms of the formal system. We
want to be able to implement DBMS, don't we? So we need a formal system
where R would be formalized.)

> For now, I don't care about its internals,
> just that it exists so we have a way to record facts.

If you have an equivalence of facts and data, then you need some additional
means in order to distinguish them. And, equivalently, you cannot describe
recording in terms of either data or facts.

>> Pi is Pi and retains all its property
>> independently on where and how you write it (or not). Let's declare F = D
>> and forget about R.
> 
> For now - ok.
> 
>> (BTW, some of DB people regularly posting to comp.object vehemently denied
>> that DB is about persistency. Could you clarify it?)
> 
> No, not at this point. This is best left to a thread on its own.
> 
> Disclosure: I have in the past vehemently denied that DB is about 
> persistency, and I have yet to see a coherent argument that
> it would be. Assume for now it is a belief I turned to
> after experiencing the way the smalltalk system image works and 
> Rumbaugh's remarks on persistency.
> 
>>>> A formal system operates on data
>>>> without any clue of the meaning of.
>>> I think that is to crude.
>>> The meaning itself is informal, hence inherently impossible to fully
>>> access from within the formal system (I think we agree on that).
>>> However, without meaning to associate it with, a formalism is useless.
>> 
>> It is a tautology. You say that without meaning there is no meaning. 
> 
> No, though your rephrase is (a tautology).
> I'll state it differently.
> 
> Without shared, informal denotations, any formalism is useless crap.
> I don't want it and you don't want it.

This is not the same as meaning, and uselessness is yet another thing. But
I see no disagreement in the core issue: a formal system does not operate
meanings. It is we who assign meanings to the inputs and outputs, and, at
yet another level of understanding, judge about the formal system as a
whole in terms of its usefulness, for example.

>> Yes, we cannot reason about meaning while staying 
>> within the same formal system.
>> Because you seem to bind data with a meaning (as I do), that immediately
>> kicks the notion of data out of the formal system. So data do not exist
>> there. Which is all my point! No data, nothing to worry about.
> 
> And the result is a hermetic system as useful as solipsism.
> Have some fun there! I'm out waiting until you are bored of it.

OK, I am back on vacation. How are you going to formalize something which
cannot be formalized? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/14/2008 10:47:29 AM
On Wed, 13 Feb 2008 17:21:42 -0800 (PST), David BL wrote:

> On Feb 14, 7:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Tue, 12 Feb 2008 20:48:47 -0800 (PST), David BL wrote:
>>> Objects are said to have identity, state and behavior.   The idea that
>>> an object can (always) be thought of as a (data) variable that can be
>>> assigned a (data) value reveals a complete lack of understanding of
>>> OO.
>>> Bob's confusion between the concepts of object state versus object
>>> value also leads him to misunderstand the significance of
>>> encapsulation in the context of OO.
>>
>> I hate to agree with Bob Badour, but the notion of object is indeed
>> superfluous. It is enough to have value, type, variable. Type has behavior.
>> Variable has state. Identity can be attributed to a variable (the name of)
>> or a value (the type of) or a type (the behavior of, or the name of, if
>> named). What is specific to OO, that polymorphic values have identities of
>> the corresponding specific types, which makes dispatch possible.
> 
> You appear to agree with Bob, but nothing could be further from the
> truth.
> 
> Have you read the characterisations of value, variable and type by
> C.Date?  They are very different to your above descriptions.
> 
> value :  doesn't exist in time or space.  Immutable
> variable : can be assigned a value

Was it his wording? I don't remember. Or, maybe, "assigned" above is meant
not as an operation defined, but rather as:

   variable : has a value

> type :  set of values plus operations on those values
> 
> C.Date ignores the Liskov Substitution Principle (LSP) and states that
> a circle is an ellipse, and that a coloured rectangle cannot be a
> subtype of a rectangle.

Well, circle is indeed an ellipse. It is just so that the implication

   circle is a ellipse => circle is substitutable for ellipse

is wrong. Further a coloured rectangle can be substitutable for rectangle
in some context. Talking about substitutability (and anything else) one
should not mix sets (types) and members of (values). C.Date and B.Liskov
apply "is" do *different* things.

> Given Date's definitions of variable and type, his conclusions are
> sensible.   I recommend all OO programmers read C.Date's work on sub-
> typing.

I agree.

> In my opinion an OO language should properly support value-types in
> the way described by Date.

Oh, yes. Moreover by-reference-semantics is secondary to
by-value-semantics. It is impossible to create a consistent
everybody-has-identity system. Identity itself is just a value.

> Unfortunately I don't know of any that
> do.  Of course it should also support the conventional OO notion of
> typing which is based on contractual guarantees of behavior and hence
> leads to the LSP for sub-typing.

Well, LSP program is utopian. Substitutability cannot be achieved by such
rough means. As for contracts, your wording leaves an impression that
contracts are somehow unnecessary for the behavior of "value-types." (I
cannot agree with that)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/14/2008 10:57:05 AM
On Feb 14, 7:57 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 13 Feb 2008 17:21:42 -0800 (PST), David BL wrote:
> > On Feb 14, 7:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Tue, 12 Feb 2008 20:48:47 -0800 (PST), David BL wrote:
> >>> Objects are said to have identity, state and behavior.   The idea that
> >>> an object can (always) be thought of as a (data) variable that can be
> >>> assigned a (data) value reveals a complete lack of understanding of
> >>> OO.
> >>> Bob's confusion between the concepts of object state versus object
> >>> value also leads him to misunderstand the significance of
> >>> encapsulation in the context of OO.
>
> >> I hate to agree with Bob Badour, but the notion of object is indeed
> >> superfluous. It is enough to have value, type, variable. Type has behavior.
> >> Variable has state. Identity can be attributed to a variable (the name of)
> >> or a value (the type of) or a type (the behavior of, or the name of, if
> >> named). What is specific to OO, that polymorphic values have identities of
> >> the corresponding specific types, which makes dispatch possible.
>
> > You appear to agree with Bob, but nothing could be further from the
> > truth.
>
> > Have you read the characterisations of value, variable and type by
> > C.Date?  They are very different to your above descriptions.
>
> > value :  doesn't exist in time or space.  Immutable
> > variable : can be assigned a value
>
> Was it his wording? I don't remember. Or, maybe, "assigned" above is meant
> not as an operation defined, but rather as:
>
>    variable : has a value

I checked C.Date's wording.  He says a variable is a holder for the
appearance of a value, and a variable can be updated - meaning that
the current value of the variable can be replaced by another value.

> > type :  set of values plus operations on those values
>
> > C.Date ignores the Liskov Substitution Principle (LSP) and states that
> > a circle is an ellipse, and that a coloured rectangle cannot be a
> > subtype of a rectangle.
>
> Well, circle is indeed an ellipse. It is just so that the implication
>
>    circle is a ellipse => circle is substitutable for ellipse
>
> is wrong.

I think you need to qualify that.  Using C.Date's definitions of type
and variable, a circle value is substitutable for an ellipse value,
whereas substitutability doesn't apply for variables.

For an OO concept of type, substitutability of an object (ie
"variable") depends on whether the ellipse class provides any mutative
methods that could allow a circle object to stop being a circle.  Of
course one generally wants to be able to assign any possible ellipse
value to an ellipse variable so IMO this example inevitably breaks
LSP.

It is interesting that if a language were to properly support value
types then we actually would want to *drop* state in derived classes
because specialisations give you less degrees of freedom, not more.
I have wondered whether a language along the following lines would be
appropriate:

type Rect
{
    int area { return width*height; }
    int width;
    int height;
};

type Square : Rect
{
    int height { return width; }
};

type UnitSquare : Square
{
    int width { return 1; }
};

void foo()
{
    UnitSquare s;
    int a = s.area;
}

I would hope that through in-lining the compiler simply initialises a
= 1.


> Further a coloured rectangle can be substitutable for rectangle
> in some context.

I think you need to qualify that as well, because now it's the
reverse: substitutability makes sense for variables, but not for
values!

C++ programmers refer to the slicing problem when an upcast of a value
slices away some of its state.  A coloured rectangle value can easily
have its colour sliced away.


> Talking about substitutability (and anything else) one
> should not mix sets (types) and members of (values). C.Date and B.Liskov
> apply "is" do *different* things.

>
> > Given Date's definitions of variable and type, his conclusions are
> > sensible.   I recommend all OO programmers read C.Date's work on sub-
> > typing.
>
> I agree.
>
> > In my opinion an OO language should properly support value-types in
> > the way described by Date.
>
> Oh, yes. Moreover by-reference-semantics is secondary to
> by-value-semantics. It is impossible to create a consistent
> everybody-has-identity system. Identity itself is just a value.
>
> > Unfortunately I don't know of any that
> > do.  Of course it should also support the conventional OO notion of
> > typing which is based on contractual guarantees of behavior and hence
> > leads to the LSP for sub-typing.
>
> Well, LSP program is utopian. Substitutability cannot be achieved by such
> rough means. As for contracts, your wording leaves an impression that
> contracts are somehow unnecessary for the behavior of "value-types." (I
> cannot agree with that)

I guess I need better words.  Note however that I don't think
"behaviour" in the sense of conventional OO is relevant to value-
types.  Values are immutable and all updates to variables are
assignments.  A variable doesn't have a chance to exhibit behaviour!
At a certain level of abstraction all operators defined on a value
type can be assumed to act on pure inputs and return pure outputs.

0
davidbl (206)
2/14/2008 1:28:34 PM
On Feb 14, 3:52 am, David BL <davi...@iinet.net.au> wrote:
> On Feb 13, 9:56 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
>
>
> > On Feb 13, 2:06 am, David BL <davi...@iinet.net.au> wrote:
>
> > > On Feb 12, 9:53 pm, JOG <j...@cs.nott.ac.uk> wrote:
> > > [snip]
> > > > Consider /unallocated/ RAM in your PC. Look at 5 contiguous bits at
> > > > random. Are you telling me that the binary number you are looking at
> > > > is "data"? I'd accept that it is a value (albeit a meaningless one)
> > > > but "data"? You really think that?
>
> > > No I don't.
>
> > > When data is recorded on some medium there is a lot of implicit
> > > *knowledge* about how it has been encoded.  This knowledge has to
> > > account for all sorts of details, such as what designates a 1 versus a
> > > 0.   How many bits in a word?  What order do they appear in?  Is there
> > > an address bus?  How is the address bus organised?  The binary
> > > encoding is only a tiny part of it.  Obviously we both agree that all
> > > that knowledge is implicit in correctly decoding the data.
>
> > Yes I broadly agree apart from on one key matter (there's a suprise
> > eh) - "knowledge is implict". I contend the exact opposite, and this
> > is my whole point really. The knowledge required must be explicit.
> > That's what makes otherwise random noise, or values, data.  In the
> > case of a scientist log book for example what the data means is
> > explicit in a title at the top of the page or in the scientist's
> > head.
>
> You can't make the knowledge explicit because you can't formalise it.
>
> > Another example:
> > "todays lottery numbers: 23, 34, 17"
> > "experimental reults: 23, 34, 17"
>
> > Same values, different data. If you agree with this statement then
> > values != data surely?
>
> You seem to have forgotten that I said data was associated with the
> appearance (ie encoding) of values.

Nicely dodged, but let me try again!

"todays lottery numbers: 23, 34, 17"
"experimental results: 23, 34, 17"

All written down on a bit of paper - same values discussed, but
different data. Agree or disagree?

I ask this because if we can distinguish data and values, we must then
determine /how/ they are different. You state it is by "encoding" but
the two lines above are encoded in the same manner as far as I am
concerned, so that cannot be the difference between the two concepts.
That is unless your "Encodings" equates to my notion of "Facts", and
we are thus agreeing loudly, using different definitions of those
terms.

> Encodings have a context, and
> values do not.  We don't disagree on whether data is associated with
> encodings.  Rather we disagree on what is being encoded.  I say data =
> encoded values.  (I think) you say data = encoded facts.
>
> > > Our point of contention is rather that I suggest that most generally
> > > the data is nothing other than encoded values, and doesn't necessarily
> > > convey any facts.   I'm assuming that the knowledge implicit in the
> > > encoding of the data is by definition not part of the data itself,
> > > whereas I think you are suggesting it is part of the data.
>
> > Yes I think that's an excellent breakdown. Its all just down to where
> > we draw the lines I guess...
> > Brian: Data is encoded values. I need to know externally what they
> > represent.
> > Jim: Data is encoded values plus an denotation of what they represent.
>
> Did you mean to say Brian?

No I meant to say David. Apologies.

>
> Do you agree you cannot formalise what the values represent?

Yes, imo no "meaning" can be represented via a purely descriptive
formalism. One always needs some component situated in the real world
for that. But obviously we can formalize communicated statements of
fact.

> [schnnnip]
> > > > > C.Date distinguishes between a value (that by definition doesn't exist
> > > > > in time and space), versus the *appearance* of a value which appears
> > > > > in time and space and is encoded in a particular way.
>
> > > > Is this what your view of the terms is based upon?
>
> > > These definitions seems reasonable to me.
>
> > This seem overly philosophical to me. Surely we don't need metaphysics
> > to know that if someone hands me a bit of paper with: "1.00, 0.376 and
> > 0.904" on it, well that's just a list of values. However if if someone
> > hands you a bit of paper with "Surface Gravity - Earth:1.00, Mars:
> > 0.376 and Venus:0.904", or tells you those denotations,  then we have
> > data ;)
>
> You have repeatedly chosen examples that suit your argument, whereas
> according to our disagreement only I that have that privilege!
>
> Jim:
>     In all examples, data is useful to the recipient and
>     represents facts

Yes, of course, because the poem example is much harder for me to deal
with ;P

>
> David:
>     1) In all examples, data is useful to the recipient and
>        represents values; and
>     2) There exists example where data is useful to the recipient
>        and doesn't represent facts
>
> Since a tuple of a relation is a value and it also represents a fact
> it is clear that my definition of data encompasses yours.
>
> We can both easily think of examples where (so called) data is useless
> to the recipient.  Let's agree and say that's not actually data.  That
> only leaves one possibility for proof by counter example:  I provide
> an example where the data is useful to the recipient yet doesn't
> convey any facts.   The sending of a poem or an image without any
> additional context is an example.

Well put. I contend that you can't do this, and that a poem or image
as described is not an example of data, but merely values. You are
saying to me "a poem is data. It is clearly not a fact. Ergo, pwnage."
But you are already assuming it is data in the first step. I say its
not, and cannot follow why you would think it is. Like a "22". That's
not data but, if I was a numerologist say, I would still find the
value interesting.

So to me the poem is just a value. Its only data when I say this thing
here, X, has role Y. A picture is just a picture. Even if its, say, a
biochemistry picture of a cell membrane. _However_ if that picture is
then put in a log book, under "image of neurostem cell from experiment
B",  its data. This accords to tradtional definitions.

I am offering you examples where you have an item that you would not
describe as data, and showing how it is turned into something that is
generally described as data. All best, have found the conversation so
far well articulated, even if we don't agree.... Jim.

>
> People download web pages (which are basically just encoded values)
> into their WWW browsers all the time without any more context than
> following a hyperlink.  They often don't find out whether it's useful
> or relevant until they read it.   In many respects the WWW can be
> regarded as a big collection of encoded "interesting values" indexed
> by content without any additional context.

Web pages are just values. They of course may describe data in their
contents. Boink.
0
jog (83)
2/14/2008 1:38:33 PM
On Feb 14, 10:57 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 13 Feb 2008 17:21:42 -0800 (PST), David BL wrote:
> > On Feb 14, 7:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Tue, 12 Feb 2008 20:48:47 -0800 (PST), David BL wrote:
> >>> Objects are said to have identity, state and behavior.   The idea that
> >>> an object can (always) be thought of as a (data) variable that can be
> >>> assigned a (data) value reveals a complete lack of understanding of
> >>> OO.
> >>> Bob's confusion between the concepts of object state versus object
> >>> value also leads him to misunderstand the significance of
> >>> encapsulation in the context of OO.
>
> >> I hate to agree with Bob Badour, but the notion of object is indeed
> >> superfluous. It is enough to have value, type, variable. Type has behavior.
> >> Variable has state. Identity can be attributed to a variable (the name of)
> >> or a value (the type of) or a type (the behavior of, or the name of, if
> >> named). What is specific to OO, that polymorphic values have identities of
> >> the corresponding specific types, which makes dispatch possible.
>
> > You appear to agree with Bob, but nothing could be further from the
> > truth.
>
> > Have you read the characterisations of value, variable and type by
> > C.Date?  They are very different to your above descriptions.
>
> > value :  doesn't exist in time or space.  Immutable
> > variable : can be assigned a value
>
> Was it his wording? I don't remember. Or, maybe, "assigned" above is meant
> not as an operation defined, but rather as:
>
>    variable : has a value
>
> > type :  set of values plus operations on those values
>
> > C.Date ignores the Liskov Substitution Principle (LSP) and states that
> > a circle is an ellipse, and that a coloured rectangle cannot be a
> > subtype of a rectangle.
>
> Well, circle is indeed an ellipse.

I /believe/ what Date would say (and its certainly what I would say
even if he has not) is that a set of points has the properties
qualifying it as a "circle" as well as those qualifying it as an
"ellipse". Two parallel views of the same underlying data.

> It is just so that the implication
>
>    circle is a ellipse => circle is substitutable for ellipse
>
> is wrong. Further a coloured rectangle can be substitutable for rectangle
> in some context. Talking about substitutability (and anything else) one
> should not mix sets (types) and members of (values). C.Date and B.Liskov
> apply "is" do *different* things.
>
> > Given Date's definitions of variable and type, his conclusions are
> > sensible.   I recommend all OO programmers read C.Date's work on sub-
> > typing.
>
> I agree.
>
> > In my opinion an OO language should properly support value-types in
> > the way described by Date.
>
> Oh, yes. Moreover by-reference-semantics is secondary to
> by-value-semantics. It is impossible to create a consistent
> everybody-has-identity system. Identity itself is just a value.
>
> > Unfortunately I don't know of any that
> > do.  Of course it should also support the conventional OO notion of
> > typing which is based on contractual guarantees of behavior and hence
> > leads to the LSP for sub-typing.
>
> Well, LSP program is utopian. Substitutability cannot be achieved by such
> rough means. As for contracts, your wording leaves an impression that
> contracts are somehow unnecessary for the behavior of "value-types." (I
> cannot agree with that)
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

0
jog (83)
2/14/2008 2:01:46 PM
JOG wrote:
> On Feb 14, 3:52 am, David BL <davi...@iinet.net.au> wrote:
> 
>>On Feb 13, 9:56 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>
>>
>>
>>
>>>On Feb 13, 2:06 am, David BL <davi...@iinet.net.au> wrote:
>>
>>>>On Feb 12, 9:53 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>>>[snip]
>>>>
>>>>>Consider /unallocated/ RAM in your PC. Look at 5 contiguous bits at
>>>>>random. Are you telling me that the binary number you are looking at
>>>>>is "data"? I'd accept that it is a value (albeit a meaningless one)
>>>>>but "data"? You really think that?
>>
>>>>No I don't.
>>
>>>>When data is recorded on some medium there is a lot of implicit
>>>>*knowledge* about how it has been encoded.  This knowledge has to
>>>>account for all sorts of details, such as what designates a 1 versus a
>>>>0.   How many bits in a word?  What order do they appear in?  Is there
>>>>an address bus?  How is the address bus organised?  The binary
>>>>encoding is only a tiny part of it.  Obviously we both agree that all
>>>>that knowledge is implicit in correctly decoding the data.
>>
>>>Yes I broadly agree apart from on one key matter (there's a suprise
>>>eh) - "knowledge is implict". I contend the exact opposite, and this
>>>is my whole point really. The knowledge required must be explicit.
>>>That's what makes otherwise random noise, or values, data.  In the
>>>case of a scientist log book for example what the data means is
>>>explicit in a title at the top of the page or in the scientist's
>>>head.
>>
>>You can't make the knowledge explicit because you can't formalise it.
>>
>>
>>>Another example:
>>>"todays lottery numbers: 23, 34, 17"
>>>"experimental reults: 23, 34, 17"
>>
>>>Same values, different data. If you agree with this statement then
>>>values != data surely?
>>
>>You seem to have forgotten that I said data was associated with the
>>appearance (ie encoding) of values.
> 
> 
> Nicely dodged, but let me try again!
> 
> "todays lottery numbers: 23, 34, 17"
> "experimental results: 23, 34, 17"
> 
> All written down on a bit of paper - same values discussed, but
> different data. Agree or disagree?
> 
> I ask this because if we can distinguish data and values, we must then
> determine /how/ they are different. You state it is by "encoding" but
> the two lines above are encoded in the same manner as far as I am
> concerned, so that cannot be the difference between the two concepts.
> That is unless your "Encodings" equates to my notion of "Facts", and
> we are thus agreeing loudly, using different definitions of those
> terms.
> 
> 
>>Encodings have a context, and
>>values do not.  We don't disagree on whether data is associated with
>>encodings.  Rather we disagree on what is being encoded.  I say data =
>>encoded values.  (I think) you say data = encoded facts.
>>
>>
>>>>Our point of contention is rather that I suggest that most generally
>>>>the data is nothing other than encoded values, and doesn't necessarily
>>>>convey any facts.   I'm assuming that the knowledge implicit in the
>>>>encoding of the data is by definition not part of the data itself,
>>>>whereas I think you are suggesting it is part of the data.
>>
>>>Yes I think that's an excellent breakdown. Its all just down to where
>>>we draw the lines I guess...
>>>Brian: Data is encoded values. I need to know externally what they
>>>represent.
>>>Jim: Data is encoded values plus an denotation of what they represent.
>>
>>Did you mean to say Brian?
> 
> 
> No I meant to say David. Apologies.
> 
> 
>>Do you agree you cannot formalise what the values represent?
> 
> 
> Yes, imo no "meaning" can be represented via a purely descriptive
> formalism. One always needs some component situated in the real world
> for that. But obviously we can formalize communicated statements of
> fact.
> 
> 
>>[schnnnip]
>>
>>>>>>C.Date distinguishes between a value (that by definition doesn't exist
>>>>>>in time and space), versus the *appearance* of a value which appears
>>>>>>in time and space and is encoded in a particular way.
>>
>>>>>Is this what your view of the terms is based upon?
>>
>>>>These definitions seems reasonable to me.
>>
>>>This seem overly philosophical to me. Surely we don't need metaphysics
>>>to know that if someone hands me a bit of paper with: "1.00, 0.376 and
>>>0.904" on it, well that's just a list of values. However if if someone
>>>hands you a bit of paper with "Surface Gravity - Earth:1.00, Mars:
>>>0.376 and Venus:0.904", or tells you those denotations,  then we have
>>>data ;)
>>
>>You have repeatedly chosen examples that suit your argument, whereas
>>according to our disagreement only I that have that privilege!
>>
>>Jim:
>>    In all examples, data is useful to the recipient and
>>    represents facts
> 
> 
> Yes, of course, because the poem example is much harder for me to deal
> with ;P
> 
> 
>>David:
>>    1) In all examples, data is useful to the recipient and
>>       represents values; and
>>    2) There exists example where data is useful to the recipient
>>       and doesn't represent facts
>>
>>Since a tuple of a relation is a value and it also represents a fact
>>it is clear that my definition of data encompasses yours.
>>
>>We can both easily think of examples where (so called) data is useless
>>to the recipient.  Let's agree and say that's not actually data.  That
>>only leaves one possibility for proof by counter example:  I provide
>>an example where the data is useful to the recipient yet doesn't
>>convey any facts.   The sending of a poem or an image without any
>>additional context is an example.
> 
> 
> Well put. I contend that you can't do this, and that a poem or image
> as described is not an example of data, but merely values.

If it is represented suitably for machine processing, it is data. It has 
value to the recipient as data because it evokes some emotion or image 
and because a machine can store it, transmit it, reformat it etc. The 
poem is also a fact. The poem doesn't convey a fact. It is one. Poem P 
says Blah.

[misguided argument snipped]
0
bbadour (434)
2/14/2008 2:04:17 PM
On Thu, 14 Feb 2008 05:28:34 -0800 (PST), David BL wrote:

> On Feb 14, 7:57 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Wed, 13 Feb 2008 17:21:42 -0800 (PST), David BL wrote:
>>> On Feb 14, 7:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> On Tue, 12 Feb 2008 20:48:47 -0800 (PST), David BL wrote:
>>>>> Objects are said to have identity, state and behavior.   The idea that
>>>>> an object can (always) be thought of as a (data) variable that can be
>>>>> assigned a (data) value reveals a complete lack of understanding of
>>>>> OO.
>>>>> Bob's confusion between the concepts of object state versus object
>>>>> value also leads him to misunderstand the significance of
>>>>> encapsulation in the context of OO.
>>
>>>> I hate to agree with Bob Badour, but the notion of object is indeed
>>>> superfluous. It is enough to have value, type, variable. Type has behavior.
>>>> Variable has state. Identity can be attributed to a variable (the name of)
>>>> or a value (the type of) or a type (the behavior of, or the name of, if
>>>> named). What is specific to OO, that polymorphic values have identities of
>>>> the corresponding specific types, which makes dispatch possible.
>>
>>> You appear to agree with Bob, but nothing could be further from the
>>> truth.
>>
>>> Have you read the characterisations of value, variable and type by
>>> C.Date?  They are very different to your above descriptions.
>>
>>> value :  doesn't exist in time or space.  Immutable
>>> variable : can be assigned a value
>>
>> Was it his wording? I don't remember. Or, maybe, "assigned" above is meant
>> not as an operation defined, but rather as:
>>
>>    variable : has a value
> 
> I checked C.Date's wording.  He says a variable is a holder for the
> appearance of a value, and a variable can be updated - meaning that
> the current value of the variable can be replaced by another value.

I don't think that it is essential for a variable to be replaceable.
Consider a type over a set with exactly one value. Can I have a variable
of? In my view variable is just a mapping of the computational state onto
the set of values of the type.

>>> type :  set of values plus operations on those values
>>
>>> C.Date ignores the Liskov Substitution Principle (LSP) and states that
>>> a circle is an ellipse, and that a coloured rectangle cannot be a
>>> subtype of a rectangle.
>>
>> Well, circle is indeed an ellipse. It is just so that the implication
>>
>>    circle is a ellipse => circle is substitutable for ellipse
>>
>> is wrong.
> 
> I think you need to qualify that.  Using C.Date's definitions of type
> and variable, a circle value is substitutable for an ellipse value,
> whereas substitutability doesn't apply for variables.

That makes the notion of subtype less interesting, especially if it would
not apply to variables. Further, the difference between values and
variables is IMO not in immutability. Variable is an artefact of
computation, a computational object. Value is outside, it is a semantic, a
value of the object.

> For an OO concept of type, substitutability of an object (ie
> "variable") depends on whether the ellipse class provides any mutative
> methods that could allow a circle object to stop being a circle.

It is wider. It is about provable prepositions. Mutability is not an issue.
One can express the problem without any mention of variables., fully
immutably:

   forall x,y in R exists Ellipse with x=axis1 and y=axis2   (1)

Circle is not substitutable here. But circle is still an ellipse in the
sense of injective mapping:

   forall c of Circle exists e of Ellipse such that <no matter here>  (2)

2 does not imply 1. End of story. The actual problem is that for software
design a notion of subtype based on 2 is uninteresting because it is the
things like 1 we want to deal with. Subtypes aren't subsets, because
subsets are too weak to judge about substitutability.

One cannot reduce subtypes to subsets, or wider behavior to data.

> It is interesting that if a language were to properly support value
> types then we actually would want to *drop* state in derived classes
> because specialisations give you less degrees of freedom, not more.

I think it is interface inheritance from concrete type, is what you want.

> I have wondered whether a language along the following lines would be
> appropriate:
> 
> type Rect
> {
>     int area { return width*height; }
>     int width;
>     int height;
> };
> 
> type Square : Rect
> {
>     int height { return width; }
> };
> 
> type UnitSquare : Square
> {
>     int width { return 1; }
> };
> 
> void foo()
> {
>     UnitSquare s;
>     int a = s.area;
> }
> 
> I would hope that through in-lining the compiler simply initialises a
> = 1.

Yes, this is what I am arguing for years. This is exactly why there should
be no such thing as "data" or "member." int width of the class rooted in
Rect is pure behavior. It is incidentally implemented as a member (data)
for the type Rect. That is an implementation detail, no more. Another
implementation from the class (UnitSquare) could implement it differently.
So it is only the contracted behavior "get width of," which matters.

>> Further a coloured rectangle can be substitutable for rectangle
>> in some context.
> 
> I think you need to qualify that as well, because now it's the
> reverse: substitutability makes sense for variables, but not for
> values!

There are types of substitutability. You seem to call substitutability only
in-substitutability (that is - to be substitutable in the operations taking
in-arguments). But out-substitutability is of no less interests, as you
have out, in-out arguments and results of operations.

> C++ programmers refer to the slicing problem when an upcast of a value
> slices away some of its state.  A coloured rectangle value can easily
> have its colour sliced away.

Which has to be this way. A colored rectangle value cannot be passed as a
rectangle value, that would be a type error. It must be converted first.
The result forgets anything it was before. As C.Date stays, values exist
out of time, there is no any history of. So it has no color. The rest is a
design fault of C++. It shall not dispatch on specific rectangle values.
That breaks the contract of the corresponding type. One can dispatch on
polymorphic values only.

> I guess I need better words.  Note however that I don't think
> "behaviour" in the sense of conventional OO is relevant to value-
> types.  Values are immutable and all updates to variables are
> assignments.  A variable doesn't have a chance to exhibit behaviour!
> At a certain level of abstraction all operators defined on a value
> type can be assumed to act on pure inputs and return pure outputs.

Yes. Just one note, values expose behavior of their type. The behavior of
1, an integer value, is in part that there exits 2, an integer value such
that Inc(1)=2. Nothing beyond that. Behavior does not imply either
statefulness or identity.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/14/2008 3:03:09 PM
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:9mygggm8sikb.98nyv0zywo9z.dlg@40tude.net...

> I don't think that it is essential for a variable to be replaceable.
> Consider a type over a set with exactly one value. Can I have a variable
> of? In my view variable is just a mapping of the computational state onto
> the set of values of the type.

A constant can take on only one value.  A variable is called a variable
because it can be varied.  In other words, the value written in it can be
replaced.




0
cressey73 (124)
2/14/2008 3:17:19 PM
On 2008-02-13 06:01:02 -0600, "David Cressey" <cressey73@verizon.net> said:

>> Yes, but in very different ways, and with very different emphasis.
>> 
>> OO is about structuring modules around behavior and hiding data.  The
>> structure and form of the data is hidden as deeply as possible, so that
>> no other behaviors depend upon it.
>> 
> 
> If you can disregard Bob's rude tone without disregarding the content of his
> response,  I ask you to do so.

No rudeness was intended.  I apologize if my words seemed to carry a rude tone.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/14/2008 3:29:42 PM
On 2008-02-13 05:38:32 -0600, "David Cressey" <cressey73@verizon.net> said:

> One of the features of the classical procedural languages is the rigid
> separation of "program" and "data".  In Pascal, for instance, one can create
> some new Pascal code, in the form of text,  manipulating it as though it
> were data (which it is).  But in order to "execute" it,  one needs to pass
> it through the compiler,  and from there to the run time system.  Once it's
> "program"  it can't be seen as "data" anymore.  A program cannot examine
> itself.

Very nicely put.  This is essentially the dinstinction between source 
code and binary code.  It is at this boundary where OO has it's power.

You see, OO is about *source* code.  Here's why:

Imagine we have a program that creates a report in text.

Imagine we have a new requirement to *also* produce that report in HTML.

The two reports contain the same data, use the same calculations, and 
are roughly the same tabular format.  However, the details of the 
formatting are completely different.  One uses tabs and line ends.  The 
other uses <table>, <tr>, and <td> tags, etc.

As programmers we have some options.

1. Copy the report program and change the copy replacing all the tabs 
and newlines with appropriate HTML.

2. Create a flag and smear "if" statements throughout the report 
program choosing text or html at every output statement.

3. Completely separate the details for content generation from the 
details of content formatting.

The first is problematic because of the duplicate code.  Any change to 
the content of the report, or the general format of the report, must 
now be made in two places.

The second is problematic because it makes a mess of the code, and is 
deeply fragile. It also makes a third format much more difficult.

The third is OO.  The technique is simple.  All content generation code 
goes in one class.  This class makes calls to an object interface that 
has functions for newRow, newCell, etc.  There are two implementations 
of the interface.  One that emits tabs and line ends, another that 
emits HTML tags.

The *source code* dependencies all point towards the interface.  The 
content generation module knows nothing about the two format 
implementations.

The benefits are:

1. We can add new formats without affecting any others.
2. We can change content in one place.
3. When content changes, the format modules do not need to be 
recompiled, or redeployed; and vice versa.

That last bullet is important.  Remember that source code is converted 
into binary code through "compilation".  Running the compiler can be 
expensive.  Deploying binary code to the execution environment can also 
be expensive.  OO allows us to make changes to programs without forcing 
us to recompile every module.  Well designed OO programs can often be 
changed by recompiling a single module.  That recompiled module results 
in a binary file that can be redeployed to the target environment 
without redeploying any other binary modules.




-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/14/2008 3:50:13 PM
On 2008-02-13 06:07:58 -0600, "David Cressey" <cressey73@verizon.net> said:

> 
> "Robert Martin" <unclebob@objectmentor.com> wrote in message
> news:2008021221010631729-unclebob@objectmentorcom...
>> On 2008-02-11 16:21:12 -0600, "David Cressey" <cressey73@verizon.net>
> said:
>> 
>>> Objects do not always hide data.  Specifically,  they pass messages to
> each
>>> other in the form of data.
>> 
>> True, but the recipient has no guarantee that the data recieved was
>> stored anywhere. Nor can the recipient be sure that the recieved data
>> originated in the recieved form.   Moreover, the sender expects the
>> recipient to do something with the data.  All messages connote action
>> of some kind.
>> 
> 
> It's the recipient's job to store the data, in general.

No, a recipient *might* store it.  Or it might use the data as an index 
to look up something else.  Or it might multiply it by 42, convert it 
to hexadecimal, and send it to a text to speech device.

> In
> many contexts,  we like to think of the recipient of a query as the client
> process that partners with the DBMS as a server process.  In reality,  the
> receiver is a transaction, not a process.

Quite.  The transaction is an object.  It recieves messages from the 
client and performs certain behaviors based on those messages.  The 
transaction has some state information buried in it; but the clients 
are not privy to the form of that data.  We can ask a transaction 
whether it is dirty or not, or whether it is open, or complete, but the 
form of that state information is hidden deep inside the transation and 
passed out in a form suitable for client consumption.  That's how 
objects behave.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/14/2008 3:57:27 PM
>> Well, circle is indeed an ellipse.

Yes.  But a program that represents all circles does not necessarily 
represent all ellipses.

The fact that a program p represents an entity e, where e is a subset 
of a larger set S, does not mean that p is a subset of the programs 
that represent S.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/14/2008 4:06:47 PM

Robert Martin wrote:
> On 2008-02-13 05:38:32 -0600, "David Cressey" <cressey73@verizon.net> said=
:
>

I'm sorry people, but this is rimming over the pan with gobs of
Bullshit. Politeness is off for this one.

> > One of the features of the classical procedural languages is the rigid
> > separation of "program" and "data".  In Pascal, for instance, one can cr=
eate
> > some new Pascal code, in the form of text,  manipulating it as though it=

> > were data (which it is).  But in order to "execute" it,  one needs to pa=
ss
> > it through the compiler,  and from there to the run time system.  Once i=
t's
> > "program"  it can't be seen as "data" anymore.  A program cannot examine=

> > itself.
>
> Very nicely put.  This is essentially the dinstinction between source
> code and binary code.  It is at this boundary where OO has it's power.

It's called a "compiled language".  If you have an interpreted
language, you have more opportunity for a program to "examine itself"
because interpreted languages tend to KEEP the programming structures/
idioms that the code turns into. I don't see how this has anything to
do with OO versus procedural. LISP, for example, is highly self-
examining and was created long before Pascal.

For efficiency, true-compiled languages need to toss higher-level
structures, meaning there is less of them to examine at run-time. Java
is not a truely compiled language, but a hybrid, I would note. Maybe
one could make a hybrid version of Pascal to give it reflexion-like
capabilities.

>
> You see, OO is about *source* code.  Here's why:
>
> Imagine we have a program that creates a report in text.
>
> Imagine we have a new requirement to *also* produce that report in HTML.
>
> The two reports contain the same data, use the same calculations, and
> are roughly the same tabular format.  However, the details of the
> formatting are completely different.  One uses tabs and line ends.  The
> other uses <table>, <tr>, and <td> tags, etc.
>
> As programmers we have some options.
>
> 1. Copy the report program and change the copy replacing all the tabs
> and newlines with appropriate HTML.
>
> 2. Create a flag and smear "if" statements throughout the report
> program choosing text or html at every output statement.
>
> 3. Completely separate the details for content generation from the
> details of content formatting.
>
> The first is problematic because of the duplicate code.  Any change to
> the content of the report, or the general format of the report, must
> now be made in two places.
>
> The second is problematic because it makes a mess of the code, and is
> deeply fragile. It also makes a third format much more difficult.
>
> The third is OO.  The technique is simple.  All content generation code
> goes in one class.  This class makes calls to an object interface that
> has functions for newRow, newCell, etc.  There are two implementations
> of the interface.  One that emits tabs and line ends, another that
> emits HTML tags.
>
> The *source code* dependencies all point towards the interface.  The
> content generation module knows nothing about the two format
> implementations.

There's a 4th possibility that you conveniently skipped. Describe the
page as an intermediate data structure (a meta-format), and then each
"output type" routine uses that structure to format it as needed.

You guys just don't get table-oriented programming (or at least "data
centric", since non-table data structures can do it also if you like
navigational structs). My #@%^& Goodness!

>
> The benefits are:
>
> 1. We can add new formats without affecting any others.
> 2. We can change content in one place.
> 3. When content changes, the format modules do not need to be
> recompiled, or redeployed; and vice versa.
>
> That last bullet is important.

What about those of us who prefer interpreted invironments? We don't
give a flying flip about compilation issues.

And, the approach I described can have an extra module added for a
different output type withOUT having to recompile diddly squat because
it only has to read an existing data meta-structure or table or file.

In fact, this is more or less how modern device drivers (cough) are
often done. For example MS Windows generates a semi-standardized
intermediate format, and printerFoo.DLL (or whatever extension they
use now) is fed that meta-data structure/format and reshapes it for
the device at hand.

That's not OOP, that's data-oriented programming.

Another one of the advantages of an intermediate "meta format" is that
it is easier to share across languages and tools. Objects tend to be
xenophobic, preferring to be processed ONLY by the lang they were
built in. Data-centric info is more sharable.

QED

> Remember that source code is converted
> into binary code through "compilation".  Running the compiler can be
> expensive.  Deploying binary code to the execution environment can also
> be expensive.  OO allows us to make changes to programs without forcing
> us to recompile every module.  Well designed OO programs can often be
> changed by recompiling a single module.  That recompiled module results
> in a binary file that can be redeployed to the target environment
> without redeploying any other binary modules.
>

Bullshit, as described above.

Anyhow, most instances of variation-on-a-theme that is encountered in
custom biz apps does NOT fit the damned device-driver pattern. There
is more mix-and-match of features not found in device drivers such
that driver-like sub-typing would get messy. SETs (as in set theory)
are the best way I've seen to map features to instances. OO is either
tree-centric or graph-centric when managing variations-on-a-theme. I
find sets conceptually better than graphs. If you have a graph-
oriented brain, that is fine, but don't extrapolate that to others.
Set's are more "math-able" than graphs, as Dr. Codd found out.

There should be a 10-year moratorium on device-driver-like examples.
(Same with shapes and animals.) They are distorting the picture of
what real apps need.

>
>
> --
> Robert C. Martin (Uncle Bob)=EF=BF=BD=EF=BF=BD| email: unclebob@objectment=
or.com

-T-
0
topmind (2124)
2/14/2008 4:31:15 PM
On Thu, 14 Feb 2008 15:17:19 GMT, David Cressey wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:9mygggm8sikb.98nyv0zywo9z.dlg@40tude.net...
> 
>> I don't think that it is essential for a variable to be replaceable.
>> Consider a type over a set with exactly one value. Can I have a variable
>> of? In my view variable is just a mapping of the computational state onto
>> the set of values of the type.
> 
> A constant can take on only one value.  A variable is called a variable
> because it can be varied.  In other words, the value written in it can be
> replaced.

Mathematical interpretation (where the term comes from) is different. It is  

   "a quantity capable of assuming any of a set of values"

This does imply replacement or even variation. It says that the value is
unspecified here, can be thought as any from some set of.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/14/2008 4:43:11 PM
JOG wrote:

> On Feb 14, 10:57 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>On Wed, 13 Feb 2008 17:21:42 -0800 (PST), David BL wrote:
>>
>>>On Feb 14, 7:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>>wrote:
>>>
>>>>On Tue, 12 Feb 2008 20:48:47 -0800 (PST), David BL wrote:
>>>>
>>>>>Objects are said to have identity, state and behavior.   The idea that
>>>>>an object can (always) be thought of as a (data) variable that can be
>>>>>assigned a (data) value reveals a complete lack of understanding of
>>>>>OO.
>>>>>Bob's confusion between the concepts of object state versus object
>>>>>value also leads him to misunderstand the significance of
>>>>>encapsulation in the context of OO.
>>
>>>>I hate to agree with Bob Badour, but the notion of object is indeed
>>>>superfluous. It is enough to have value, type, variable. Type has behavior.

Don't be a hater. You can love to disagree with me without hating to agree.


>>>>Variable has state. Identity can be attributed to a variable (the name of)
>>>>or a value (the type of) or a type (the behavior of, or the name of, if
>>>>named). What is specific to OO, that polymorphic values have identities of
>>>>the corresponding specific types, which makes dispatch possible.
>>
>>>You appear to agree with Bob, but nothing could be further from the
>>>truth.
>>
>>>Have you read the characterisations of value, variable and type by
>>>C.Date?  They are very different to your above descriptions.
>>
>>>value :  doesn't exist in time or space.  Immutable
>>>variable : can be assigned a value
>>
>>Was it his wording? I don't remember. Or, maybe, "assigned" above is meant
>>not as an operation defined, but rather as:
>>
>>   variable : has a value
>>
>>>type :  set of values plus operations on those values
>>
>>>C.Date ignores the Liskov Substitution Principle (LSP) and states that

Actually, D&D address Liskov directly. One wonders whether David 
bothered to read them. If he did, one can only conclude he has 
difficulty comprehending written english.


>>>a circle is an ellipse, and that a coloured rectangle cannot be a
>>>subtype of a rectangle.
>>
>>Well, circle is indeed an ellipse.

And a coloured rectangle is a composition of a colour and a rectangle. 
Only an ignorant moron would demand compositions be subtypes of their 
components. Duh! ::rolls eyes::


> I /believe/ what Date would say (and its certainly what I would say
> even if he has not) is that a set of points has the properties
> qualifying it as a "circle" as well as those qualifying it as an
> "ellipse". Two parallel views of the same underlying data.

Actually, the more interesting thing Date said is the addresses of 
ellipse variables are a subtype of the addresses of circle variables. 
They are a subset of the addresses where one can store a circle value, 
and they have a superset of the (assignment) operations.

It is always true that the addresses of a supertype's variables are a 
subtype of the addresses of a subtype's variables. People like David 
bend themselves out of shape trying to apply Liskov in reverse.


>>It is just so that the implication
>>
>>   circle is a ellipse => circle is substitutable for ellipse
>>
>>is wrong. Further a coloured rectangle can be substitutable for rectangle
>>in some context. Talking about substitutability (and anything else) one
>>should not mix sets (types) and members of (values). C.Date and B.Liskov
>>apply "is" do *different* things.

I disagree. D&D address Liskov directly.


>>>Given Date's definitions of variable and type, his conclusions are
>>>sensible.   I recommend all OO programmers read C.Date's work on sub-
>>>typing.
>>
>>I agree.

I see we can all agree on something.


>>>In my opinion an OO language should properly support value-types in
>>>the way described by Date.
>>
>>Oh, yes. Moreover by-reference-semantics is secondary to
>>by-value-semantics. It is impossible to create a consistent
>>everybody-has-identity system. Identity itself is just a value.

Not only is it secondary, the reference reverses the sub and the super.

[snip]
0
bbadour (434)
2/14/2008 5:24:32 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2008021409294216807-unclebob@objectmentorcom...
> On 2008-02-13 06:01:02 -0600, "David Cressey" <cressey73@verizon.net>
said:
>
> >> Yes, but in very different ways, and with very different emphasis.
> >>
> >> OO is about structuring modules around behavior and hiding data.  The
> >> structure and form of the data is hidden as deeply as possible, so that
> >> no other behaviors depend upon it.
> >>
> >
> > If you can disregard Bob's rude tone without disregarding the content of
his
> > response,  I ask you to do so.
>
> No rudeness was intended.  I apologize if my words seemed to carry a rude
tone.
>
I was referring to Bob Badour,  not to you.  None of your messages have
carried even a hint of rudeness.

Sorry for the ambiguous reference.



0
cressey73 (124)
2/14/2008 5:45:36 PM
"topmind" <topmind@technologist.com> wrote in message
news:5f10c4d4-5ab7-4bae-a44e-613d95f3eb38@q78g2000hsh.googlegroups.com...


Robert Martin wrote:
> On 2008-02-13 05:38:32 -0600, "David Cressey" <cressey73@verizon.net>
said:
>

> I'm sorry people, but this is rimming over the pan with gobs of
> Bullshit. Politeness is off for this one.

>> > One of the features of the classical procedural languages is the rigid
>> > separation of "program" and "data".  In Pascal, for instance, one can
create
>> > some new Pascal code, in the form of text,  manipulating it as though
it
>> > were data (which it is).  But in order to "execute" it,  one needs to
pass
>> > it through the compiler,  and from there to the run time system.  Once
it's
>> > "program"  it can't be seen as "data" anymore.  A program cannot
examine
>> > itself.
>>
>> Very nicely put.  This is essentially the dinstinction between source
>> code and binary code.  It is at this boundary where OO has it's power.

> It's called a "compiled language".  If you have an interpreted
> language, you have more opportunity for a program to "examine itself"
> because interpreted languages tend to KEEP the programming structures/
> idioms that the code turns into. I don't see how this has anything to
> do with OO versus procedural. LISP, for example, is highly self-
> examining and was created long before Pascal.

If you will trace back to the comment that Robert was referring to, you will
note that the paragraph Robert quoted was a counter point to the previous
paragraph, in which I explicitly mentioned machine language and lisp,  as
languages that do permit this kind of thing.

The paragraph quoted may seem like BS because of the omission of the other
paragraph.  If you put it back in the original context, it may make more
sense to you.


For efficiency, true-compiled languages need to toss higher-level
structures, meaning there is less of them to examine at run-time. Java
is not a truely compiled language, but a hybrid, I would note. Maybe
one could make a hybrid version of Pascal to give it reflexion-like
capabilities.

This is not the only way in which languages like Pascal separate program
form data.
In Pascal (at least vanilla Pascal)  a program may not examine the object
code the compiler generated,  even though it may share a memory space with
the data structures it manipulates.



0
cressey73 (124)
2/14/2008 5:55:49 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2008021409572750073-unclebob@objectmentorcom...
> On 2008-02-13 06:07:58 -0600, "David Cressey" <cressey73@verizon.net>
said:
>
> >
> > "Robert Martin" <unclebob@objectmentor.com> wrote in message
> > news:2008021221010631729-unclebob@objectmentorcom...
> >> On 2008-02-11 16:21:12 -0600, "David Cressey" <cressey73@verizon.net>
> > said:
> >>
> >>> Objects do not always hide data.  Specifically,  they pass messages to
> > each
> >>> other in the form of data.
> >>
> >> True, but the recipient has no guarantee that the data recieved was
> >> stored anywhere. Nor can the recipient be sure that the recieved data
> >> originated in the recieved form.   Moreover, the sender expects the
> >> recipient to do something with the data.  All messages connote action
> >> of some kind.
> >>
> >
> > It's the recipient's job to store the data, in general.
>
> No, a recipient *might* store it.

I should have said, "It's the recipient's job to store the data, if the
recipient needs to."


0
cressey73 (124)
2/14/2008 5:57:05 PM
On Feb 14, 7:50 am, Robert Martin <uncle...@objectmentor.com> wrote:
> Imagine we have a program that creates a report in text.
>
> Imagine we have a new requirement to *also* produce that report in HTML.
>
> The two reports contain the same data, use the same calculations, and
> are roughly the same tabular format.  However, the details of the
> formatting are completely different.  One uses tabs and line ends.  The
> other uses <table>, <tr>, and <td> tags, etc.
>
> As programmers we have some options.
>
> 1. Copy the report program and change the copy replacing all the tabs
> and newlines with appropriate HTML.
>
> 2. Create a flag and smear "if" statements throughout the report
> program choosing text or html at every output statement.
>
> 3. Completely separate the details for content generation from the
> details of content formatting.
>
> The first is problematic because of the duplicate code.  Any change to
> the content of the report, or the general format of the report, must
> now be made in two places.
>
> The second is problematic because it makes a mess of the code, and is
> deeply fragile. It also makes a third format much more difficult.

Ok, here is how to solve this problem right.

1. Don't take "the program" that produces the report on faith. Maybe
it would take you 5 minutes to DYI? If the report in question is
database one, then sure you can write a query that extracts the data
in less than 5 min! Assuming that it is database report (and your
reference to the <tab> tag makes me strongly suspect that), you have
all the database bells and wistles to do your job, instead of relying
onto some obscure program written by nobody.

2. Let the report data source be something other than database. Again,
you don't want to touch the code written by someone else with a large
pole. You'd better write a converter instead. There is a whole science
how to process linearly ordered data such as strings: regular
expessions, formal grammars, etc. In case of the data (as opposed to
program source) the grammars defining the data structure tends to be
much smaller, so writing a grammar is not such a challenging task.

I admit that formal grammars and languages never enjoyed the sucess
comparable to other branches of the programming industry. Among 1000
professionals you'd be lucky to find a single one comfortable with
grammars (although percentage utilizing regexps is much higher!). The
fault is entirely of the pioneer computer scientists who left the
languages and grammars area underdeveloped. The void has been filled
in by the horrors of XML.

Please note that formal grammars are declarative specifications of the
data which are serialized as strings of characters. Ideally, the
grammar solution should be as clean as the database one. In practice,
however, there are silly limitations -- you have to check that your
grammar conforms to a specific "vision" of the compiler designer. For
example, ANTLR goes only as far as LL(*) and chokes on ambiguous
grammars. Contrast this to DBMS world where RDBMS executes the query
no matter how badly it is written.

0
2/14/2008 6:02:11 PM
On Thu, 14 Feb 2008 10:02:11 -0800 (PST), Tegiri Nenashi wrote:

> Please note that formal grammars are declarative specifications of the
> data which are serialized as strings of characters. Ideally, the
> grammar solution should be as clean as the database one. In practice,
> however, there are silly limitations -- you have to check that your
> grammar conforms to a specific "vision" of the compiler designer. For
> example, ANTLR goes only as far as LL(*) and chokes on ambiguous
> grammars. Contrast this to DBMS world where RDBMS executes the query
> no matter how badly it is written.

LOL. Like letting a DFA to recognize a^n b^n... You made my day, thanks!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/14/2008 8:20:02 PM
On Feb 14, 12:20=A0pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 14 Feb 2008 10:02:11 -0800 (PST), Tegiri Nenashi wrote:
> > Please note that formal grammars are declarative specifications of the
> > data which are serialized as strings of characters. Ideally, the
> > grammar solution should be as clean as the database one. In practice,
> > however, there are silly limitations -- you have to check that your
> > grammar conforms to a specific "vision" of the compiler designer. For
> > example, ANTLR goes only as far as LL(*) and chokes on ambiguous
> > grammars. Contrast this to DBMS world where RDBMS executes the query
> > no matter how badly it is written.
>
> LOL. Like letting a DFA to recognize a^n b^n... You made my day, thanks!

I'm glad I entertained you, although you are missing the point (as
usual). What languages on a particular levels of Chomsky hierarcky are
capable (or rather uncapable of) is not important. Grammar based
methods are  immature (yet?) and there is even no clear concept of
string transformation. Attribute grammars is as far as the theory got,
but in practice people put all kind of horrible procedural sideeffects
inside the curly brakets after each grammar rule.

BTW, I was talking about CFGs which have nothing to do with NFA or
DFA. Also, one of the things that makes the grammar field unaccessible
to mainstream programmers is the concept of automata itself! Automaton
is just a particular (and not very natural) regular language
representation. Then, you have all sorts of automata derived
constructions (e.g. stack machines) -- give me a break.

0
2/14/2008 8:46:56 PM
On Feb 14, 12:20=A0pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 14 Feb 2008 10:02:11 -0800 (PST), Tegiri Nenashi wrote:
> > Please note that formal grammars are declarative specifications of the
> > data which are serialized as strings of characters. Ideally, the
> > grammar solution should be as clean as the database one. In practice,
> > however, there are silly limitations -- you have to check that your
> > grammar conforms to a specific "vision" of the compiler designer. For
> > example, ANTLR goes only as far as LL(*) and chokes on ambiguous
> > grammars. Contrast this to DBMS world where RDBMS executes the query
> > no matter how badly it is written.
>
> LOL. Like letting a DFA to recognize a^n b^n... You made my day, thanks!

On Feb 14, 12:20 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 14 Feb 2008 10:02:11 -0800 (PST), Tegiri Nenashi wrote:
> > Please note that formal grammars are declarative specifications of the
> > data which are serialized as strings of characters. Ideally, the
> > grammar solution should be as clean as the database one. In practice,
> > however, there are silly limitations -- you have to check that your
> > grammar conforms to a specific "vision" of the compiler designer. For
> > example, ANTLR goes only as far as LL(*) and chokes on ambiguous
> > grammars. Contrast this to DBMS world where RDBMS executes the query
> > no matter how badly it is written.
>
> LOL. Like letting a DFA to recognize a^n b^n... You made my day, thanks!

I'm glad I entertained you, although you are missing the point (as
usual). What languages on a particular levels of Chomsky hierarcky are
capable (or rather uncapable of) is not important. Grammar based
methods are  immature (yet?) and there is even no clear concept of
string transformation. Attribute grammars is as far as the theory got,
but in practice people put all kind of horrible procedural sideeffects
inside the curly brakets after each grammar rule.

BTW, I was talking about CFGs which have nothing to do with NFA or
DFA. Also, one of the things that makes the grammar field unaccessible
to mainstream programmers is the concept of automata itself! Automaton
is just a particular (and not very natural) regular language
representation. Then, you have all sorts of automata derived
constructions (e.g. stack machines) -- give me a break.

0
2/14/2008 8:47:31 PM
On Feb 7, 2:42=A0pm, topmind <topm...@technologist.com> wrote:
> On Feb 7, 1:00=A0pm, Tegiri Nenashi <TegiriNena...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 7, 12:35 pm, Victor Porton <por...@narod.ru> wrote:
>
> > > I know both object oriented programming and DB (SQL). But it seems
> > > that these are incompatible.
>
> > I suggest that OO ideas are too naive to continue influence
> > programming. Formal Concept Analysis (FCA) is much more theoretically
> > sound method how to organize things into taxonomies.
>
> > Here is an example -- a hierarchy of living things, restricted to the
> > set {Lamprey, Trout, Lungfish, ..., Human}. FCA starts with feature
> > matrix like this:
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Jaws Limbs =A0 Hair =A0 =A0Lungs =
=A0 Tail =A0 =A0Shell
> > Lamprey 0 =A0 =A0 =A0 0 =A0 =A0 =A0 0 =A0 =A0 =A0 0 =A0 =A0 =A0 1 =A0 =
=A0 =A0 0
> > Trout =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 0 =A0 =A0 =A0 0 =A0 =A0 =A0 0 =
=A0 =A0 =A0 1 =A0 =A0 =A0 0
> > Lungfish =A0 =A0 =A0 =A01 =A0 =A0 =A0 0 =A0 =A0 =A0 0 =A0 =A0 =A0 1 =A0 =
=A0 =A0 1 =A0 =A0 =A0 0
> > Turtle =A0 =A0 =A0 =A0 =A0 =A0 =A01 =A0 1 =A0 =A0 =A0 0 =A0 =A0 =A0 1 =
=A0 =A0 =A0 1 =A0 =A0 =A0 1
> > Cat =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 1 =A0 =A0 =A0 1 =A0 =A0 =A0 1 =
=A0 =A0 =A0 1 =A0 =A0 =A0 0
> > Gorilla =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 1 =A0 =A0 =A0 1 =A0 =A0 =A0 1 =A0 =
=A0 =A0 0 =A0 =A0 =A0 0
> > Human =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 1 =A0 =A0 =A0 1 =A0 =A0 =A0 1 =
=A0 =A0 =A0 0 =A0 =A0 =A0 0
>
> > Then, the objects and the attributes (aka concepts) organize
> > themselves into a lattice like this
>
> > Lamprey -> Trout -> Lungfish -> Cat -> Gorilla
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 |
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 ---> Hu=
man
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0----> Turtle
>
> > which is more powerful concept than OO hierarchy of classes. Each FCA
> > concept is essentially a limited form of a relation.
>
> It should be pointed out that biological taxonomies are often not an
> appropriate test of variations-on-a-theme management techniques for
> many domains. This is because biology is based on descent-based
> evolution; while other domain items, such as Apple Widgets are not,

It has been observed that programming field started to resemble
biology. There is clear evolution that governs the survival of the
fittest. Also (for better or worse) the ever increasing complexity
started to promote imprecise methods.

> and are composed of a buffet-like mix-and-match of features based on
> S. Job's whims.

I'm not sure why St. John is relevant to the discussion. I just posted
by deep impression about FCA method. You fill in the character feature
matrix, and FCA method builds a hierarchy automatically for you. The
Galois duality between attributes and objects also provides an insight
on the LSP confusion. An object has more than one set of properties
subject to subset relation!
0
2/14/2008 9:51:41 PM
On Feb 14, 1:51 pm, Tegiri Nenashi <TegiriNena...@gmail.com> wrote:
>
> The Galois duality between attributes and objects

Oh, shit. What does that mean? I have this intuition that
you've just said something that it's important that I learn about.


Marshall

PS. And I'm still meaning to follow up on the Galois connection
between syntax and semantics... need more Tarski. Mumble
mumble. Have to finish that axiomatic set theory book, then
need to read about model theory. Argh.
0
2/14/2008 10:11:39 PM
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>Mathematical interpretation (where the term comes from) is different. It is  
>"a quantity capable of assuming any of a set of values"

  Modern (axiomatic) mathematics, does not use a fixed standard
  vocabulary for formal terms.

  Instead, formal terms are being defined /specifically/ for
  each theory by axioms. Informal terms are used in explanations
  of formal texts and might be somewhat vague.

  While ISO 2382 might define �variable� somehow, in
  programming, the term also is context-dependent: For example,
  in �Java Language Specification, Third Edition� a �variable�
  is what in �ISO/IEC 14882:2003(E)� is an �object�.

  For successful communication you need to agree on a
  common vocabulary with your dialog partner. Often you can
  not just take it for granted.

0
ram (2986)
2/14/2008 11:22:59 PM
Dmitry A. Kazakov wrote:
> mAsterdam wrote:
> 
>> Dmitry, why are you engaging in this thread?
> 
> Don't know, probably it was my mistake. I hoped that there could be some
> civilized exchange of meanings rather than usual cursing and calling others
> idiots.

Heh. Same thing here.

>>>>> But why is recording essential? 
>>>> To facilitate the sharing of observations.
>>> So, we have now:
>>>
>>> 1. observations
>>> 2. entities (busy with sharing observations)
>>> 3. actions (state?) of sharing something (like observations)
>>> 4. identity (of "same" thing being shared/observed)
>>> 5. identity (of "different" entities observing "same" thing)
>> No we don't. You don't have anything here, because you reject the 
>> existence of data. Beyond some agreement on that any attempt at 
>> formalization of it is futile. You asked my opinion, you reflected it
>> against some of your preconceptions about what to formalize
>> and what not, and something comes out.
> 
> But you certainly should have a mental picture
> where "data" plays some role. 

Is it necessary for both sides of the border to fully understand the
formalisms en vogue at the other side? I don't think so.
Your position - I trust you'll correct me if I'm wrong -
is: there is no data, no other side, no border to cross.

> Let you to tried to formalize it. You would describe some properties
> and axioms about "data". You would also like to remove much of unnecessary
> and uncertain things (like 1-5 from there). What I tried to say is that
> after doing this, you could probably notice that you can remove "data" from
> your system without any loss...
> 
>> Which primitive elements does your formal system have?
> 
> Value, type, variable, operation.

That looks rich enough to get somewhere.

Somewhat OT to this thread - just because I am curious:
do you have a reference to definitions/descriptions of how these act 
together you consider worthwhile?

>>> Bad. It means that you have to formalize "memorize" in some quite tricky
>>> way. Honestly I don't know what could be the difference between "memorized
>>> Pi", "not-yet-memorized Pi", "once-memorized-but-forgotten-by-now Pi" and
>>> so on.
>> Are you suggesting π is data?
> 
> Yes. But you can take some P(pi)=true instead.

Or R(P(π)) - packaging a symbol/value doesn't make it data.
In order to be data it should convey a fact, relevant in a
sense outside the formal system, i.e. an observation, or the basis
for a decision.

>>>>> May I translate data into a different
>>>>> representation and then erase the original record? 
>>>>> Will data still be there?
>>>> Iff it conveys the same facts as the original record, sure.
>>> OK, that means that data = facts + record medium of:
>>>
>>> D = (F, R)
>> Guessing about your notation as D denotes Data, F denotes Facts, R is 
>> the requirement that the fact is recorded, R is just 1.
> 
> (A side question, in "R is just 1", were "just 1" data or fact?)

It is the 'recorded' property of the fact.
As you deny the existence of facts and data
I don't see how this is relevant to you.
(This /is/ accurate, right? I don't want to even /look/
like calling somebody an idgit in this thread - for polical 
correctness, of course :-)

>>> It also states that
>>>
>>> F1 = F2 => D1 = D2
>> Almost. Within a shared set of observations,
>>
>>   F₁=F₂ ⇔ D₁=D₂
> 
> Even stronger, also.
> 
>>> Why should I care about R, then? 
>> Why do you? I don't yet.
> 
> I order to get rid of it. (It is not only for the sake of reducing the
> system. It is also in order to describe R in terms of the formal system. We
> want to be able to implement DBMS, don't we? So we need a formal system
> where R would be formalized.)
> 
>> For now, I don't care about its internals,
>> just that it exists so we have a way to record facts.
> 
> If you have an equivalence of facts and data, then you need some additional
> means in order to distinguish them. 

By definition recorded (data) vs. maybe recorded maybe not (facts).
D ⊆ F
(don't know if this covers partial recordings)

> And, equivalently, you cannot describe
> recording in terms of either data or facts.

Yep, that's the fate of primitives and semi-primitives.

[snip persistence]

>>>>> A formal system operates on data
>>>>> without any clue of the meaning of.
>>>> I think that is to crude.
>>>> The meaning itself is informal, hence inherently impossible to fully
>>>> access from within the formal system (I think we agree on that).
>>>> However, without meaning to associate it with, a formalism is useless.
>>> It is a tautology. You say that without meaning there is no meaning. 
>> No, though your rephrase is (a tautology).
>> I'll state it differently.
>>
>> Without shared, informal denotations, any formalism is useless crap.
>> I don't want it and you don't want it.
> 
> This is not the same as meaning, 

Indeed, but it is a proxy to it.
In C. Date's books it is called the external predicate.

> and uselessness is yet another thing. 

Yes. A thing pertaining to the reason of the
formal systems' existence.

> But I see no disagreement in the core issue: 
> a formal system does not operate meanings.

I see no agreement to the core issue:
A formal system needs to support meaning to be useful.

> It is we who assign meanings to the inputs and outputs, and, at
> yet another level of understanding, judge about the formal system as a
> whole in terms of its usefulness, for example.

It is IPO vs. IDO (late 70's debate) all over:

Input values - Process - Output values: It does not matter what the 
input means, as long as the output is correctly processed from the input.

Input process - Data - Output process: The input process (datacapture) 
is to be constrained in order to prevent inconsistencies in the data. 
The output process (rendering) should be validated not to corrrupt 
meaning. "You have  01 vacation days left". Ouch - but just within the 
currently acceptable range.

>>> Yes, we cannot reason about meaning while staying 
>>> within the same formal system.
>>> Because you seem to bind data with a meaning (as I do), that immediately
>>> kicks the notion of data out of the formal system. So data do not exist
>>> there. Which is all my point! No data, nothing to worry about.
>> And the result is a hermetic system as useful as solipsism.
>> Have some fun there! I'm out waiting until you are bored of it.
> 
> OK, I am back on vacation. How are you going to formalize something which
> cannot be formalized? (:-))

Hey, I am not the one eager to formalize without
a proper, shared, informal understanding.


--
What you see depends on where you stand.
0
mAsterdam (155)
2/14/2008 11:41:37 PM

Tegiri Nenashi wrote:
> On Feb 7, 2:42=EF=BF=BDpm, topmind <topm...@technologist.com> wrote:
> > On Feb 7, 1:00=EF=BF=BDpm, Tegiri Nenashi <TegiriNena...@gmail.com> wrot=
e:
> >
> >
> > > On Feb 7, 12:35 pm, Victor Porton <por...@narod.ru> wrote:
> >
> > > > I know both object oriented programming and DB (SQL). But it seems
> > > > that these are incompatible.
> >
> > > I suggest that OO ideas are too naive to continue influence
> > > programming. Formal Concept Analysis (FCA) is much more theoretically
> > > sound method how to organize things into taxonomies.
> >
> > > Here is an example -- a hierarchy of living things, restricted to the
> > > set {Lamprey, Trout, Lungfish, ..., Human}. FCA starts with feature
> > > matrix like this:
> >
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =
=EF=BF=BD =EF=BF=BD =EF=BF=BDJaws Limbs =EF=BF=BD Hair =EF=BF=BD =EF=BF=BDLu=
ngs =EF=BF=BD Tail =EF=BF=BD =EF=BF=BDShell
> > > Lamprey 0 =EF=BF=BD =EF=BF=BD =EF=BF=BD 0 =EF=BF=BD =EF=BF=BD =EF=BF=
=BD 0 =EF=BF=BD =EF=BF=BD =EF=BF=BD 0 =EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =EF=BF=
=BD =EF=BF=BD =EF=BF=BD 0
> > > Trout =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=
=BF=BD 1 =EF=BF=BD 0 =EF=BF=BD =EF=BF=BD =EF=BF=BD 0 =EF=BF=BD =EF=BF=BD =EF=
=BF=BD 0 =EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 0
> > > Lungfish =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD1 =EF=BF=BD =EF=BF=BD =
=EF=BF=BD 0 =EF=BF=BD =EF=BF=BD =EF=BF=BD 0 =EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =
=EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 0
> > > Turtle =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=
=BF=BD1 =EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 0 =EF=BF=BD =EF=BF=BD =EF=
=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 1
> > > Cat =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=
=BD =EF=BF=BD 1 =EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =EF=BF=BD =EF=BF=
=BD =EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=
=BD 0
> > > Gorilla =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =
=EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =
=EF=BF=BD =EF=BF=BD =EF=BF=BD 0 =EF=BF=BD =EF=BF=BD =EF=BF=BD 0
> > > Human =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=
=BF=BD 1 =EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=
=BF=BD 1 =EF=BF=BD =EF=BF=BD =EF=BF=BD 0 =EF=BF=BD =EF=BF=BD =EF=BF=BD 0
> >
> > > Then, the objects and the attributes (aka concepts) organize
> > > themselves into a lattice like this
> >
> > > Lamprey -> Trout -> Lungfish -> Cat -> Gorilla
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =
=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD| =EF=BF=BD =EF=BF=BD =EF=
=BF=BD =EF=BF=BD |
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =
=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD| =EF=BF=BD =EF=BF=BD =EF=
=BF=BD =EF=BF=BD ---> Human
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =
=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD|
> > > =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =
=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD----> Turtle
> >
> > > which is more powerful concept than OO hierarchy of classes. Each FCA
> > > concept is essentially a limited form of a relation.
> >
> > It should be pointed out that biological taxonomies are often not an
> > appropriate test of variations-on-a-theme management techniques for
> > many domains. This is because biology is based on descent-based
> > evolution; while other domain items, such as Apple Widgets are not,
>
> It has been observed that programming field started to resemble
> biology. There is clear evolution that governs the survival of the
> fittest. Also (for better or worse) the ever increasing complexity
> started to promote imprecise methods.

I partly agree, but in biology genes don't jump species very often (at
least not for modern multi-cellular critters), while in computer code
they can and do often.

But I meant more in terms of modeling the domain (business nouns), not
modeling the internals of software. The differences in the business
nouns are not reliably tree-shaped for the most part.

>
> > and are composed of a buffet-like mix-and-match of features based on
> > S. Job's whims.
>
> I'm not sure why St. John is relevant to the discussion. I just posted
> by deep impression about FCA method. You fill in the character feature
> matrix, and FCA method builds a hierarchy automatically for you.

Any set or graph can be forced into a tree if you try hard enough, but
working with it in that forced form, especially with regard to change
management, can be a pain because most changes are not "tree-
friendly". You'd be refactoring (shuffling around) large branches too
often.  Sets are generally more forgiving.

Biology changes are generally funnelled into a tree-shape by the
limits of reproduction. Constructs created by managers and marketers,
on the other had, don't give a bleep about architectural purity or
easy changes.

Even many OO'ers see the limits of pure trees, and construct more
complicated OO structures (patterns) to better handle changes.
However, these lose the conceptual simplicity of hierarchies, turning
into a messy graph and one is stuck with a big ball of class pasta.

> The
> Galois duality between attributes and objects also provides an insight
> on the LSP confusion. An object has more than one set of properties
> subject to subset relation!

-T-
0
topmind (2124)
2/15/2008 12:01:20 AM
David Cressey wrote:
> Robert Martin wrote:
>> David Cressey said:
>>>> Yes, but in very different ways, and with very different emphasis.
>>>>
>>>> OO is about structuring modules around behavior and hiding data.  The
>>>> structure and form of the data is hidden as deeply as possible, so that
>>>> no other behaviors depend upon it.
>>>>
>>> If you can disregard Bob's rude tone without 
>>> disregarding the content of his
>>> response,  I ask you to do so.
>> No rudeness was intended.  
>> I apologize if my words seemed to carry a rude tone.
> I was referring to Bob Badour,  not to you. 
>  None of your messages have carried even a hint of rudeness.
> 
> Sorry for the ambiguous reference.

? I really don't see the ambiguity.

Or is this an extreme table manners over content thing?

If there was any rudeness to Roberts posts it was
to the audience, by not addressing the content - but, as
so many times before, Bob's tone almost legitimized this.


Aahh ... Bob/Robert ... now I see it. Hey! This is difficult
for nonnative speakers, I tell you.


--
What you see depends on where you stand.
0
mAsterdam (155)
2/15/2008 12:15:35 AM
Stefan Ram wrote:
>   For successful communication you need to agree on a
>   common vocabulary with your dialog partner. Often you can
>   not just take it for granted.

http://groups.google.nl/group/comp.databases.theory/msg/08029395838a041d?hl=nl&&q=cdt+glossary
0
mAsterdam (155)
2/15/2008 12:29:47 AM
David Cressey wrote:

> You missed the major point.

That happens a lot, these days.
I don't think a few new glossary items help this time, though.
0
mAsterdam (155)
2/15/2008 12:37:48 AM
> ... the potential for fan-in/fan-out.

Precedence analysis is strictly fan-in.
0
mAsterdam (155)
2/15/2008 12:40:09 AM
Marshall wrote:
> Tegiri Nenashi wrote:
>> The Galois duality between attributes and objects
> 
> Oh, shit. What does that mean? I have this intuition that
> you've just said something that it's important that I learn about.
> 
> 
> Marshall
> 
> PS. And I'm still meaning to follow up on the Galois connection
> between syntax and semantics... need more Tarski. Mumble
> mumble. Have to finish that axiomatic set theory book, then
> need to read about model theory. Argh.

Yes, V^H Nenashi, please elaborate for us mere mortals :-)
0
mAsterdam (155)
2/15/2008 1:32:49 AM
On Feb 14, 5:32=A0pm, mAsterdam <mAster...@vrijdag.org> wrote:
> Marshall wrote:
> > Tegiri Nenashi wrote:
> >> The Galois duality between attributes and objects
>
> > Oh, shit. What does that mean? I have this intuition that
> > you've just said something that it's important that I learn about.
>
> > Marshall
>
> > PS. And I'm still meaning to follow up on the Galois connection
> > between syntax and semantics... need more Tarski. Mumble
> > mumble. Have to finish that axiomatic set theory book, then
> > need to read about model theory. Argh.
>
> Yes, V^H Nenashi, please elaborate for us mere mortals :-)

I thought Marshall was joking. Anyway, don't take my word for it,
Galois connections are mentioned in about every FCA paper.

Here is FCA home page
http://www.upriss.org.uk/fca/fca.html
and introductory article
http://www.upriss.org.uk/papers/arist.pdf
There is even free software to play with, e.g ConceptExplorer!




0
2/15/2008 2:19:36 AM
On Feb 14, 10:38 pm, JOG <j...@cs.nott.ac.uk> wrote:
> On Feb 14, 3:52 am, David BL <davi...@iinet.net.au> wrote:
> > On Feb 13, 9:56 pm, JOG <j...@cs.nott.ac.uk> wrote:
> > > On Feb 13, 2:06 am, David BL <davi...@iinet.net.au> wrote:
> > > > On Feb 12, 9:53 pm, JOG <j...@cs.nott.ac.uk> wrote:

[snip]

> > > Another example:
> > > "todays lottery numbers: 23, 34, 17"
> > > "experimental reults: 23, 34, 17"
>
> > > Same values, different data. If you agree with this statement then
> > > values != data surely?
>
> > You seem to have forgotten that I said data was associated with the
> > appearance (ie encoding) of values.
>
> Nicely dodged, but let me try again!
>
> "todays lottery numbers: 23, 34, 17"
> "experimental results: 23, 34, 17"
>
> All written down on a bit of paper - same values discussed, but
> different data. Agree or disagree?

I agree.  Yes, same values but different data

> I ask this because if we can distinguish data and values, we must then
> determine /how/ they are different. You state it is by "encoding" but
> the two lines above are encoded in the same manner as far as I am
> concerned, so that cannot be the difference between the two concepts.
> That is unless your "Encodings" equates to my notion of "Facts", and
> we are thus agreeing loudly, using different definitions of those
> terms.

They are the same values and they are encoded in the same manner.
However they are distinct appearances, hence distinct data.

[snip]

> > Do you agree you cannot formalise what the values represent?
>
> Yes, imo no "meaning" can be represented via a purely descriptive
> formalism. One always needs some component situated in the real world
> for that. But obviously we can formalize communicated statements of
> fact.

I would say facts can be formalised to the extent that within a
context a tuple can be assumed to represent a fact.  But strictly
speaking within the formalism tuples themselves are really just
values.

[snip]

> > > This seem overly philosophical to me. Surely we don't need metaphysics
> > > to know that if someone hands me a bit of paper with: "1.00, 0.376 and
> > > 0.904" on it, well that's just a list of values. However if if someone
> > > hands you a bit of paper with "Surface Gravity - Earth:1.00, Mars:
> > > 0.376 and Venus:0.904", or tells you those denotations,  then we have
> > > data ;)
>
> > You have repeatedly chosen examples that suit your argument, whereas
> > according to our disagreement only I that have that privilege!
>
> > Jim:
> >     In all examples, data is useful to the recipient and
> >     represents facts
>
> Yes, of course, because the poem example is much harder for me to deal
> with ;P
>
>
> > David:
> >     1) In all examples, data is useful to the recipient and
> >        represents values; and
> >     2) There exists example where data is useful to the recipient
> >        and doesn't represent facts
>
> > Since a tuple of a relation is a value and it also represents a fact
> > it is clear that my definition of data encompasses yours.
>
> > We can both easily think of examples where (so called) data is useless
> > to the recipient.  Let's agree and say that's not actually data.  That
> > only leaves one possibility for proof by counter example:  I provide
> > an example where the data is useful to the recipient yet doesn't
> > convey any facts.   The sending of a poem or an image without any
> > additional context is an example.
>
> Well put. I contend that you can't do this, and that a poem or image
> as described is not an example of data, but merely values. You are
> saying to me "a poem is data. It is clearly not a fact. Ergo, pwnage."

In this discussion I would prefer to actually say "the appearance of a
poem is data".

> But you are already assuming it is data in the first step. I say its
> not, and cannot follow why you would think it is. Like a "22". That's
> not data but, if I was a numerologist say, I would still find the
> value interesting.

I keep thinking you're ignoring my qualification that it is the
appearance of a value that counts as data, not the value itself.

> So to me the poem is just a value.

Yes, but would you say the appearance of a value is just a value?

> Its only data when I say this thing
> here, X, has role Y.

We agree that a value doesn't have a context.  However the appearance
of a value *does* have a context.

> A picture is just a picture. Even if its, say, a
> biochemistry picture of a cell membrane. _However_ if that picture is
> then put in a log book, under "image of neurostem cell from experiment
> B",  its data. This accords to tradtional definitions.


You seem to have three distinct arguments.

1) Data requires knowledge in order to decode it as a value; and
   this knowledge is part of the data.

2) David has been saying data = value; and
   a value (is just a value and) doesn't have a context; and
   a conveyed value without a context is meaningless.

3) by definition data = encoded values that represent facts; so
   an encoded poem (with no additional context) is not data

Please tell me if I've misrepresented you!

I would say (1) doesn't actually lead to any differences in practise
over what we call data, making it appear rather metaphysical.

In my opinion (2) can be defeated for two different reasons
  a) David has actually been saying  data = appearance of value; and
     an appearance of a value has a context
  b) there exists examples (like a poem) where a conveyed value
without any
     additional context  is useful.

(3) leads to a difference on real examples, but I do find it
surprising that I could give you a disk with a web page encoded on it
and you would claim that it isn't actually data (but it may contain
data).


> I am offering you examples where you have an item that you would not
> describe as data, and showing how it is turned into something that is
> generally described as data. All best, have found the conversation so
> far well articulated, even if we don't agree.... Jim.

Also the conversation has been courteous.  Cheers!

0
davidbl (206)
2/15/2008 2:31:56 AM
On Feb 14, 11:04 pm, Bob Badour <bbad...@pei.sympatico.ca> wrote:

> If it is represented suitably for machine processing, it is data. It has
> value to the recipient as data because it evokes some emotion or image
> and because a machine can store it, transmit it, reformat it etc. The
> poem is also a fact. The poem doesn't convey a fact. It is one. Poem P
> says Blah.

The symbol P is presumably an identifier for the holder for the
appearance of the encoded poem.   Drawing the conclusion that the
value being encoded has in fact been encoded is rather sheepish to
me.   It is hardly a proposition that applies in a UoD in the normal
sense (ie where the UoD is independent of the medium on which the data
has been recorded).

0
davidbl (206)
2/15/2008 2:43:15 AM
On Feb 15, 12:03 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 14 Feb 2008 05:28:34 -0800 (PST), David BL wrote:
> > On Feb 14, 7:57 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Wed, 13 Feb 2008 17:21:42 -0800 (PST), David BL wrote:
> >>> On Feb 14, 7:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> >>> wrote:
> >>>> On Tue, 12 Feb 2008 20:48:47 -0800 (PST), David BL wrote:
> >>>>> Objects are said to have identity, state and behavior.   The idea that
> >>>>> an object can (always) be thought of as a (data) variable that can be
> >>>>> assigned a (data) value reveals a complete lack of understanding of
> >>>>> OO.
> >>>>> Bob's confusion between the concepts of object state versus object
> >>>>> value also leads him to misunderstand the significance of
> >>>>> encapsulation in the context of OO.
>
> >>>> I hate to agree with Bob Badour, but the notion of object is indeed
> >>>> superfluous. It is enough to have value, type, variable. Type has behavior.
> >>>> Variable has state. Identity can be attributed to a variable (the name of)
> >>>> or a value (the type of) or a type (the behavior of, or the name of, if
> >>>> named). What is specific to OO, that polymorphic values have identities of
> >>>> the corresponding specific types, which makes dispatch possible.
>
> >>> You appear to agree with Bob, but nothing could be further from the
> >>> truth.
>
> >>> Have you read the characterisations of value, variable and type by
> >>> C.Date?  They are very different to your above descriptions.
>
> >>> value :  doesn't exist in time or space.  Immutable
> >>> variable : can be assigned a value
>
> >> Was it his wording? I don't remember. Or, maybe, "assigned" above is meant
> >> not as an operation defined, but rather as:
>
> >>    variable : has a value
>
> > I checked C.Date's wording.  He says a variable is a holder for the
> > appearance of a value, and a variable can be updated - meaning that
> > the current value of the variable can be replaced by another value.
>
> I don't think that it is essential for a variable to be replaceable.
> Consider a type over a set with exactly one value. Can I have a variable
> of? In my view variable is just a mapping of the computational state onto
> the set of values of the type.

Agreed.

> >>> type :  set of values plus operations on those values
>
> >>> C.Date ignores the Liskov Substitution Principle (LSP) and states that
> >>> a circle is an ellipse, and that a coloured rectangle cannot be a
> >>> subtype of a rectangle.
>
> >> Well, circle is indeed an ellipse. It is just so that the implication
>
> >>    circle is a ellipse => circle is substitutable for ellipse
>
> >> is wrong.
>
> > I think you need to qualify that.  Using C.Date's definitions of type
> > and variable, a circle value is substitutable for an ellipse value,
> > whereas substitutability doesn't apply for variables.
>
> That makes the notion of subtype less interesting, especially if it would
> not apply to variables.

In a language that supports value-types properly, the following is
useful

    float GetArea(Ellipse e);

    Circle c;
    float a = GetArea(c);   // ok

GetArea()  takes an ellipse by value, and one can happily provide a
circle value (because every circle value is also an ellipse value).


Conversions of variables:  With in-out parameters on functions no
conversions are permitted.  However with a pure out parameter we
rightfully should support implicit upcast from address of ellipse
variable to address of circle variable as follows

    // Assign a circle value to the variable with address c.
    void AssignCircle(Circle* c);

    Ellipse e;
    AssignCircle(&e);	// ok

That this is possible also follows from the fact that every circle
value is also an ellipse value


> Further, the difference between values and
> variables is IMO not in immutability. Variable is an artefact of
> computation, a computational object. Value is outside, it is a semantic, a
> value of the object.

Agreed.


> > For an OO concept of type, substitutability of an object (ie
> > "variable") depends on whether the ellipse class provides any mutative
> > methods that could allow a circle object to stop being a circle.
>
> It is wider. It is about provable prepositions. Mutability is not an issue.
> One can express the problem without any mention of variables., fully
> immutably:
>
>    forall x,y in R exists Ellipse with x=axis1 and y=axis2   (1)
>
> Circle is not substitutable here. But circle is still an ellipse in the
> sense of injective mapping:
>
>    forall c of Circle exists e of Ellipse such that <no matter here>  (2)
>
> 2 does not imply 1. End of story.

Agreed

> The actual problem is that for software
> design a notion of subtype based on 2 is uninteresting because it is the
> things like 1 we want to deal with.

This is often true, perhaps even mostly true, but not always true.

> Subtypes aren't subsets, because
> subsets are too weak to judge about substitutability.
>
> One cannot reduce subtypes to subsets, or wider behavior to data.

I see it slightly differently - that there are two distinct and
incompatible notions of type.  Both are important.

Consider the function 1/x which is axiomatically defined on (nonzero)
reals but not the integers.  That suggests that Z is not a subtype of
R.  However consider

    float Invert(float x) { return 1/x; }

That doesn't stop us calling Invert(2) even though 2 is only an
integer.  We still get a float result!

As another example, I think a language can rightly support implicit
upcast of 16 bit integers to 32 bit integers.  Of course we have to
keep in mind that the modulo 2^16 operators are distinct from the
modulo 2^32 operators.


> > It is interesting that if a language were to properly support value
> > types then we actually would want to *drop* state in derived classes
> > because specialisations give you less degrees of freedom, not more.
>
> I think it is interface inheritance from concrete type, is what you want.
>
>
>
>
>
> > I have wondered whether a language along the following lines would be
> > appropriate:
>
> > type Rect
> > {
> >     int area { return width*height; }
> >     int width;
> >     int height;
> > };
>
> > type Square : Rect
> > {
> >     int height { return width; }
> > };
>
> > type UnitSquare : Square
> > {
> >     int width { return 1; }
> > };
>
> > void foo()
> > {
> >     UnitSquare s;
> >     int a = s.area;
> > }
>
> > I would hope that through in-lining the compiler simply initialises a
> > = 1.
>
> Yes, this is what I am arguing for years. This is exactly why there should
> be no such thing as "data" or "member." int width of the class rooted in
> Rect is pure behavior. It is incidentally implemented as a member (data)
> for the type Rect. That is an implementation detail, no more.

Yes, exactly.

I see it as only a convenience that one can specify the abstract
interface and a possible implementation at the same time.  Perhaps we
need something like this

abstract type Point;

type CartesianPoint : Point
{
    float r { return sqrt(x*x + y*y); }
    float theta { return atan2(y,x); }
    float x,y;
};

type PolarPoint : Point
{
    float x { return r*cos(theta); }
    float y { return r*sin(theta); }
    float r, theta;
};


> Another
> implementation from the class (UnitSquare) could implement it differently.
> So it is only the contracted behavior "get width of," which matters.
>
> >> Further a coloured rectangle can be substitutable for rectangle
> >> in some context.
>
> > I think you need to qualify that as well, because now it's the
> > reverse: substitutability makes sense for variables, but not for
> > values!
>
> There are types of substitutability. You seem to call substitutability only
> in-substitutability (that is - to be substitutable in the operations taking
> in-arguments). But out-substitutability is of no less interests, as you
> have out, in-out arguments and results of operations.

I think when I say "substitutability of values" I mean what you call
in-substitutability, and when I say "substitutability of variables" I
mean what you call out-substitutability.


> > C++ programmers refer to the slicing problem when an upcast of a value
> > slices away some of its state.  A coloured rectangle value can easily
> > have its colour sliced away.
>
> Which has to be this way. A colored rectangle value cannot be passed as a
> rectangle value, that would be a type error. It must be converted first.
> The result forgets anything it was before. As C.Date stays, values exist
> out of time, there is no any history of. So it has no color. The rest is a
> design fault of C++. It shall not dispatch on specific rectangle values.
> That breaks the contract of the corresponding type. One can dispatch on
> polymorphic values only.

Agreed.

> > I guess I need better words.  Note however that I don't think
> > "behaviour" in the sense of conventional OO is relevant to value-
> > types.  Values are immutable and all updates to variables are
> > assignments.  A variable doesn't have a chance to exhibit behaviour!
> > At a certain level of abstraction all operators defined on a value
> > type can be assumed to act on pure inputs and return pure outputs.
>
> Yes. Just one note, values expose behavior of their type. The behavior of
> 1, an integer value, is in part that there exits 2, an integer value such
> that Inc(1)=2. Nothing beyond that. Behavior does not imply either
> statefulness or identity.

Yes.
0
davidbl (206)
2/15/2008 4:27:52 AM
On Feb 15, 2:24 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> JOG wrote:
> > On Feb 14, 10:57 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >>On Wed, 13 Feb 2008 17:21:42 -0800 (PST), David BL wrote:
> >>>On Feb 14, 7:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> >>>wrote:
> >>>>On Tue, 12 Feb 2008 20:48:47 -0800 (PST), David BL wrote:
>
> >>>>>Objects are said to have identity, state and behavior.   The idea that
> >>>>>an object can (always) be thought of as a (data) variable that can be
> >>>>>assigned a (data) value reveals a complete lack of understanding of
> >>>>>OO.
> >>>>>Bob's confusion between the concepts of object state versus object
> >>>>>value also leads him to misunderstand the significance of
> >>>>>encapsulation in the context of OO.
>
> >>>>I hate to agree with Bob Badour, but the notion of object is indeed
> >>>>superfluous. It is enough to have value, type, variable. Type has behavior.
>
> Don't be a hater. You can love to disagree with me without hating to agree.
>
>
>
>
>
> >>>>Variable has state. Identity can be attributed to a variable (the name of)
> >>>>or a value (the type of) or a type (the behavior of, or the name of, if
> >>>>named). What is specific to OO, that polymorphic values have identities of
> >>>>the corresponding specific types, which makes dispatch possible.
>
> >>>You appear to agree with Bob, but nothing could be further from the
> >>>truth.
>
> >>>Have you read the characterisations of value, variable and type by
> >>>C.Date?  They are very different to your above descriptions.
>
> >>>value :  doesn't exist in time or space.  Immutable
> >>>variable : can be assigned a value
>
> >>Was it his wording? I don't remember. Or, maybe, "assigned" above is meant
> >>not as an operation defined, but rather as:
>
> >>   variable : has a value
>
> >>>type :  set of values plus operations on those values
>
> >>>C.Date ignores the Liskov Substitution Principle (LSP) and states that
>
> Actually, D&D address Liskov directly. One wonders whether David
> bothered to read them. If he did, one can only conclude he has
> difficulty comprehending written english.

C.Date discusses LSP but discounts it as inapplicable to his notion of
subtyping - which has to do with *value* substitutability.   LSP
concerns substitutability of objects, and Bob will be the first to
tell you that these are variables (not values).


> >>>a circle is an ellipse, and that a coloured rectangle cannot be a
> >>>subtype of a rectangle.
>
> >>Well, circle is indeed an ellipse.
>
> And a coloured rectangle is a composition of a colour and a rectangle.
> Only an ignorant moron would demand compositions be subtypes of their
> components. Duh! ::rolls eyes::
>
> > I /believe/ what Date would say (and its certainly what I would say
> > even if he has not) is that a set of points has the properties
> > qualifying it as a "circle" as well as those qualifying it as an
> > "ellipse". Two parallel views of the same underlying data.
>
> Actually, the more interesting thing Date said is the addresses of
> ellipse variables are a subtype of the addresses of circle variables.
> They are a subset of the addresses where one can store a circle value,
> and they have a superset of the (assignment) operations.

Bob seems to have neglected the fact that variables can be read (as
well as written), which means it isn't true that a pointer to an
ellipse variable is a pointer to a circle variable.

Example

    float GetArea(Circle* c)
    {
        return PI*c->GetRadius()*c->GetRadius();
    }

    Ellipse e;
    float a = GetArea(&e);	// oops

> It is always true that the addresses of a supertype's variables are a
> subtype of the addresses of a subtype's variables.

Not true.

[snip]
0
davidbl (206)
2/15/2008 4:59:11 AM
On Feb 15, 1:27 pm, David BL <davi...@iinet.net.au> wrote:

> I think when I say "substitutability of values" I mean what you call
> in-substitutability, and when I say "substitutability of variables" I
> mean what you call out-substitutability.

I take back my claim that "substitutability of variables" means out-
substitutability.  I think it should encompass both in-
substitutability and out-substitutability.

Therefore I was wrong to suggest that a pointer to a ColouredRectangle
variable could be implicit cast to a pointer to a Rectangle variable,
because it can lead to subsequent slicing.   In the end it's better
just to say that subtyping ColouredRectangle from Rectangle doesn't
make sense and leave it at that.

If we go back to the much more sensible example of value-type
inheritance of circle from ellipse we see that a circle is in-
substitutable for an ellipse, whereas an ellipse is out-substitutable
for a circle.  That suggests to me that a language must distinguish
out parameters from in-out parameters, and therefore passing out-
parameters using pointers to variables isn't the right approach.

In the following example an ellipse is out-substitutable for a circle:

    // declaration
    Circle foo();

    // call
    Ellipse e = foo();

I'm not sure I like this terminology of in-substitutable and out-
substitutable.  It seems easier to me to just remember that a circle
value is an ellipse value and note that in-parameters narrow whereas
out-parameters widen.

One of the reasons people tend to pass out parameters as pointer
arguments is to support multiple out parameters.  I rather like the
idea of a language that supports a tuple syntax for multiple out
parameters.  Eg

    // definition
    (Circle c, int x) foo()
    {
        // Can assign named out-parameters c,x
        // No need for a 'return' statement!
        c = Circle( Point(0,0), 10 );
        x = 1;
    }

    // call
    (Ellipse e, int x) = foo();

0
davidbl (206)
2/15/2008 9:12:22 AM
On Fri, 15 Feb 2008 01:12:22 -0800 (PST), David BL wrote:

> On Feb 15, 1:27 pm, David BL <davi...@iinet.net.au> wrote:
> 
>> I think when I say "substitutability of values" I mean what you call
>> in-substitutability, and when I say "substitutability of variables" I
>> mean what you call out-substitutability.
> 
> I take back my claim that "substitutability of variables" means out-
> substitutability.  I think it should encompass both in-
> substitutability and out-substitutability.
> 
> Therefore I was wrong to suggest that a pointer to a ColouredRectangle
> variable could be implicit cast to a pointer to a Rectangle variable,
> because it can lead to subsequent slicing.

An important node. Pointer is a data type distinct from the data type of
what it is supposed to point to. What you probably meant is that there
exists a mapping: f : ColouredRectangle -> Rectangle. Which in dreadful C++
notation looks like

   *(Rectangle *)&

(a composition: &, casting and *). In a decent language, which C++ is not,
the operation * should not be allowed for all types indiscriminately. That
makes optimization quite difficult. What if Rectangle "physically exists"
on a different machine in a DB? How can I get its pointer? What is this
pointer? etc. Getting rid of data, also eliminates hard-wired data things
like pointers. Instead you get behavior of some objects referencing others.

> In the end it's better
> just to say that subtyping ColouredRectangle from Rectangle doesn't
> make sense and leave it at that.

But there exists a mapping between them, which makes possible for
ColouredRectangle to be an extension of Rectangle. In practical terms it
means that ColouredRectangle can be out-substitutable for Rectangle:

   Give_Me_One : <something> -> Rectangle

(this case you considered for circle/ellipse later)

> If we go back to the much more sensible example of value-type
> inheritance of circle from ellipse we see that a circle is in-
> substitutable for an ellipse, whereas an ellipse is out-substitutable
> for a circle.  That suggests to me that a language must distinguish
> out parameters from in-out parameters, and therefore passing out-
> parameters using pointers to variables isn't the right approach.

Sure. Note that out and by-reference are different issues. You can have
copy-out passing for by-value types, and copy-in-copy-out for in-out ones.
It is an implementation issue.

As for pointers, it is yet another story. T* can be considered as a
subtype/supertype of T with all issues of substitutability. For instance,
null is not substitutable in any of the operations of T.
 
> In the following example an ellipse is out-substitutable for a circle:
> 
>     // declaration
>     Circle foo();
> 
>     // call
>     Ellipse e = foo();
> 
> I'm not sure I like this terminology of in-substitutable and out-
> substitutable.  It seems easier to me to just remember that a circle
> value is an ellipse value and note that in-parameters narrow whereas
> out-parameters widen.

Ah, this is a crucial point. Circle value is not an ellipse value. These
have different types. It is only so that there exists a mapping which gives
you an ellipse value from any circle value.

> One of the reasons people tend to pass out parameters as pointer
> arguments is to support multiple out parameters.  I rather like the
> idea of a language that supports a tuple syntax for multiple out
> parameters.  Eg
> 
>     // definition
>     (Circle c, int x) foo()
>     {
>         // Can assign named out-parameters c,x
>         // No need for a 'return' statement!
>         c = Circle( Point(0,0), 10 );
>         x = 1;
>     }
> 
>     // call
>     (Ellipse e, int x) = foo();

Right. Anonymous ad-hoc types would make life a lot easier. But again, a
tuple is a new type with all potential problems of substitutability. Same
as with pointers, you might wish to consider (T) substitutable for T and
reverse, for obvious reasons. Or maybe even (T, ...) for T, which would be
in-substitutable of course. The problem is fundamental, and it does not
have a universal solution, alas.

What the language should deliver is a clean types model.

As for subtyping, to me, it is just a relation between types. I don't
expect it to deliver substitutability. It cannot. What it can and should,
is to help me to deal with the problem.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/15/2008 11:13:33 AM
On Feb 14, 2:04 pm, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> JOG wrote:
> > On Feb 14, 3:52 am, David BL <davi...@iinet.net.au> wrote:
>
> >>On Feb 13, 9:56 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> >>>On Feb 13, 2:06 am, David BL <davi...@iinet.net.au> wrote:
>
> >>>>On Feb 12, 9:53 pm, JOG <j...@cs.nott.ac.uk> wrote:
> >>>>[snip]
>
> >>>>>Consider /unallocated/ RAM in your PC. Look at 5 contiguous bits at
> >>>>>random. Are you telling me that the binary number you are looking at
> >>>>>is "data"? I'd accept that it is a value (albeit a meaningless one)
> >>>>>but "data"? You really think that?
>
> >>>>No I don't.
>
> >>>>When data is recorded on some medium there is a lot of implicit
> >>>>*knowledge* about how it has been encoded.  This knowledge has to
> >>>>account for all sorts of details, such as what designates a 1 versus a
> >>>>0.   How many bits in a word?  What order do they appear in?  Is there
> >>>>an address bus?  How is the address bus organised?  The binary
> >>>>encoding is only a tiny part of it.  Obviously we both agree that all
> >>>>that knowledge is implicit in correctly decoding the data.
>
> >>>Yes I broadly agree apart from on one key matter (there's a suprise
> >>>eh) - "knowledge is implict". I contend the exact opposite, and this
> >>>is my whole point really. The knowledge required must be explicit.
> >>>That's what makes otherwise random noise, or values, data.  In the
> >>>case of a scientist log book for example what the data means is
> >>>explicit in a title at the top of the page or in the scientist's
> >>>head.
>
> >>You can't make the knowledge explicit because you can't formalise it.
>
> >>>Another example:
> >>>"todays lottery numbers: 23, 34, 17"
> >>>"experimental reults: 23, 34, 17"
>
> >>>Same values, different data. If you agree with this statement then
> >>>values != data surely?
>
> >>You seem to have forgotten that I said data was associated with the
> >>appearance (ie encoding) of values.
>
> > Nicely dodged, but let me try again!
>
> > "todays lottery numbers: 23, 34, 17"
> > "experimental results: 23, 34, 17"
>
> > All written down on a bit of paper - same values discussed, but
> > different data. Agree or disagree?
>
> > I ask this because if we can distinguish data and values, we must then
> > determine /how/ they are different. You state it is by "encoding" but
> > the two lines above are encoded in the same manner as far as I am
> > concerned, so that cannot be the difference between the two concepts.
> > That is unless your "Encodings" equates to my notion of "Facts", and
> > we are thus agreeing loudly, using different definitions of those
> > terms.
>
> >>Encodings have a context, and
> >>values do not.  We don't disagree on whether data is associated with
> >>encodings.  Rather we disagree on what is being encoded.  I say data =
> >>encoded values.  (I think) you say data = encoded facts.
>
> >>>>Our point of contention is rather that I suggest that most generally
> >>>>the data is nothing other than encoded values, and doesn't necessarily
> >>>>convey any facts.   I'm assuming that the knowledge implicit in the
> >>>>encoding of the data is by definition not part of the data itself,
> >>>>whereas I think you are suggesting it is part of the data.
>
> >>>Yes I think that's an excellent breakdown. Its all just down to where
> >>>we draw the lines I guess...
> >>>Brian: Data is encoded values. I need to know externally what they
> >>>represent.
> >>>Jim: Data is encoded values plus an denotation of what they represent.
>
> >>Did you mean to say Brian?
>
> > No I meant to say David. Apologies.
>
> >>Do you agree you cannot formalise what the values represent?
>
> > Yes, imo no "meaning" can be represented via a purely descriptive
> > formalism. One always needs some component situated in the real world
> > for that. But obviously we can formalize communicated statements of
> > fact.
>
> >>[schnnnip]
>
> >>>>>>C.Date distinguishes between a value (that by definition doesn't exist
> >>>>>>in time and space), versus the *appearance* of a value which appears
> >>>>>>in time and space and is encoded in a particular way.
>
> >>>>>Is this what your view of the terms is based upon?
>
> >>>>These definitions seems reasonable to me.
>
> >>>This seem overly philosophical to me. Surely we don't need metaphysics
> >>>to know that if someone hands me a bit of paper with: "1.00, 0.376 and
> >>>0.904" on it, well that's just a list of values. However if if someone
> >>>hands you a bit of paper with "Surface Gravity - Earth:1.00, Mars:
> >>>0.376 and Venus:0.904", or tells you those denotations,  then we have
> >>>data ;)
>
> >>You have repeatedly chosen examples that suit your argument, whereas
> >>according to our disagreement only I that have that privilege!
>
> >>Jim:
> >>    In all examples, data is useful to the recipient and
> >>    represents facts
>
> > Yes, of course, because the poem example is much harder for me to deal
> > with ;P
>
> >>David:
> >>    1) In all examples, data is useful to the recipient and
> >>       represents values; and
> >>    2) There exists example where data is useful to the recipient
> >>       and doesn't represent facts
>
> >>Since a tuple of a relation is a value and it also represents a fact
> >>it is clear that my definition of data encompasses yours.
>
> >>We can both easily think of examples where (so called) data is useless
> >>to the recipient.  Let's agree and say that's not actually data.  That
> >>only leaves one possibility for proof by counter example:  I provide
> >>an example where the data is useful to the recipient yet doesn't
> >>convey any facts.   The sending of a poem or an image without any
> >>additional context is an example.
>
> > Well put. I contend that you can't do this, and that a poem or image
> > as described is not an example of data, but merely values.
>
> If it is represented suitably for machine processing, it is data.

So before computers there was no data? Really?

> It has
> value to the recipient as data because it evokes some emotion or image
> and because a machine can store it, transmit it, reformat it etc. The
> poem is also a fact. The poem doesn't convey a fact. It is one. Poem P
> says Blah.
>
> [misguided argument snipped]

0
jog (83)
2/15/2008 11:14:15 AM
On Thu, 14 Feb 2008 20:27:52 -0800 (PST), in
comp.object,comp.databases.theory you wrote:

[snip, pointer issues, replied in another post ]
 
>> Subtypes aren't subsets, because
>> subsets are too weak to judge about substitutability.
>>
>> One cannot reduce subtypes to subsets, or wider behavior to data.
> 
> I see it slightly differently - that there are two distinct and
> incompatible notions of type.  Both are important.
> 
> Consider the function 1/x which is axiomatically defined on (nonzero)
> reals but not the integers.  That suggests that Z is not a subtype of
> R.  However consider
> 
>     float Invert(float x) { return 1/x; }
> 
> That doesn't stop us calling Invert(2) even though 2 is only an
> integer.  We still get a float result!

I think there is a confusion here. Note that invert as an operation deals
with a tuple float x float:

   Invert : float -> float

Now, the question is where are you going to substitute ints?

1. In the first appearance of float
2. In the second one (result)
3. In both

Depending on that Invert will become inheritable or not. I.e
substitutability is not only parameter mode depending, it also depends on
the concrete parameters too. (For the sake of genericity, results are
parameters.)

> As another example, I think a language can rightly support implicit
> upcast of 16 bit integers to 32 bit integers.  Of course we have to
> keep in mind that the modulo 2^16 operators are distinct from the
> modulo 2^32 operators.

Also, these examples are all about specialization vs. generalization. Which
are "relatively" simple. But there are much more difficult cases where
there is no any injective mapping between two sets. Yet substitutability is
highly desired. Consider two color models. Most colors would have a
representation in both models, but some colors would be unique in either.
Or take fixed point and floating point numbers.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/15/2008 11:20:46 AM
Tegiri Nenashi wrote:
> mAsterdam wrote:
>> Marshall wrote:
>>> Tegiri Nenashi wrote:
>>>> The Galois duality between attributes and objects
>>> Oh, shit. What does that mean? I have this intuition that
>>> you've just said something that it's important that I learn about.
>>> Marshall
>>> PS. And I'm still meaning to follow up on the Galois connection
>>> between syntax and semantics... need more Tarski. Mumble
>>> mumble. Have to finish that axiomatic set theory book, then
>>> need to read about model theory. Argh.
>> Yes, V^H Nenashi, please elaborate for us mere mortals :-)
> 
> I thought Marshall was joking. Anyway, don't take my word for it,
> Galois connections are mentioned in about every FCA paper.

He may have been. I wasn't. In the coming days I won't be posting 
much, I suspect :-) Thank you for these references:

> Here is FCA home page
> http://www.upriss.org.uk/fca/fca.html
> and introductory article
> http://www.upriss.org.uk/papers/arist.pdf
> There is even free software to play with, e.g ConceptExplorer!

0
mAsterdam (155)
2/15/2008 12:50:38 PM
On Fri, 15 Feb 2008 00:41:37 +0100, mAsterdam wrote:

> Dmitry A. Kazakov wrote:
>> mAsterdam wrote:
>> 
>> But you certainly should have a mental picture
>> where "data" plays some role. 
> 
> Is it necessary for both sides of the border to fully understand the
> formalisms en vogue at the other side? I don't think so.
> Your position - I trust you'll correct me if I'm wrong -
> is: there is no data, no other side, no border to cross.

Maybe what you are using "data" for, could be common.

>> Let you to tried to formalize it. You would describe some properties
>> and axioms about "data". You would also like to remove much of unnecessary
>> and uncertain things (like 1-5 from there). What I tried to say is that
>> after doing this, you could probably notice that you can remove "data" from
>> your system without any loss...
>> 
>>> Which primitive elements does your formal system have?
>> 
>> Value, type, variable, operation.
> 
> That looks rich enough to get somewhere.
> 
> Somewhat OT to this thread - just because I am curious:
> do you have a reference to definitions/descriptions of how these act 
> together you consider worthwhile?

Date's definitions were OK for values and types. Any value has exactly one
type. Variables map the computational states onto values. I think it would
be more or less acceptable for anybody. Much more difficult is to agree on
subtype and class. Class is a set of types. Subtype is a type relation of
some properties (transitive, reflexive etc), and so on.
 
>>>> Bad. It means that you have to formalize "memorize" in some quite tricky
>>>> way. Honestly I don't know what could be the difference between "memorized
>>>> Pi", "not-yet-memorized Pi", "once-memorized-but-forgotten-by-now Pi" and
>>>> so on.
>>> Are you suggesting � is data?
>> 
>> Yes. But you can take some P(pi)=true instead.
> 
> Or R(P(�)) - packaging a symbol/value doesn't make it data.
> In order to be data it should convey a fact, relevant in a
> sense outside the formal system, i.e. an observation, or the basis
> for a decision.

Then I see no disagreement anymore. Is all that rant going on for years
between c.d.t and c.o just about what to feed to the beast?

[ BTW, it was exactly the point I made in my first post to this thread. It
is not about theory it is about selling stuff = making sense outside the
system = getting money out of customers. (:-)) ]

>>>>>> May I translate data into a different
>>>>>> representation and then erase the original record? 
>>>>>> Will data still be there?
>>>>> Iff it conveys the same facts as the original record, sure.
>>>> OK, that means that data = facts + record medium of:
>>>>
>>>> D = (F, R)
>>> Guessing about your notation as D denotes Data, F denotes Facts, R is 
>>> the requirement that the fact is recorded, R is just 1.
>> 
>> (A side question, in "R is just 1", were "just 1" data or fact?)
> 
> It is the 'recorded' property of the fact.
> As you deny the existence of facts and data
> I don't see how this is relevant to you.

In order to be able say, that the property (or whatever) "is 1" has to be
data (to be any "useful", using your terms). Thus it itself needs this
property, which constitutes an infinite recursion.

>> And, equivalently, you cannot describe
>> recording in terms of either data or facts.
> 
> Yep, that's the fate of primitives and semi-primitives.

In other words being recorded / data is incomputable.

>> But I see no disagreement in the core issue: 
>> a formal system does not operate meanings.
> 
> I see no agreement to the core issue:
> A formal system needs to support meaning to be useful.

"To support" needs to be defined. If you mere mean self-consistency or
Turing-completeness, then it is OK. If you mean something finer than that,
you have to say what. Anyway it would be not "I want data, else there is no
common ground." It would be about the structure of the formal system which
you wished deploy for what you call data. (Maybe, I could to do it as well,
but for something having a different name.)

>> It is we who assign meanings to the inputs and outputs, and, at
>> yet another level of understanding, judge about the formal system as a
>> whole in terms of its usefulness, for example.
> 
> It is IPO vs. IDO (late 70's debate) all over:
> 
> Input values - Process - Output values: It does not matter what the 
> input means, as long as the output is correctly processed from the input.
> 
> Input process - Data - Output process: The input process (datacapture) 
> is to be constrained in order to prevent inconsistencies in the data. 
> The output process (rendering) should be validated not to corrrupt 
> meaning. "You have  01 vacation days left". Ouch - but just within the 
> currently acceptable range.

In both cases you constrain a process. So if complementary of views was
your point, I think it is invalid. Further if you want to deal with D in
IDO, you need a language to describe D. That is a formal system, a process.
I.e. you cannot abstract D out of some processes, generating, carrying,
understanding data.

>>>> Yes, we cannot reason about meaning while staying 
>>>> within the same formal system.
>>>> Because you seem to bind data with a meaning (as I do), that immediately
>>>> kicks the notion of data out of the formal system. So data do not exist
>>>> there. Which is all my point! No data, nothing to worry about.
>>> And the result is a hermetic system as useful as solipsism.
>>> Have some fun there! I'm out waiting until you are bored of it.
>> 
>> OK, I am back on vacation. How are you going to formalize something which
>> cannot be formalized? (:-))
> 
> Hey, I am not the one eager to formalize without
> a proper, shared, informal understanding.

Neither I am. But shared can be also a method of understanding. You
consider understanding as a premise (data (:-)). Do it rather as process
(behavior (:-)).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/15/2008 2:43:39 PM
On 2008-02-14 11:45:36 -0600, "David Cressey" <cressey73@verizon.net> said:

> I was referring to Bob Badour,  not to you.  None of your messages have
> carried even a hint of rudeness.
> 
> Sorry for the ambiguous reference.

No problem.  I killfiled that bad odor years ago so I didn't see the 
connection.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/15/2008 3:57:19 PM
On 2008-02-14 10:31:15 -0600, topmind <topmind@technologist.com> said:

> I'm sorry people, but this is rimming over the pan with gobs of
> Bullshit. Politeness is off for this one.

Fine.  Then I'm not going to discuss it with you.  Rave on.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
2/15/2008 4:04:18 PM
On Feb 14, 8:59 pm, David BL <davi...@iinet.net.au> wrote:
>
> ... variables can be read (as
> well as written), which means it isn't true that a pointer to an
> ellipse variable is a pointer to a circle variable.

The problem arises when you have all of:
1) mutability
2) first-class variables
3) subtyping

You can't pin the problem on any one of these; the problem
is in the combination.


Marshall
0
2/15/2008 4:27:16 PM
On Feb 15, 3:13 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>
> Ah, this is a crucial point. Circle value is not an ellipse value. These
> have different types.

You shouldn't let your history with type systems influence your
thinking to the degree that you say obviously false things like
"Circle value is not an ellipse value." Such unqualified statements
obscure rather than illuminate. It would be better to say that
within a given type system we might give up the mathematical
fact that a circle is an ellipse in favor of other properties we
might find more useful.


Marshall
0
2/15/2008 4:43:35 PM
On Feb 15, 8:20 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 14 Feb 2008 20:27:52 -0800 (PST), in

> > Consider the function 1/x which is axiomatically defined on (nonzero)
> > reals but not the integers.  That suggests that Z is not a subtype of
> > R.  However consider
>
> >     float Invert(float x) { return 1/x; }
>
> > That doesn't stop us calling Invert(2) even though 2 is only an
> > integer.  We still get a float result!
>
> I think there is a confusion here. Note that invert as an operation deals
> with a tuple float x float:
>
>    Invert : float -> float
>
> Now, the question is where are you going to substitute ints?
>
> 1. In the first appearance of float
> 2. In the second one (result)
> 3. In both
>
> Depending on that Invert will become inheritable or not. I.e
> substitutability is not only parameter mode depending, it also depends on
> the concrete parameters too. (For the sake of genericity, results are
> parameters.)

I'm aware of the three conceivable options, but I'm quite clear in my
mind that the system should only support the narrowing of in-
parameters and widening of out-parameters.  Therefore, as Invert() has
been written (1) is the only option.  If you want option (3) then you
need to explicitly write a parameterised function.  Eg

    template <class T> T Invert(T x) { return 1/x; }

However it seems inappropriate to allow Invert<int>().

When C.Date talks about value substitutability he doesn't mean you can
pick any function you like and substitute a sub-type in place of a
super-type throughout the function.  Doing so gives you a *distinct*
function and the system is not allowed to guess that it is meaningful
to do so.  If you wanted this to be valid, then it would greatly
restrict possible sub-typing relationships and that limits code
reuse.  In particular, it would no longer be possible to treat Z as a
subtype of R.  Probably some mathematicians would think that is
sensible since the system Z doesn't inherit the axiom for existence of
multiplicative inverses from R.  However, I prefer the idea that
algorithms are parameterised explicitly where appropriate, and only
let the system perform implicit type conversions on in/out parameters
or assignments.

[snip]

0
davidbl (206)
2/15/2008 4:46:54 PM
JOG wrote:

> On Feb 14, 2:04 pm, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> 
>>JOG wrote:
>>
>>>On Feb 14, 3:52 am, David BL <davi...@iinet.net.au> wrote:
>>
>>>>On Feb 13, 9:56 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>
>>>>>On Feb 13, 2:06 am, David BL <davi...@iinet.net.au> wrote:
>>
>>>>>>On Feb 12, 9:53 pm, JOG <j...@cs.nott.ac.uk> wrote:
>>>>>>[snip]
>>
>>>>>>>Consider /unallocated/ RAM in your PC. Look at 5 contiguous bits at
>>>>>>>random. Are you telling me that the binary number you are looking at
>>>>>>>is "data"? I'd accept that it is a value (albeit a meaningless one)
>>>>>>>but "data"? You really think that?
>>
>>>>>>No I don't.
>>
>>>>>>When data is recorded on some medium there is a lot of implicit
>>>>>>*knowledge* about how it has been encoded.  This knowledge has to
>>>>>>account for all sorts of details, such as what designates a 1 versus a
>>>>>>0.   How many bits in a word?  What order do they appear in?  Is there
>>>>>>an address bus?  How is the address bus organised?  The binary
>>>>>>encoding is only a tiny part of it.  Obviously we both agree that all
>>>>>>that knowledge is implicit in correctly decoding the data.
>>
>>>>>Yes I broadly agree apart from on one key matter (there's a suprise
>>>>>eh) - "knowledge is implict". I contend the exact opposite, and this
>>>>>is my whole point really. The knowledge required must be explicit.
>>>>>That's what makes otherwise random noise, or values, data.  In the
>>>>>case of a scientist log book for example what the data means is
>>>>>explicit in a title at the top of the page or in the scientist's
>>>>>head.
>>
>>>>You can't make the knowledge explicit because you can't formalise it.
>>
>>>>>Another example:
>>>>>"todays lottery numbers: 23, 34, 17"
>>>>>"experimental reults: 23, 34, 17"
>>
>>>>>Same values, different data. If you agree with this statement then
>>>>>values != data surely?
>>
>>>>You seem to have forgotten that I said data was associated with the
>>>>appearance (ie encoding) of values.
>>
>>>Nicely dodged, but let me try again!
>>
>>>"todays lottery numbers: 23, 34, 17"
>>>"experimental results: 23, 34, 17"
>>
>>>All written down on a bit of paper - same values discussed, but
>>>different data. Agree or disagree?
>>
>>>I ask this because if we can distinguish data and values, we must then
>>>determine /how/ they are different. You state it is by "encoding" but
>>>the two lines above are encoded in the same manner as far as I am
>>>concerned, so that cannot be the difference between the two concepts.
>>>That is unless your "Encodings" equates to my notion of "Facts", and
>>>we are thus agreeing loudly, using different definitions of those
>>>terms.
>>
>>>>Encodings have a context, and
>>>>values do not.  We don't disagree on whether data is associated with
>>>>encodings.  Rather we disagree on what is being encoded.  I say data =
>>>>encoded values.  (I think) you say data = encoded facts.
>>
>>>>>>Our point of contention is rather that I suggest that most generally
>>>>>>the data is nothing other than encoded values, and doesn't necessarily
>>>>>>convey any facts.   I'm assuming that the knowledge implicit in the
>>>>>>encoding of the data is by definition not part of the data itself,
>>>>>>whereas I think you are suggesting it is part of the data.
>>
>>>>>Yes I think that's an excellent breakdown. Its all just down to where
>>>>>we draw the lines I guess...
>>>>>Brian: Data is encoded values. I need to know externally what they
>>>>>represent.
>>>>>Jim: Data is encoded values plus an denotation of what they represent.
>>
>>>>Did you mean to say Brian?
>>
>>>No I meant to say David. Apologies.
>>
>>>>Do you agree you cannot formalise what the values represent?
>>
>>>Yes, imo no "meaning" can be represented via a purely descriptive
>>>formalism. One always needs some component situated in the real world
>>>for that. But obviously we can formalize communicated statements of
>>>fact.
>>
>>>>[schnnnip]
>>
>>>>>>>>C.Date distinguishes between a value (that by definition doesn't exist
>>>>>>>>in time and space), versus the *appearance* of a value which appears
>>>>>>>>in time and space and is encoded in a particular way.
>>
>>>>>>>Is this what your view of the terms is based upon?
>>
>>>>>>These definitions seems reasonable to me.
>>
>>>>>This seem overly philosophical to me. Surely we don't need metaphysics
>>>>>to know that if someone hands me a bit of paper with: "1.00, 0.376 and
>>>>>0.904" on it, well that's just a list of values. However if if someone
>>>>>hands you a bit of paper with "Surface Gravity - Earth:1.00, Mars:
>>>>>0.376 and Venus:0.904", or tells you those denotations,  then we have
>>>>>data ;)
>>
>>>>You have repeatedly chosen examples that suit your argument, whereas
>>>>according to our disagreement only I that have that privilege!
>>
>>>>Jim:
>>>>   In all examples, data is useful to the recipient and
>>>>   represents facts
>>
>>>Yes, of course, because the poem example is much harder for me to deal
>>>with ;P
>>
>>>>David:
>>>>   1) In all examples, data is useful to the recipient and
>>>>      represents values; and
>>>>   2) There exists example where data is useful to the recipient
>>>>      and doesn't represent facts
>>
>>>>Since a tuple of a relation is a value and it also represents a fact
>>>>it is clear that my definition of data encompasses yours.
>>
>>>>We can both easily think of examples where (so called) data is useless
>>>>to the recipient.  Let's agree and say that's not actually data.  That
>>>>only leaves one possibility for proof by counter example:  I provide
>>>>an example where the data is useful to the recipient yet doesn't
>>>>convey any facts.   The sending of a poem or an image without any
>>>>additional context is an example.
>>
>>>Well put. I contend that you can't do this, and that a poem or image
>>>as described is not an example of data, but merely values.
>>
>>If it is represented suitably for machine processing, it is data.
> 
> So before computers there was no data? Really?

Of course there was. Computers are not the only machines.


>>It has
>>value to the recipient as data because it evokes some emotion or image
>>and because a machine can store it, transmit it, reformat it etc. The
>>poem is also a fact. The poem doesn't convey a fact. It is one. Poem P
>>says Blah.
>>
>>[misguided argument snipped]
0
bbadour (434)
2/15/2008 5:27:18 PM
Marshall wrote:

> On Feb 14, 8:59 pm, David BL <davi...@iinet.net.au> wrote:
> 
>>... variables can be read (as
>>well as written), which means it isn't true that a pointer to an
>>ellipse variable is a pointer to a circle variable.

Apparently, David cannot follow written english.


> The problem arises when you have all of:
> 1) mutability
> 2) first-class variables
> 3) subtyping
> 
> You can't pin the problem on any one of these; the problem
> is in the combination.

What was the problem again?
0
bbadour (434)
2/15/2008 5:31:42 PM
On Fri, 15 Feb 2008 08:43:35 -0800 (PST), Marshall wrote:

> On Feb 15, 3:13 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>>
>> Ah, this is a crucial point. Circle value is not an ellipse value. These
>> have different types.
> 
> You shouldn't let your history with type systems influence your
> thinking to the degree that you say obviously false things like
> "Circle value is not an ellipse value." Such unqualified statements
> obscure rather than illuminate. It would be better to say that
> within a given type system we might give up the mathematical
> fact that a circle is an ellipse in favor of other properties we
> might find more useful.

I don't give up anything. Mathematical "is" merely means that there exists
an injective mapping from the set of circles to the set of ellipses. As
this stays true for the values, circle is an ellipse. Yet circle value is
not an ellipse value. Even after anybody would define an equivalence
operation (=) on the corresponding types, they will be of different types.
However if your circle and ellipse types are supposed to *model* the
corresponding geometrical objects, you certainly will do that, in order to
*mean" a geometrical circle when you use a circle value.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/15/2008 8:22:26 PM
On Fri, 15 Feb 2008 08:46:54 -0800 (PST), David BL wrote:

> On Feb 15, 8:20 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 14 Feb 2008 20:27:52 -0800 (PST), in
> 
>>> Consider the function 1/x which is axiomatically defined on (nonzero)
>>> reals but not the integers.  That suggests that Z is not a subtype of
>>> R.  However consider
>>
>>>     float Invert(float x) { return 1/x; }
>>
>>> That doesn't stop us calling Invert(2) even though 2 is only an
>>> integer.  We still get a float result!
>>
>> I think there is a confusion here. Note that invert as an operation deals
>> with a tuple float x float:
>>
>>    Invert : float -> float
>>
>> Now, the question is where are you going to substitute ints?
>>
>> 1. In the first appearance of float
>> 2. In the second one (result)
>> 3. In both
>>
>> Depending on that Invert will become inheritable or not. I.e
>> substitutability is not only parameter mode depending, it also depends on
>> the concrete parameters too. (For the sake of genericity, results are
>> parameters.)
> 
> I'm aware of the three conceivable options, but I'm quite clear in my
> mind that the system should only support the narrowing of in-
> parameters and widening of out-parameters.

It is an arbitrary constraint, worse is that it kills any algebraic
operations.

>Therefore, as Invert() has
> been written (1) is the only option.

As a counterexample, consider C (complex) instead of Z.

> If you want option (3) then you
> need to explicitly write a parameterised function.  Eg
> 
>     template <class T> T Invert(T x) { return 1/x; }
> 
> However it seems inappropriate to allow Invert<int>().

From the language design point of view there is no any problem because the
type system shall have different types for polymorphic and specific values.
So you could declare Invert in either of four forms:

Invert : T -> T     (substitutes both)
Invert : class T -> T  (substitutes the result)
Invert : T -> class T  (substitutes the argument)
Invert : class T -> class T  (does not substitute)

> When C.Date talks about value substitutability he doesn't mean you can
> pick any function you like and substitute a sub-type in place of a
> super-type throughout the function.

Then it is worse, it is so that substitutability is not controlled by the
type. If so, then how it is any better than just let the programmer to do
what he wants?

> Doing so gives you a *distinct*
> function and the system is not allowed to guess that it is meaningful
> to do so.  If you wanted this to be valid, then it would greatly
> restrict possible sub-typing relationships and that limits code
> reuse.  In particular, it would no longer be possible to treat Z as a
> subtype of R.

(which is not, in LSP sense.)

> Probably some mathematicians would think that is
> sensible since the system Z doesn't inherit the axiom for existence of
> multiplicative inverses from R.  However, I prefer the idea that
> algorithms are parameterised explicitly where appropriate, and only
> let the system perform implicit type conversions on in/out parameters
> or assignments.

This is too restricting to me. I prefer to be able to design algorithms
without parametrization.

1. Why should I specify the parameters if the types are already known to
the system?

2. Static only parametrization makes impossible to design a huge range of
applications where types are known only to be constrained to certain class.
Even where applicable it becomes extremely weird. Look at STL. It is a
mess.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
2/15/2008 8:24:34 PM
On Feb 12, 6:49=A0pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-02-11 12:44:28 -0600, topmind <topm...@technologist.com> said:
>
> > A bigger issue is how to manage "variations on a theme". OOP tends to
> > use polymorphism and object pointers, while a data-centric approach
> > tends to use set theory and attributes (meta data). I much prefer the
> > second. I won't claim it objectively better, but to my mind it is a
> > lot nicer, more flexible, and easier to report/study/sift via query
> > and table browsers.
>
> I won't disagree with any of that. =A0I will say, however, that I can
> manage the dependencies between source code modules with OO,
> and I can't with data. =A0

The trick is to shift to a declarative interface/logic so that less
is
in app code. Change the problem instead of trying to solve the
wrong problem.

> There are other dependencies I can manage with data,
> that I can't with OO. =A0Both are useful. =A0Neither is better than the
> other. =A0They are orthogonal and complementary.

I disagree. They tend to fight over the same territory.

>
> --
> Robert C. Martin (Uncle Bob)=A0=A0| email: uncle...@objectmentor.com
> Object Mentor Inc.=A0 =A0 =A0 =A0 =A0 =A0=A0| blog:=A0=A0www.butunclebob.c=
om
> The Agile Transition Experts=A0=A0| web:=A0=A0=A0www.objectmentor.com
> 800-338-6716=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0|

-T-
0
topmind (2124)
2/16/2008 12:14:35 AM
Dmitry A. Kazakov wrote:
> mAsterdam wrote:
>> Dmitry A. Kazakov wrote:
>>> mAsterdam wrote:
>>>
>>> But you certainly should have a mental picture
>>> where "data" plays some role. 
>> Is it necessary for both sides of the border to fully understand the
>> formalisms en vogue at the other side? I don't think so.
>> Your position - I trust you'll correct me if I'm wrong -
>> is: there is no data, no other side, no border to cross.
> 
> Maybe what you are using "data" for, could be common.

That's nice. Let's see if we can get rid of the scarequotes.
Call it blurk for now.

>>>> ... Which primitive elements does your formal system have?
>>> Value, type, variable, operation.
>> That looks rich enough to get somewhere.
>>
>> Somewhat OT to this thread - just because I am curious:
>> do you have a reference to definitions/descriptions of how these act 
>> together you consider worthwhile?
> 
> Date's definitions were OK for values and types. 

> Any value has exactly one type. 
We know that doesn't work in practise, but that may be due to the poor 
type systems (or their implementations) in use. Maybe it works in 
theory and just not yet in practise - I really don't know.
Anyway, your statement does sort of draw type into the basics
of the common ground as well, no? For precision: I do not need to
accept "Any value has exactly one type." in order to accept blurk.

> Variables map the computational states onto values. I think it would
> be more or less acceptable for anybody. Much more difficult is to agree on
> subtype and class. Class is a set of types. Subtype is a type relation of
> some properties (transitive, reflexive etc), and so on.

I agree that that is more difficult. Let's not rush here.

>>>>> Bad. It means that you have to formalize "memorize" in some quite tricky
>>>>> way. Honestly I don't know what could be the difference between "memorized
>>>>> Pi", "not-yet-memorized Pi", "once-memorized-but-forgotten-by-now Pi" and
>>>>> so on.
>>>> Are you suggesting π is data?
>>> Yes. But you can take some P(pi)=true instead.
>> Or R(P(π)) - packaging a symbol/value doesn't make it data.
>> In order to be data it should convey a fact, relevant in a
>> sense outside the formal system, i.e. an observation, or the basis
>> for a decision.
> 
> Then I see no disagreement anymore. Is all that rant going on for years
> between c.d.t and c.o just about what to feed to the beast?

Heh. Could it be?

> [ BTW, it was exactly the point I made in my first post to this thread. It
> is not about theory it is about selling stuff = making sense outside the
> system = getting money out of customers. (:-)) ]

I see the smiley. :-|

>>>>>>> May I translate data into a different
>>>>>>> representation and then erase the original record? 
>>>>>>> Will data still be there?
>>>>>> Iff it conveys the same facts as the original record, sure.
>>>>> OK, that means that data = facts + record medium of:
>>>>>
>>>>> D = (F, R)
>>>> Guessing about your notation as D denotes Data, F denotes Facts, R is 
>>>> the requirement that the fact is recorded, R is just 1.
>>> (A side question, in "R is just 1", were "just 1" data or fact?)
>> It is the 'recorded' property of the fact.
>> As you deny the existence of facts and data
>> I don't see how this is relevant to you.
> 
> In order to be able say, that the property (or whatever) "is 1" has to be
> data (to be any "useful", using your terms). Thus it itself needs this
> property, which constitutes an infinite recursion.

If you are going to accept blurk, you need to get used
to the discipline of not accepting that something is
blurk just because there are some symbols. We need to establish
the common (/in/formal) understanding first.

A plot without an understood legend is a
meaningless drawing. With it, it is a depicted
chunk of blurk.

>>> And, equivalently, you cannot describe
>>> recording in terms of either data or facts.
>> Yep, that's the fate of primitives and semi-primitives.
> 
> In other words being recorded / data is incomputable.

Being recorded - maybe, but data - why not?

>>> But I see no disagreement in the core issue: 
>>> a formal system does not operate meanings.
>> I see no agreement to the core issue:
>> A formal system needs to support meaning to be useful.
> 
> "To support" needs to be defined. 

No, it merely needs to be understood. A definition is neither
a necessary nor a sufficient conditon for understanding.
It may sharpen it, and it may assist in formalizing the understanding.

> If you mere mean self-consistency or Turing-completeness, then it is OK. 

It is not what I meant.
In fact I wonder how you arrived to think that is what I meant.

> If you mean something finer than that, you have to say what. 

Nothing finer. Coarser if anything.
What is the raison d'être of the structure of a bridge?
That's easy: it supports the substance of the parts of the bridge
to interact such that the bridge can do what it is designed for: carry 
traffic without blocking what is underneath. Take away the purpose of 
the bridge, take away the substance, either way the structure is futile.

> Anyway it would be not "I want data, else there is no
> common ground." It would be about the structure of the formal system which
> you wished deploy for what you call data. (Maybe, I could to do it as well,
> but for something having a different name.)

If that what it takes to get rid of the scarequotes, I have no
problem with you calling it something else if there are enough
common associations and isomorphisms - and no blocks.
Do you have a name in mind? Blurk sucks.

>>> It is we who assign meanings to the inputs and outputs, and, at
>>> yet another level of understanding, judge about the formal system as a
>>> whole in terms of its usefulness, for example.
>> It is IPO vs. IDO (late 70's debate) all over:
>>
>> Input values - Process - Output values: It does not matter what the 
>> input means, as long as the output is correctly processed from the input.
>>
>> Input process - Data - Output process: The input process (datacapture) 
>> is to be constrained in order to prevent inconsistencies in the data. 
>> The output process (rendering) should be validated not to corrrupt 
>> meaning. "You have  01 vacation days left". Ouch - but just within the 
>> currently acceptable range.
> 
> In both cases you constrain a process. So if complementary of views was
> your point, I think it is invalid. 

1. This does not follow.
2. Complementary views - on what?

> Further if you want to deal with D in
> IDO, you need a language to describe D. 

Schema + external predicates come to mind.

> That is a formal system, a process.
> I.e. you cannot abstract D out of some processes, generating, carrying,
> understanding data.
> 
>>>>> Yes, we cannot reason about meaning while staying 
>>>>> within the same formal system.
>>>>> Because you seem to bind data with a meaning (as I do), that immediately
>>>>> kicks the notion of data out of the formal system. So data do not exist
>>>>> there. Which is all my point! No data, nothing to worry about.
>>>> And the result is a hermetic system as useful as solipsism.
>>>> Have some fun there! I'm out waiting until you are bored of it.
>>> OK, I am back on vacation. How are you going to formalize something which
>>> cannot be formalized? (:-))
>> Hey, I am not the one eager to formalize without
>> a proper, shared, informal understanding.
> 
> Neither I am. 

It sure looks that way, even in your post I am replying to now.

> But shared can be also a method of understanding. 
> You consider understanding as a premise (data (:-)). 
> Do it rather as process (behavior (:-)).


--
What you see depends on where you stand.
0
mAsterdam (155)
2/16/2008 12:44:13 AM
On Feb 15, 9:31 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
>
> > The problem arises when you have all of:
> > 1) mutability
> > 2) first-class variables
> > 3) subtyping
>
> > You can't pin the problem on any one of these; the problem
> > is in the combination.
>
> What was the problem again?

Object oriented programming languages.


Marshall
0
Marshall
2/16/2008 1:31:15 AM
Marshall wrote:

> On Feb 15, 9:31 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> 
>>>The problem arises when you have all of:
>>>1) mutability
>>>2) first-class variables
>>>3) subtyping
>>
>>>You can't pin the problem on any one of these; the problem
>>>is in the combination.
>>
>>What was the problem again?
> 
> Object oriented programming languages.
> 
> Marshall

Oh, so OOPL is problem space not solution space. I see.
0
Bob
2/16/2008 1:42:47 AM
On Feb 16, 5:24 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 15 Feb 2008 08:46:54 -0800 (PST), David BL wrote:
> > On Feb 15, 8:20 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Thu, 14 Feb 2008 20:27:52 -0800 (PST), in
>
> >>> Consider the function 1/x which is axiomatically defined on (nonzero)
> >>> reals but not the integers.  That suggests that Z is not a subtype of
> >>> R.  However consider
>
> >>>     float Invert(float x) { return 1/x; }
>
> >>> That doesn't stop us calling Invert(2) even though 2 is only an
> >>> integer.  We still get a float result!
>
> >> I think there is a confusion here. Note that invert as an operation deals
> >> with a tuple float x float:
>
> >>    Invert : float -> float
>
> >> Now, the question is where are you going to substitute ints?
>
> >> 1. In the first appearance of float
> >> 2. In the second one (result)
> >> 3. In both
>
> >> Depending on that Invert will become inheritable or not. I.e
> >> substitutability is not only parameter mode depending, it also depends on
> >> the concrete parameters too. (For the sake of genericity, results are
> >> parameters.)
>
> > I'm aware of the three conceivable options, but I'm quite clear in my
> > mind that the system should only support the narrowing of in-
> > parameters and widening of out-parameters.
>
> It is an arbitrary constraint, worse is that it kills any algebraic
> operations.

I imagine any notion of sub-typing could be called arbitrary because
the fact is that there is no single definition that will keep everyone
happy.

I hope you are remembering in this discussion that I expect an OO
language to support at least two distinct notions of subtype.   One
centres on substitutability of values and the other on
substitutability of objects.  I'm reticent to say variable instead of
object because some people assume (by definition) variable represents
a value.

I'm assuming here we are only discussing value-types.  Agreed?

> >Therefore, as Invert() has
> > been written (1) is the only option.
>
> As a counterexample, consider C (complex) instead of Z.

Please provide more details.  Are you alluding to covariant return
types?  ie

Complex Invert(Complex x);
Real Invert(Real x);

I don't see how this presents a problem.


> > If you want option (3) then you
> > need to explicitly write a parameterised function.  Eg
>
> >     template <class T> T Invert(T x) { return 1/x; }
>
> > However it seems inappropriate to allow Invert<int>().
>
> From the language design point of view there is no any problem because the
> type system shall have different types for polymorphic and specific values.

Sorry, I can't understand "different types for polymorphic and
specific values".

> So you could declare Invert in either of four forms:
>
> Invert : T -> T     (substitutes both)
> Invert : class T -> T  (substitutes the result)
> Invert : T -> class T  (substitutes the argument)
> Invert : class T -> class T  (does not substitute)


> > When C.Date talks about value substitutability he doesn't mean you can
> > pick any function you like and substitute a sub-type in place of a
> > super-type throughout the function.
>
> Then it is worse, it is so that substitutability is not controlled by the
> type. If so, then how it is any better than just let the programmer to do
> what he wants?

I don't understand what the problem is.  Please provide an example.


> > Doing so gives you a *distinct*
> > function and the system is not allowed to guess that it is meaningful
> > to do so.  If you wanted this to be valid, then it would greatly
> > restrict possible sub-typing relationships and that limits code
> > reuse.  In particular, it would no longer be possible to treat Z as a
> > subtype of R.
>
> (which is not, in LSP sense.)

I think there is a misunderstanding here.  In this discussion I'm only
talking about value-types.  In an OO application I would imagine that
many if not most types are *not* value-types and indeed go by LSP for
sub-typing.   Note that I assume LSP is (only) about substitutability
of objects (or if you like, variables that have state but don't
necessarily represent a value).

The types we are discussing here - ints, floats, circles, ellipses are
all value-types.  I don't see any sense in demanding LSP sub-typing
amongst value-types.   Variables for these types do nothing but hold a
value, and don't exhibit behaviour in the sense that is relevant to
LSP.

In fact imposing LSP sub-typing amongst value-types means there cannot
be any non-trivial sub-typing amongst value-types at all.

Here is a proof by contradiction:  Suppose S,T are value-types and
values(S) is a strict subset of values(T).   Now also suppose S is a
LSP-sub-type of T.  In other words, a pointer to a variable of type S
can be implicit cast to a pointer to a variable of type T.

    void foo(T* x)
    {
        // By definition, value-types always support assignment
        // on variables
        *x = <some value in  values(T)\values(S)>;
    }

    S s;
    foo(&s);	// oops