[Harbour-users] ORMs (from "thread" GUI programming)

[dougf at people.net.au]

 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