Re: OOP - a question about database access

"Bob Badour" <bbadour_at_golden.net> wrote in message news:<AIydnVJ60ZqyxDei4p2dnA_at_golden.net>...

> > >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.

Are user defined operators applications??

Are builtin operators like join, union, etc also applications?

I looked into the dictionaries and I have found several definitions saying that any instruction sequence is an application, but I don't think that it is the common use of the term.

I prefer this definition:

application program

<programming, operating system> (Or "application", "app") A complete, self-contained program that performs a specific function directly for the user. This is in contrast to system software such as the operating system kernel, server processes and libraries which exists to support application programs.

www.dictionary.com

According to this, MonthEnd() is not an application.

> > > 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.

What I mean is that the division is between presentation/communication and data managment.

I doubt that Dijkstra would be against this division.

> > 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.

I was talking about how to write any application the past week, and I was talking about the past :-)

With all due respect, you are a bit too persnickety with the terms :)

When I talked about the present, I meant that morning, or that day or so, and not that infinitesimal instant :)

Five minutes ago, D languages were not a widespreaded reality either.

> > 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?

Users prove that all the time. They are always able to invent weird presentation rules that no developer could imagine :)

I don't remember the page, but TTM says that in practice you can not build a declarative system that is able to express everything.

You could extend the system always you find something you can not declare, or you could use the procedural constructions of the language.

> > 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?

Speaking loosely, because declarative works when you say the "what" and the system knows the "how", but when the system does not know the "how" you must show it, and this is procedural programming.

Regards
  Alfredo Received on Mon Nov 10 2003 - 13:45:20 CET