Ryan,

Visaul DBASE 7.1 appears to have alot of what your suggesting.
Take a look at the product info at www.inprise.com (formerly borland.com)

They have a classes for:
database
query
datetime
numeric
text
report writer
menus
grids
etc...

The text class, for example, contains methods for accomplishing what most
of the old character string functions could do, such as substr(), at(), etc.

-Marty Kay-



>>>Hey Menachem,
>>>
>>>I think what we need is a database object. An object that has an events like OpenDataBase, CloseDataBase, OpenTable, CloseTable, RecordPointerChanged and so on. With a DB object there are a number of requested features that could be incorporated by a developer like security and data encryption.
>>>
>>>Just my $0.02!
>>
>>I'll buy that for a dollar. All I want is the ability to control out of app access to my data.
>
>I agree with you both wholeheartedly, and have some more objects I'd like to see. The following is a suggestion I sent to the VFP development team recently. I'd like your input as to whether this is possible, or even desirable. Admittedly, I know nothing about the internals of building a language or compiler. See what you think:
>
>I think a good way to draw new developers to VFP while maintaining
>backward compatibility would be to reduce the reliance on XBASE style
>code. Even though VFP is OOP, much of the code inside an object can still be XBASE in origin. You can still retain this for compatibility, but
>there should be an option in building a project (and coding) to disable
>backwards compatibility and XBASE style code. The debugger could
>enforce more object-like syntax. While things like set statements,
>sys commands, VFP's native sql and array commands are powerful, the syntax is not very easy to get used to, especially because the syntax can't be drilled
>down on using things like Intellisense. You could refine VFP's object model to have something like the
>following:
>
>_vfp.application.arrays.***
>where off the arrays object would be remove, insert, copy, dimension and
>other array functions
>
>_vfp.application.errors.***
>
>_vfp.application.filefunctions (for low-level file I/O)
>
>_vfp.application.variable (for variable manipulation and operations)
>
>_vfp.application.datatypes.characterfunctions
> .dataconversion
> .datefunctions
> .numericfunctions
>
>_vfp.application.databasefunctions (or you could provide direct
>access to ADO here, where all child objects are really ADO objects) Better yet, model VFP's own internal data object after ADO, with additional properties and methods for those really cool VFP functions that ADO does not have.
>
>_vfp.application.systemvariables
>
>You get the idea. You could redesign the object model to fit this
>structure, and internally map old XBASE style code into these objects,
>so that backwards compatibility is maintained (For the time being
>anyway. Eventually with the new syntax, you could build a conversion
>tool that would automatically change the XBASE code to object-based
>code, while developers would be getting used to the new objects. Over
>time, you could drop support for XBASE code which would reduce runtime
>file size.)
>
>If you had separate objects that could be drilled down (with
>Intellisense) for each of the 'language categories' that you define in
>the online documentation, you would have a mechanism for a reduced
>learning curve. You could also say that you have a more object-based
>method for programming than current XBASE commands. VFP would attract
>lots of attention then! I really like VFP, but this would help the
>product further evolve.