Re: Early and late binding.

dawn wrote:
> x wrote:
>

>>David Cressey wrote:
>>
>>>The discussion about dynamic typing and the discussion about Dawn's new
>>>blog both put me in mind of an old topic:
>>>  early and late binding.
>>>I searched the web, and got a lot of articles on this subject.  All the
>>>ones I've read so far deal with two specific 
>>>instances of early and late binding.
>>
>>>One is about the early or late binding of variables to types,  the statis
>>>and dynamic binding topic.  The other is about early or late binding of
>>>operators to class specific methods in an object oriented environment.
>>
>>>It's possible that there's a more abstract treatment of early and late
>>>binding than the ones I've managed to locate so far.
>>
>>Values and operators can also be typed.
>>
>>With a SQL DBMSs one is forced to separate DDL from DML 
>>which may or may not be a good thing.

In prolog there is no difference. That is the other extreme.

What is data and what is process depends on what we are talking about. Let's take a possibly difficult example. In a process-modeling team/tool we need some data to represent the process model (say process 'A').

Now does that process-representing data of A lose it's data-ness and become processoid spontaneously? Of course not. In the process of process-modeling it's just data. Now what about the data which is supposed to be processed by A? Well, it is data, but not real data; it does not represent facts. It is prototype data to be evaluated by domain experts, to validate the process model. It represents could-be facts. When we go from model to system, we take JUST the structure of the data, and populate that structure with real data.

I've seen data taken from a model used for populating a part of the real system. To me that is not real data. The user doesn't maintain it, the developer does. It represents developer domain facts, not user domain facts.

> I wasn't fond of JavaScript when I started working with it, but it is
> growing on me, in part because data and process are intertwined. Every
> object is an associative array. Members of the array can be functions
> along with any other type.
>
> I would say that the separataion of DDL and DML is not a positive
> aspect of SQL DBMS's. --dawn

In SQL itself you can can mix DDL and DML, if you so decide. Some applications do. The times I saw that mix used I did not like it, and could trace it down to poor design. Maybe this is necessarily so, maybe not. Thoughts? Received on Sat Jan 21 2006 - 06:20:38 CST