Re: OOP - a question about database access

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:e4330f45.0311100445.3e9c1f77_at_posting.google.com...
> "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??

Yes.

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

They are part of an application.

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

When one extends the dbms, does one not apply the dbms to a particular use?

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

MonthEnd() is a self-contained program that performs a specific function directly for the user. How is it 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.

Other than spelling out some of the applications, how does that not contradict your earlier statement?

> I doubt that Dijkstra would be against this division.

That would depend on what you mean by division. He certainly encouraged the use of one theory or lemma to simplify another. However, I doubt he would place any limitation on where one can use a particular theorem.

> > > 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 :)

Anecdotal evidence does not convince me--especially without any details of the anecdote!

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

Is the lambda calculus declarative?

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

I remain unconvinced by your assertions.

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

Why do you assume the system does not know the how and cannot determine the how from the what? Received on Mon Nov 10 2003 - 15:00:41 CET