This sounds like a great idea to me.. I'm all for supporting it. The
only drawback I could think of is that you might end up with lots of
code that's no longer transferable to someone who doesn't have the
++precompiler installed, but I'd see that as not a big deal as a
tradeoff for us to have control of helping to evolve the syntax of
the language. There's lots of conventions from C/C++ that I'd love to
use in VFP.
-Steve
At 10:31 AM 10/27/2006, you wrote:
Tristian,
> I'm intrigued what is this VFP++ you are speaking about?
I noticed Bill Sander's posted a link to this thread which I encourage
you to read, but here's a quick summary to get you started:
VFP++ is a proposal to extend the VFP language by intercepting the raw
source being sent to the VFP preprocessor/compiler and pre-preprocessing
the source before VFP attempts to compile it. The original source would
not be changed - only the source that VFP compiler sees.
*IF* we had the ability to hook source code and pre-process it ourselves
(using VFP code) then we could extend the VFP langauge indefinitely. For
starters, imagine:
* declare and assign in a single statement
local lnVariable = value
* support enumerated constants
enum Colors
Red
Green
Blue
end enum
* initialize single column arrays
laArray[] = 2, 3, 5, "cat", .T.
The above examples are simple transformations that could be done to
convert an extended VFP syntax (VFP++) to regular VFP code that the VFP
compiler would compile. There are many more syntax enhancements that
could be made to add .NET and open source language innovations to the
VFP language.
If you're still with me ... yes, you could do this with project hooks.
*BUT* this would prevent you from using VFP++ syntax in any of the VFP
designers which automatically compile source code as soon as you leave a
snippet editor (there is no way to turn this auto-compilation off). And
it would force you to (re)build a project every time you wanted to run a
regular PRG file with VFP++ syntax ... a pain-in-the-ass.
*IF* we could hook the compilation process (_PREPROCESSOR = vfpplus.app)
then we could seamlessly use VFP++ syntax in the designers, PRG files
and even in the command window.
VFP has a rich history of allowing itself to be extended by VFP source
code. THE LAST REMAINING OPPORTUNITY FOR EXTENSIBILITY is a hook into
the compilation stream.
If any of you are interested in this concept, then let's start to talk
it up on this list!
Malcolm
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
