Overview of OOP

Overview of Object-Orientation

“After years of relative obscurity, object orientation appears to be entering the mainstream of commercial computing for both software developers and end users. A shift to object orientation is occurring simultaneously across a wide range of software components, including languages, user interfaces, databases, and operating systems. While object-oriented programming is no panacea, it has already demonstrated that it can help manage the growing complexity and increasing costs of software development”.


                – from Object-Oriented Software by

                               Winblad, Edwards & King

This quotation is an excellent summary of what is happening in the world of computing today. Although exciting research and development is taking place on many fronts, no single software topic currently enjoys as wide a scope or impact as object orientation. Some of the most advanced and powerful software products available today incorporate object orientation as a central concept: languages such as Smalltalk, C++, and Actor; leading edge minicomputer databases such as Ontos and Servio Logic’s Gemstone; expert system development tools such as Neuron Data’s Nexpert Object and Level 5 Object from Information Builders; and graphical user interfaces (GUIs) such as Microsoft Windows, as well as UNIX GUIs such as Open Software Foundation’s Motif, and Sun Microsystems’ Open Look.

Although object orientation applies in slightly different ways in each of the areas mentioned above, the same basic concepts are being applied in each case. Because of its broad scope, the term is often misused, especially in marketing claims; indeed, articles have been written on this subject, such as “My Cat is Object-Oriented”, by Roger King of the University of Colorado.

This abuse often arises from the fact that object orientation in user interfaces is not easy to define clearly, and it is through user interfaces that end users encounter object orientation, usually without realizing it. Some vendors assert that their products are object-oriented merely because they use screen windows – the windows are objects, the argument goes, and therefore the program is object-oriented.

This is perhaps an extreme of misrepresentation, but the situation is complicated by in-between products such as Microsoft Windows. At both the user interface and programming level, Windows is object-oriented in many ways, but in other ways falls far short of being “fully” object-oriented.

The aspect of object orientation which Class(y) addresses is that of object-oriented languages. The features required of an object-oriented language are well defined, and existing language products set something of a standard in this area. Once familiar with the principles of object-oriented languages, it becomes much easier to differentiate between true and false claims about object orientation in other areas.

One of the main driving forces for the adoption of OOP is likely to be the need to produce programs that run under graphical user interfaces such as Microsoft Windows. This means that changing from procedural to object-oriented programming may involve changing not just the language being used, but the operating environment, resulting in an extremely steep learning curve.

While GUIs promise to make life easier for the end user, they will only make it harder for the programmer, unless we are prepared to change our programming style. Writing programs with a completely object-oriented architecture simplifies development for GUIs, since the program architecture reflects the architecture of the underlying environment.

Although we cannot write Microsoft Windows applications using standard Clipper just yet, we can prepare ourselves by starting to develop object-oriented programs. This will allow us to climb the learning curve gradually, rather than suddenly being forced to learn a new programming style as well as the complexities of event driven programming in a GUI.

We’ll start our climb of the learning curve with a brief look at the history of object-oriented languages, followed by an introduction to object-oriented concepts.

Brief History of Object-Oriented Languages

The concept of an object class and inheritance, central to object-oriented languages, was first implemented in the language Simula 67, an extension of Algol 60 designed in 1967 by Ole-Johan Dahl and Kristen Nygaard from the University of Oslo and the Norwegian Computing Center (Norsk Regnesentral). Although Simula, as it is now called, is a general purpose programming language, it is not in wide usage.

A major milestone in the development of object-oriented languages was the Smalltalk research project at the Xerox Corporation’s Palo Alto Research Centre (PARC). Starting in the early 1970s, the Smalltalk project, initiated by Alan Kay, had as its goals more than just the development of a programming language; rather, a complete integrated environment was the goal, including an object-oriented language, development tools, and a graphical interface. The standard components of modern graphical user interfaces, such as windows, icons, and the mouse, were pioneered at Xerox PARC.

The Smalltalk language itself was the first ‘true’ object-oriented language in that it dealt exclusively with objects. All subsequent object-oriented languages have been based on the concepts used in Smalltalk. Smalltalk was important, not just for its language, but for the development tools available in the Smalltalk environment. These include class browsers and object inspectors. A class browser is a very powerful tool which allows program code to be edited in a much more convenient and structured way than with conventional editors. Because of the inherently well-defined structure of object-oriented programs, the class browser is capable of displaying a given program’s class hierarchy in graphical form, allowing the user to ‘point and shoot’ to select a particular method (procedure) to be edited. Many programming tasks become menu driven, such as the creation of new classes, modifying the structure of the inheritance tree, and modifying the structure of a class. These operations are more complex and tedious when performed in a traditional editing environment.

Tools such as these are an integral part of the promise of object-oriented technology. They can simplify a programmer’s life, reducing development time and costs. Although they are a rarity in the DOS world at present, as the move toward object-oriented technology grows, and as we move towards GUIs like Microsoft Windows, these tools will become more commonplace.

What is an Object?

One of the fundamental reasons that object orientation is enjoying such success as a programming paradigm is very simple: the real world is made up of objects. An invoice is an object. A stock item is an object. A balance sheet is an object. An entire company is an object. Objects can contain other objects (this is called composition); and in this way complete systems can be constructed using objects.

But what is an object from a programming point of view? Simply put, it is a collection of related data, which is associated with the procedures which can operate on that data.

By this definition, most well-structured programs could be said to contain objects. This is another contributing factor to the confusion surrounding the definition of object orientation.

It is in fact possible to write programs in an object-oriented way in many traditional procedure-oriented languages. However, without the support provided by an object orientated languages, many compromises have to be made.

An object-oriented language formalizes the relationship of the data within an object to the program code which can operate on that data, by requiring that the compiler or interpreter be informed which procedures are allowed to operate on an object’s data.

Before we can clarify our definition of an object further, we need to explore a few other concepts.

Classes, Instances and Instance Variables

In any given system, many objects will exist. Many of these objects will be very similar to each other: for example, you might have thousands of invoice objects stored on disk. Although each one is different, they all share a common set of attributes. The same operations are valid on all of them. There is a term to describe such a collection of similar objects: it is called a class.

A class can be thought of as a template, or specification, for creating an object. The class itself consists of details specifying what the structure of its objects should be. The class can also be said to ‘contain’ the program procedures which are permitted to operate on objects of that class.

For example, an Invoice class would contain procedures for printing and updating invoices. It would also contain details of the structure of an invoice object, for example that each invoice object must contain variables named date, customer, amount, etc.

To look at it another way, we can define an object as an instance of a class. A given class may have many instances of itself (objects) in existence at any one time. Each of these instances has a structure determined by the class to which it belongs, but they are distinguished from each other by the data within that structure, which is stored in instance variables. The term instance variable distinguishes a variable that belongs to an object class from the ordinary stand-alone variables that we are used to. Instance variables are contained within objects, and are not directly accessible outside of those objects, although they can be accessed by sending messages to their objects.

Messages and Methods

Earlier, an object was defined as a module containing both procedures and data. An object’s procedures are known as methods. This terminology helps to distinguish them from procedures which are not associated with an object, since there are fundamental differences. In a fully object-oriented system such as Smalltalk, there are no procedures, only methods. In a hybrid system such as C++, or Clipper with Class(y), both methods and procedures can coexist.

Methods are not called in the same way that procedures are. Rather, messages are sent to objects, which respond by executing the appropriate method. All valid operations on or using the data in an object are defined by its methods, so all operations on an object are accomplished by sending messages to the object. Because of this, it is not necessary for other objects to access, or even know about, the internals of foreign objects. Objects behave like black boxes: send them a message, and they respond by executing the appropriate method. Send the print message to an invoice object, and it will respond by printing itself. This black box approach is known generally as encapsulation, and while it is possible to achieve in procedural systems, object-oriented systems actively encourage, support and enforce it.

Inheritance – Superclasses and Subclasses

Common properties among groups of classes can often be combined to form a parent class, or superclass. For example, it might make sense for a Quotation class, an Order class, and an Invoice class to all share the same superclass, a Sales Document class. The Quotation, Order, and Invoice classes are thus subclasses of the Sales Document class. This is known as inheritance. The subclasses inherit all the properties of their superclass, and may add unique, individual properties of their own. This concept can be extended further, with subclasses of subclasses. Such class hierarchies are a common feature of object-oriented systems.

Inheritance is one of the most powerful features of object-oriented programming, since it allows reuse of existing code in new situations without modification. When a subclass is derived from a superclass, only the differences in behavior need to be programmed into the subclass. The superclass remains intact and will usually continue to be used as is in other parts of the system, while other subclasses are using it in different ways.


The term polymorphism in this context refers to the fact that the same message, such as print, can result in different behaviors when sent to different objects. Sending the print message to a graph object has a different effect than it would on a balance sheet object. With a traditional procedural approach, the programmer is forced to differentiate procedure names, using names like PrnBalSheet and PrintGraph. In an object-oriented language, this differentiation is unnecessary, and in fact unwise.

Polymorphism has benefits for the programmer in that the same name can be used for conceptually similar operations in different classes, but its implications go deeper than that. It means that a message can be sent to an object whose class is not known. In a procedural system, given a variable of unknown type, a CASE statement would typically be required to test the type of the variable and pass it to the correct procedure for the desired operation. In an object-oriented system, a message is sent to the object with no testing, and the object responds accordingly.

This has important implications for inheritance, since it means that methods belonging to classes near the root of the inheritance tree do not need to know details of the subclasses which may be inherited from them. By sending messages with standardized names to the objects with which it deals, generic methods can be written which can later be used with any class which supports the required messages.

Anton van Straaten


 This article borrowed from manual of famous Clipper 3tdh party Library : CLASS(Y)


What is Harbour ?

Harbour is a modern computer programming language. It is a Clipper-compatible compiler which is cross-platform, running on many operating systems (DOSMicrosoft WindowsLinuxUnix variants, several BSD descendants, Mac OS XMINIX 3Windows CEPocket PCSymbianiPhoneQNXVxWorksOS/2/eComStationBeOS/HaikuAIX) using the same source code and databases.

Although it is a powerful general-purpose programming language, it was primarily used to create database/business programs. Harbour have been actively maintained looking for diversity keeping backward-compatible with Clipper style. It has undergone many changes and revisions and regain widely popularity amongst programmers in 1980s and 1990s

The open source Harbour license is similar to the GNU General Public License, with an exception supporting proprietary applications, so proprietary applications can be produced with Harbour and distributed..

Paradigm(s) multi-paradigmimperativefunctional,object-orientedreflective
Appeared in 1999
Designed by Antonio Linares
Developer Viktor Szakáts and community
Stable release 3.0.0 (17 July 2011)
Preview release 3.1.x available from SVN
Typing discipline optionally duckdynamicsafe, partially strong
Dialects Clipper, Xbase ++, Flagship, FoxPro, xHarbour
Influenced by dBase, Clipper
Influenced xHarbour
OS Cross-platform
License Open source GPL Compatible
Usual filename extensions .prg, .ch, .hbs, .dbf
Website http://www.harbour-project.org/


The idea of a free software Clipper compiler has been floating around for a long time and the subject has often cropped up in discussion on comp.lang.clipper. Antonio Linares founded the Harbour project and the implementation was started.

Sailing the Clipper ship to a Harbour port. Clipper is a type of ship. Harbour is a synonym to port (where ship docks) Harbour is out port to the Clipper language.

On 2009 Harbour had a huge make over on its design promoted mainly by Viktor Szakáts and Przemyslaw Czerpak

 Database support

Harbour extends the Clipper Replaceable Database Drivers (RDD) approach. It offers multiple RDDs such as DBF, DBFNTX, DBFCDX, DBFDBT and DBFFPT. In Harbour multiple RDDs can be used in a single application, and new logical RDDs can be defined from combination of other RDDs. The RDD architecture allows for inheritance, so that a given RDD may extend the functionality of other existing RDD(s). Third-party RDDs, like RDDSQL, RDDSIX, RMDBFCDX, Advantage Database Server, and Mediator exemplify some of the RDD architecture features. DBFNTX implementation has almost same functionality of DBFCDX and RDDSIX. NETIO and LetoDB provide remote access over TCP protocol Harbour also offers ODBC support by means of an OOP syntax, and ADO support by means of OLEMySQLPostgreSQLSQLiteFirebirdOracle are examples of databases which Harbour can connect.

xBase technologies often is confused with a RDBMS software. Although this is true, xBase is more than a simple database system as the same time xBase languages using purely DBF can not provide full concept of a real RDBMS

Programming philosophy

Unlike Java which is intended to be write once, run anywhere, Harbour aims to be write once, compile anywhere. As the same compiler is available for all of the above operating systems, there is no need for recoding to produce identical products for different platforms, except when operating system dependent features are used. Cross-compiling is supported with MinGW32. Under Microsoft Windows, Harbour is more stable but less well-documented than Clipper, but has multi-platform capability and is more transparent, customizable and can run from a USB flash drive.

Under Linux and Windows Mobile, Clipper source code can be compiled with Harbour with very little adaptation. Most software originally written to run on Xbase ++, Flagship, FoxPro, xHarbour and others dialects can be compiled with Harbor with some adaptation. As 2010 many efforts have been made to turn the transition from other xBase dialects easier.

Harbour can use the following C compilers, amongothers: GCCMinGWClangICCMicrosoft Visual C++ (6.0+), Borland C++Watcom CPelles C and Sun Studio.

Harbour can make use of multiple Graphic Terminal emulations, including console drivers, and Hybrid Console/GUIs, such as GTWvt, and GTWvg.

Harbour supports external GUIs, free (e.g. HWGui, MiniGUI and Qt) and commercial (e.g. FiveWin, Xailer). HBQt is a library provinding bindings to Qt. HBIDE application included in official distribution and SVN repository is a sample of HBQt potencial.

Harbour is 100% Clipper-compatible and supports many language syntax extensions including greatly extended run-time libraries such as OLE, BlatOpenSSLFreeImage,GD, TIP, Tpathy, PCRE, HbZip (zlib and bzip2), cURLCairo, its own implementation of CA-Tools and NanFor libraries and many others. Harbour has an active development community and extensive third party support.

Any xBase language provides a very productive way to build business and data intensive applications. Harbour is not an exception.

Macro Operator (runtime compiler)

One of the most powerful features of xBase languages is the Macro Operator ‘&’. Harbour’s implementation of the Macro Operator allows for runtime compilation of any valid Harbour expression. Such a compiled expression may be used as a VALUE, i.e. the right side of an assignment (rvalue), but more interestingly, such a compiled expression may be used to resolve the left side (lvalue) of an assignment, i.e. PRIVATE, or PUBLIC variables, or a database FIELD.

Additionally, the Macro Operator may compile and execute function calls, complete assignments, or even list of arguments, and the result of the macro may be used to resolve any of the above contexts in the compiled application. In other words, any Harbour application may be extended and modified at runtime to compile and execute additional code on-demand.

Latest Macro compiler can compile any valid Harbour code including code to pre-process before compile.


 &( ... )

The text value of the expression ‘…’ will be compiled, and the value resulting from the execution of the compiled code is the result.


is the short form for &( SomeId ).


is the short form of &( SomeId + “postfix” ).

Object Oriented Programming

Programming in an OOP style is a broader issue than a specific library or a specific interface, but OOP programming is something many Clipper programmers have come to expect. CA-Clipper 5.2 and especially 5.3 added a number of base classes, and a matching OOP syntax. Libraries such as Class(y), Fivewin, Clip4Win, and TopClass provide additional OOP functionality.

Harbour has OOP extensions with full support for classes including inheritance, based on Class(y) syntax. OOP syntax in Harbour is very similar to that of earlier Clipper class libraries so it should be possible to maintain legacy Clipper code with minimal changes.

Syntax and semantics

Harbour as every xBase language is case insensitive and can optionally accept keywords written just by first four characters

Built-in data types

Harbour has 6 scalar types : NilStringDateLogical, NumberPointer, and 4 complex types: ArrayObjectCodeBlock, and Hash. A scalar holds a single value, such as a string, number, or reference to any other type. Arrays are ordered lists of scalars or complex types, indexed by number, starting at 1. Hashes, or associative arrays, are unordered collections of any type values indexed by their associated key, which may be of any scalar or complex type.

Literal (static) representation of scalar types:

  • Nil: NIL
  • String: “hello”, ‘hello’, [hello]
  • Date: 0d20100405
  • Logical: .T., .F.
  • Number: 1, 1.1, −1, 0xFF

Complex Types may also be represent as literal values:

  • Array: { “String””, 1, { “Nested Array” }, .T., FunctionCall(), @FunctionPointer() }
  • CodeBlock: { |Arg1, ArgN| Arg1 := ArgN + OuterVar + FunctionCall() }
  • Hash: { “Name” => “John”, 1 => “Numeric key”, { “Nested” => “Hash” } }

Hashes may use any type including other Hashes as the Key for any element. Hashes and Arrays may contain any type as the Value of any member, including nesting arrays, and Hashes.

Codeblocks may have references to Variables of the Procedure/Function>method in which it was defined. Such Codeblocks may be returned as a value, or by means of an argument passed BY REFERENCE, in such case the Codeblock will “outlive” the routine in which it was defined, and any variables it references, will be a DETACHED variable.

Detached variables will maintain their value for as long as a Codeblock referencing them still exists. Such values will be shared with any other Codeblock which may have access to those same variables. If the Codeblock did not outlive its containing routine, and will be evaluated within the lifetime of the routine in which it is defined, changes to its Detached Variables(s) by means of its evaluation, will be reflected back at its parent routine.

Codeblocks can be evaluated any number of times, by means of the Eval( BlockExp ) function.


All types can be assigned to named variables. Named variable identifiers are 1 to 63 characters long, start with [A-Z|_] and further consist of the characters [A-Z|0–9|_] up to a maximum of 63 characters. Named variables are not case sensitive.

Variables have one of the following scopes:

  • LOCAL: Visible only within the routine which declared it. Value is lost upon exit of the routine.
  • STATIC: Visible only within the routine which declared it. Value is preserved for subsequent invocations of the routine. If a STATIC variable is declared before any Procedure/Function/Method is defined, it has a MODULE scope, and is visible within any routine defined within that same source file, it will maintain its life for the duration of the application lifetime.
  • PRIVATE: Visible within the routine which declared it, and all routines called by that routine.
  • PUBLIC: Visible by all routines in the same application.

LOCAL and STATIC are resolved at compile time, and thus are much faster than PRIVATE and PUBLIC variables which are dynamic entities accessed by means of a runtime Symbol table. For this same reason, LOCAL and STATIC variables are not exposed to the Macro compiler, and any macro code which attempts to reference them will generate a runtime error.

Due to the dynamic nature of PRIVATE and PUBLIC variables, they can be created and destroyed at runtime, can be accessed and modified by means of runtime macros, and can be accessed and modified by Codeblocks created on the fly.

Control structures

The basic control structures include all of the standard dBase, and Clipper control structures as well as additional ones inspired by the C or Java programming languages:


[DO] WHILE ConditionExp

FOR Var := InitExp TO EndExp [STEP StepExp]
FOR EACH Var IN CollectionExp
  • The  is a sequence of one of more Harbour statements, and square bracketes [] denote optional syntax.
  • The HB_EnumIndex() may be optionally used to retrieve the current iteration index (1 based).
  • The LOOP statement restarts the current iteration of the enclosing loop structure, and if the enclosing loop is a FOR or FOR EACH loop, it increases the iterator, moving to the next iteration of the loop.
  • The EXIT statement immediately terminates execution of the enclosing loop structure.
  • The NEXT statement closes the control structure and moves to the next iteration of loop structure.

In the FOR statement, the assignment expression is evaluated prior to the first loop iteration. The TO expression is evaluated and compared against the value of the control variable, prior to each iteration, and the loop is terminated if it evaluates to a numeric value greater than the numeric value of the control variable. The optional STEP expression is evaluated after each iteration, prior to deciding whether to perform the next iteration.

In FOR EACH, the Var variable will have the value (scalar, or complex) of the respective element in the collection value. The collection expression, may be an Array (of any type or combinations of types), an Hash Table, or an Object type.

IF statements

IF CondExp
[ELSEIF] CondExp

 represents 0 or more statement(s). The condition expression(s) has to evaluate to a LOGICAL value.

SWITCH statements

Harbour supports a SWITCH construct inspired by the C implementation of switch().

SWITCH SwitchExp
   CASE LiteralExp
   [CASE LiteralExp]

  • The LiteralExp must be a compiled time resolvable numeric expression, and may involve operators, as long as such operators involve compile time static value.
  • The EXIT optional statement is the equivalent of the C statement break, and if present, execution of the SWITCH structure will end when the EXIT statement is reached, otherwise it will continue with the first statement below the next CASE statement (fall through).





The BEGIN SEQUENCE structure allows for a well behaved abortion of any sequence, even when crossing nested procedures/functions. This means that a called procedure/function, may issue a BREAK statement, or a Break() expression, to force unfolding of any nested procedure/functions, all the way back to the first outer BEGIN SEQUENCE structure, either after its respective END statement, or a RECOVER clause if present. The Break statement may optionally pass any type of expression, which may be accepted by the RECOVER statement to allow further recovery handing.

Additionally the Harbour Error Object supports canDefaultcanRetry and canSubstitute properties, which allows error handlers to perform some preparations, and then request a Retry Operation, a Resume, or return a Value to replace the expression triggering the error condition.

Alternatively TRY [CATCH] [FINALLY] statements are available on xHB library working like the SEQUENCE construct.


[STATIC] PROCEDURE SomeProcedureName
[STATIC] PROCEDURE SomeProcedureName()
[STATIC] PROCEDURE SomeProcedureName( Param1' [, ParamsN] )
INIT PROCEDURE SomeProcedureName
EXIT PROCEDURE SomeProcedureName
[STATIC] FUNCTION SomeProcedureName
[STATIC] FUNCTION SomeProcedureName()
[STATIC] FUNCTION SomeProcedureName( Param1' [, ParamsN] )

Procedures/Functions in Harbour can be specified with the keywords PROCEDURE, or FUNCTION. Naming rules are same as those for Variables (up to 63 characters non case sensitive). Both Procedures and Functions may be qualified by the scope qualifier STATIC to restrict their usage to the scope of the module where defined.

The INIT or EXIT optional qualifiers, will flag the procedure to be automatically invoked just before calling the application startup procedure, or just after quitting the application, respectively. Parameters passed to a procedure/function appear in the subroutine as local variables, and may accept any type, including references.

Changes to argument variables are not reflected in respective variables passed by the calling procedure/function/method unless explicitly passed BY REFERENCE using the@ prefix.

PROCEDURE have no return value, and if used in an Expression context will produce a NIL value.

FUNCTION may return any type by means of the RETURN statement, anywhere in the body of its definition.

An example procedure definition and a function call follows:

 x := Cube( 2 )

 FUNCTION Cube( n )
 RETURN n ** 3

 Sample code The typical “hello world” program would be:

  ? "Hello, world!"


  QOut( "Hello, world!" )


  Alert( "Hello, world!" )

Or, enclosed in an explicit procedure:


    ? "Hello, world!"



OOP examples

 #include "hbclass.ch"


    LOCAL oPerson := Person( "Dave" )

    oPerson:Eyes := "Invalid"

    oPerson:Eyes := "Blue"

    Alert( oPerson:Describe() )

 CLASS Person
    DATA Name INIT ""


    ACCESS Eyes INLINE ::pvtEyes
    ASSIGN Eyes( x ) INLINE IIF( ValType( x ) == 'C' .AND. ;
                 x IN "Blue,Brown,Green", ::pvtEyes := x,; 
                 Alert( "Invalid value" ) )

    // Sample of IN-LINE Method definition
    INLINE METHOD Describe()
       LOCAL cDescription

       IF Empty( ::Name )
          cDescription := "I have no name yet."
          cDescription := "My name is: " + ::Name + ";"

       IF ! Empty( ::Eyes )
          cDescription += "my eyes' color is: " + ::Eyes

       DATA pvtEyes

 // Sample of normal Method definition.
 METHOD New( cName ) CLASS Person

   ::Name := cName




  • HBMK2 – Powerful build tool like make
  • HBDoc2 and  HBExtern – Creates documentation for Harbour
  • HPPP – Pre-processor, a powerful tool which avoids typical problems found on C language pre-processor
  • HBFormat – Formats source code written on Harbour or another dialect according defined rules
  • HBi18n – Tools to localizing text on applications
  • HBRun – Shell interpreter for Harbour. Macro compiling allows to run any valid Harbour code as it’s being compiled
  • HBIDE – Integrated Development Environment to help Harbour development and various xBase dialects

All tools are multiplatform.


Today Habour development is leading by Viktor Szakáts with huge collaborations and leading many components of core and contribs by Przemysław Czerpak. HBIDE and some components, specially HBQt, are developed by Pritpal Bedi. Others members send minor changes to the Sourceforge SVN repository.  As 2010 Harbour development is keeping vibrant activity


Although there is no way to measure popularity of Harbour or xBase, the TIOBE Programming Community Index As of June 2006 ranked Microsoft Visual FoxPro, a high profile dialect of xBase, on 12th position on programming languages popularity ranking. FoxPro/xBase ranked on 25th position As of August 2010. As of September 2010, the Clipper Usenet newsgroupscomp.lang.clipper is still active. As of August 2010 Harbour figured on 16th position on weekly downloads in compiler category and 132th position on global rank.

xHarbour comparison

xHarbour is a fork of the earlier Harbour project. xHarbour takes a more aggressive approach to implementing new features in the language, while Harbour is more conservative in its approach, aiming first of all for an exact replication of Clipper behaviour and then implementing new features and extensions as a secondary consideration. It should also be noted that Harbour is supported on a wide variety of operating systems while xHarbour only really supports MS Windows and Linux 32-bit.

The Harbour developers have attempted to document all hidden behaviour in the Clipper language and test Harbour-compiled code alongside the same code compiled with Clipper to maintain compatibility.

The Harbour developers explicitly reject extensions to the language where those extensions would break Clipper compatibility. These rejections were soften recently since the new Harbour architecture allow extensions out of the core compiler.

A detailed comparison between extensions implemented in Harbour and xHarbour can be found in SVN repository of the project on SourceForge.

As of 2009–2010, Harbour has seen a huge increase in its adoption while xHarbour decline as can be seen on his mailing list

See also


  1. ^ Harbour license
  2. ^ LetoDB
  3. ^ Official Harbour page
  4. ^ http://sourceforge.net/projects/harbour-project/
  5. ^ TIOBE Programming Community Index
  6. ^ SourceForge
  7. ^ About xHarbour
  8. ^ xhb-diff.txt
  9. ^ Harbour developers’ mailing list statistics
  10. ^ xHarbour developers’ mailing list statistics
  11. ^ ohloh.net Activity comparison

External links

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note : This post borrowed by curtesy of Vikipedia from here : http://en.wikipedia.org/wiki/Harbour_(software)