Re: OOP - a question about database access

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:e4330f45.0311060351.fe6db7a_at_posting.google.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:<j9GdnUPiP5y_LzSiRVn-sg_at_golden.net>...
>
> >> I was asking for an example of application that does not present,
> >> communicate or acquire data.
>
> >Any triggered procedure. Month end. End of quarter. Year-end.
>
> But IMO it would be better to extend the DBMS operators set instead of
> creating a new application for calculating the Month end.

Extensions are applications.

> > I doubt Dijkstra would consider a division between applications and data
> > management appropriate.
>
> IMO it is not a division between applications and data management, but
> data should be managed by specialized systems called DBMS.

The above sentence is self-contradictory.

> In the OO jargon, a DBMS is a very good example of reusable component.

Indeed.

> > > Other datawarehouses hold the combined data of several "operational"
> > > databases.
> >
> > Other views.
>
> Then we could consider any enterprise database as a view of the world
> wide database :)

We could, but the security function would have a lot of work to do.

> > > Because all the application development tools I know have a primitive
> > > computational model.
> >
> > I suggest you need to know a better vision of the future.
>
> I think that the future is for D like languages, but probably it will
> be in a distant future.
>
> But I was talking about the present.

I disagree. If you were talking about how to write any application not yet written, you were talking about the future. In the present, all decisions have been made. Any decision not yet made affects the future.

> > > > That will largely depend on what is available for declaration.
> > >
> > > But it never will be enough.
> >
> > Why?
>
> Because users always will find something you can not declare in your
> system.
>
> You will always need the possibility of creating new operators using
> procedural code.

I find it useful to challenge the above assumption/axiom. How do you intend to prove the assertion?

> > > Although the forms designed by draging and dropping can be easily
> > > translated to declarative propositions.
> >
> > Doesn't this contradict the former statement?
>
> No because you can not create any user interface only dragging and
> dropping controls, you also could need to implement some presentation
> rules with procedural code.

Why procedural? Received on Thu Nov 06 2003 - 15:20:27 CET