Re: Mixing OO and DB
Date: Wed, 13 Feb 2008 11:45:48 GMT
Message-ID: <MLAsj.11019$R64.10830_at_trndny03>
"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
news:47b24622$0$85781$e4fe514c_at_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:
- You can store data.
- You can convey data.
- 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. Received on Wed Feb 13 2008 - 12:45:48 CET