Re: Annual Oracle World Database Survey

Daniel Morgan <damorgan_at_exxesolutions.com> wrote

> Methinks you misunderstood my point. It was not that the programmer
> needs to learn more languages ... but rather the compilers. That way
> programmers would need to learn fewer. For example Oracle's compiler can
> handle
>
> SELECT 'A' || 'B' FROM dual;
> it can also handle
> SELECT CONCAT(''A','B') FROM dual;
>
> So why shouldn't be equally able to handle:
>
> END IF and ENDIF and FI? Why not IF }?
>
> From a technical standpoint, I don't think there is one.

Correct. A parser is a parser is a parser. I drove a C++ lecturer almost insane many years ago at an "Advanced" Microsoft Visual C++ course by changing C++ into a Delphi-like looking language through the abuse of macro's and #defines. :-)

However, there's more to it like that. It also depends on the language features and implementations.

For example, the ability to define properties and getters and setters. The ability to declare methods and properties as private, protected and public. It also depends on the class definitions and hierachies that are available by default. Etc. These can differ a lot from language to language.

What I really would like to see in UDT's is something like this:

create or replace TEmployee as Object
(

   private,

      id_       number(8),
      name_     varchar2(30),
      surname_  varchar2(100),
      dept_     number,

      member function Age : number,
      member procedure ChangeDept( dept$ number ),

   public,
      constructor Create( id$ number ),
      constructor Create( name$ varchar2, surname varchar2),
      property  ID      number     read id_,      
      property  Name    varchar2   read name_     write name_,
      property  Surname varchar2   read surname_  write surname_,
      property  Age     number     read Age,      
      property  Dept    number     read dept_     write ChangeDept,

      member procedure Fire,
      member procedure OnLeave( fromdate$ date, todate$ date)

In PL/SQL:
declare
  emp$ TEmployee;
begin

   emp$ := TEmployee.Create(101);
   emp$.Dept := 10;
   dbms_output.put_line( emp$.Age );
   emp$.OnLeave( sysdate, sysdate+5);
end;

And this is just scratching the surface of Delphi's OO Pascal implementation. :-)

BTW, the variable + underscore is something that many use in Delphi to indicate a private class variable (however, we prefix the variable name with an underscore but this is not valid in PL/SQL).   

What I do *not* want to see is the asine C/C++ implementations of token parsing and the like that is globalised and very unsafe to use. (there's nothing like that in Pascal)

The reason Delphi is so popular among Delphi developers is not because it is language loyalty or brand loyalty (hello VB developers!) or fanaticism (hello Java developers!). It is because of two things. The best IDE on the planet. A language and OO implementation that is easy and make sense.

Given Oracle's history of crap front-end tools (of which OEM is an extention), I have little hope of the former from Oracle. But the latter - an OO implementation that is easy, sensible, flexibile and all that... there's a *lot* that Oracle can learn from Delphi.

Microsoft proved that. They made the Delphi project manager an offer he could not refuse and had him design C#. Which is just a rippoff of Delphi - nothing more.

--
Billy