The LA Fox Developer Newsletter

March 1994

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

THE OLD “WHICH IS BETTER” QUESTION,

AGAIN

Alan,

>>Can anyone tell me which would be better for me to learn. I know Clipper S’87 and was wondering 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

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

Scott,

...I keep hearing an underlying movement to enforce type casting of variables.

Actually, no. You weren’t around for the earlier discussion 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 maintenance). 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