Re: Mixing OO and DB

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.

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.

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.

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

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.

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.

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.

Your trackrecord on stating others peoples opinion suggests I wait for Patrick to join in.

--
What you see depends on where you stand.