The LA Fox Developer Newsletter

March 1994

XPro User Group News (con’t from Page 1)

THE OLD “WHICH IS BETTER” QUESTION,

AGAIN

Fm:

DBADVISO REP 143331

To:

Alan Woodall 761 16,1163

Alan,

>>Can anyone tell me which would be better for

me to learn. I know Clipper S’87 and was wonder-

ing which way to go.

The learning curve from S’87 to either 5.x or

FoxPro 2.x is about the same. 5.x will run S’87

code but it’s pretty much a waste to do that and

lose the advantages of 5.x style coding. FoxPro

handles almost all S’87 functions (except

memoedit and dbedit) but that’s a waste to not do

it the FoxPro way and use the Power Tools

(screen designer, menu designer and project

manager) and higher level constructs. Once that’s

out of the way, the advantages of basic FoxPro

over basic

Clipper are pretty substantial. Built in productitivity

tools, mouse support, very fast performance and

cross platform capabilities just about sums up the

advantages. There are many fine third party tools

for Clipper that will add much of these advantages

to Clipper but nothing addresses all of them.

XBASE COMMITTEE DISCUSSIONS

Sb:

Undefined Type

Fm:

DBADVISO REP 143368

To:

Joseph M. Perret 71 052,2625

Joe,

The resolution was not unanimous, but I’m not

surprised that the minutes of earlier meetings may

not be entirely accurate. I and several others,

voted against the “proper subset” language at the

JPL meeting. It was apparent to me then that it

would not facilitate standardizing existing Xbase. It

would, in effect, be designing by committee (I

specifically remember the JPL rep and Borland

voting for and MSFT against). I argued the point

but apparently did not communicate the conse-

quences too well.

I have argued, since the first “pre” meeting in Pal

Desert that it would be necessary to codify

“defacto” (existing) Xbase first for the sake of

legitimacy. I suggested a “simultaneous 2 track”

method in order to have another level for “future”

Xbase. My only lack of precognizance was the lack of

support, or the level of work required, for producing an

actual standards document. This, of course, made the

“future” track just that - a future track.

Events have simply moved in the direction they were

going to go anyways.

Sb: Xbase Standard

Fm: DBADVISO REP 143412

To:

Scott Van de Workeen 71641,2117

Scott,

...I keep hearing an underlying movement to en-

force type casting of variables.

Actually, no. You weren’t around for the earlier discus-

sion of the subject but the basic concensus is that it

would be great to have strong typing _as_an_option_.

Neat trick if you can mix and match strong and weak

typing without some pretty silly results for real life

application life cycles (which includes long term main-

tenance). The leading contender for mixing strong and

weak typing is something like:

Xas INT

allowed along with weak typing:

Y=3

Which will look pretty strange to a junior programmer

taking over an application were the developer has

been gone for a year.

“Now, let’s see. The compiler says my changing Y to

a true was O.K. but X can’t be false because its an

interger. Therefore, Y must be a logical everywhere in

the existing code.”

Uh huh. Sure. You go on down there, General

Custer. <g>

Sb: Xbase Standard

Fm: DBADVISO REP 143563

To: David Veale (Borland) 73423,3153

David,

Compliance with existing code has always been the #1

point of consideration for me. Since becoming an MIS

manager (responsible for a couple of dozen different

systems where the original developers are long gone)

it has become even more obvious that this committee,

as the Hippocratic oath says, must do no harm.

It’s very interesting watching how my changing respon-

Page 5