Hi all Its nice to see that a discussion that started out with some highly questionable assertions about OOP has turned right around to a discussion of ORMs which essentially extend the OOP concept.
Harbour doesn't force OOP on anyone, but I suspect most savvy xBase coders head that way. Even those that write procedural code are using some objects, hidden from them by the preprocessor. Beginners soon realise that they are writing code that pretty much does something similar to what they have done before. At first they may use the "cut and paste" approach. Most then come to realise that this approach is not ideal because 1. Its easy to miss bits of code that need to be altered 2. To change "standard behaviour" you have to change code in many places So most of us ended up with a whole series of "utility functions" which identified (as parameters) those things that changed from invocation to invocation and meant that standard behaviour could be changed by altering a single piece of code. OOP basically extends this in a more powerful and consistent way. But if you don't like writing "standard" Harbour OOP code that might look like obj_MyWindow := TWindow():New( 500, 300, "Sample Window" ) you can use the preprocessor and write something like CREATE WINDOW myWindow TITLE "Sample Window" SIZE 500, 300 all it takes is a preprocessor directive like #xcommand CREATE WINDOW TITLE SIZE , => ; := TWindow():New( , , ) That is one of the fundamental beauties of xBase. I would also note that the popularity of VB is due to Microsoft's marketing power and the fact that many of us are effectively forced to use it (or its sibling VBA) to automate office type tasks. If you judged languages by their popularity you wouldn't be using Harbour despite the fact that its so wonderful a language. Now onto the interesting part - ORMs. These should fit very neatly into Harbour. Take an "example" from a previous post: emp=Employee.new emp.name = "Emp1" emp.basic = 4500 emp.designation = "Programmer" emp.save Harbour equivalents are easy: obj_Employee := TEmployee():New() WITH OBJECT obj_Employee :Name := "Emp1" :Basic := 4500 :Designation := "Programmer" :Save() END Of course there are many alternatives (depending in part on the TEmployee class) such as obj_Employee := TEmployeeNew( "Emp1", 4500, "Programmer" ) obj_Employee:Save() Or with suitable preprocessor directive for those that like the object orientation hidden CREATE EMPLOYEE ThisEmployee ThisEmployee:Name := "Emp1" ThisEmployee:Basic := 4500 ThisEmployee:Designation := Programmer SAVE EMPLOYEE ThisEmployee Obviously we have to define the TEmployee Class which would inherit from a class that "understands" how to read / write etc but not the particular details of an employee record, something like: CLASS TEmployee FROM TSingleRecord DATA Name DATA Basic DATA Designation // etc ENDCLASS Methods like Save() would be inherited from TSingleRecord as might its oid (object identifier / primary key ) CLASS TSingleRecord DATA oid // etc METHOD Save() // etc ENDCLASS This is very much along the lines of the approach I use combined with a client-server data base back end I wrote for my own use. A record is returned as a two-dimensional array that can be used to directly update the front end object. The array is serialsed and transmitted using IP sockets. Properties are directly updated using __ObjSetValueList(). This type of approach would seem ideal for an ORM in my opinion. Regards xProgrammer _______________________________________________ Harbour-users mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour-users
