Techical Tips
As soon as Win95 and the like came out, programmers said, "ohboy! Threads!"
Well, sometimes they are really really good. But sometimes multithreaded apps actually seem to run slower, and have more overhead, than their equivalent Win31 implementation.
It turns out, by the way, that this is a process that gets done so much (MVS and DOS/VS were doing it before you were born, maybe...) that you can buy "transaction monitors," and other pieces of software that can snap into your applications, to queue and regulate the flow of work through a multi-user or server-style application.
Remember also that "a process that can't really be completed in a concurrent fashion ... doesn't need separate threads, it needs a message queue."
X-(
COM is an acronym for "Component Object Model". It's a standard that describes how class (or object) interfaces should work -- including issues such as memory management and multithreading -- and how applications can make use of components which follow the COM standard. The standard is langauge-independent and (at least as I understand it) hardware independent as well. The standard has been pushed primarily by Microsoft and IBM, but there is no technical reason why, for instance, a Sun Sparc20 running Solaris couldn't support COM as well.
If an object is COM-compliant, it's guaranteed to have several basic
traits:
The client can call QueryInterface to determine whether the object supports a specific interface (an interface is a group of properties and methods). If it does, QueryInterface returns a pointer to a table of pointers to the properties and methods implemented by the interface. The client can then beginning calling those methods, use pointers it obtains from the table.
OLE is an "evolving standard" (which you might read as "moving target") for implementing services (components, applications, etc.) using COM-compliant objects.
OLE automation is a particular OLE service which makes it possible for a client to control a component. Actually, it's a little more specific than that. A component which can be controlled through OLE automation has an interface called IDispatch. IDispatch includes methods for determining what methods an interface supports, the names, data types and so on of each method's parameters, and for retrieving a special "dispatch ID" for each method in the interface. If the client knows only the name of the method, it can determine everything it needs to know to call the method through IDispatch. It's time consuming, but it works. Better yet, the client can determine in advance (e.g., when it is compiled) the dispID and parameter info for each method it needs to call, and call the method directly through IDispatch's Invoke method at run time.
When you compile a VB program, it uses objects' IDispatch interface (and/or type libraries) to determine the dispID and parameter info for all your object method calls, and compiles that information right into your program. That's called "early-binding" and it results in the fastest possible calls you can make using OLE automation. You can also use "late-binding": in that case, VB has to use IDispatch at run-time to determine the dispID, etc., for a method given its name. That's what happens whenever you use an object variable declared "As Object". It's slow and somewhat unsafe (since VB can't do any compile-time checking of your parameters), but it's sometimes used for its flexibility.
From: "de Villiers" <devilliers@wxs.nl>
This is where Delphi took a few leaps forward in front of other development languages. Once you understand this concept - you understand OOP. Delphi implements classes in a very unique and robust way: there are three levels:How these three levels are used to implement your class is very interesting - the private member variables are, as usual, private to the class function implementations. Nobody can access them.
Then you get the access functions. They are usually public, because they usually need to be accessed from outside the class. There are usually a SetField and GetField function which control and implement the writing and the reading of the (private) field. These functions are necssary in OOP because you might need to verify the data before writing to the field, return a specific format depending on certain variables, or reads/writes might trigger some other action. All this is handled by these access functions. However, in Delphi, access function can be declared private.
This is possible because the fields are not manipulated from outside the class through access functions, but rather through properties - which is the next level.
A property is public field. The only difference between a property and a private field is that a property itslef does not contain storage space for data. A property is simply a "field" which the user sees, instead of seeing Set* and Get* functions. That is why a property needs to have a read method and a write method (and a default value is provided).
So you can see that a property has no actual data storage space. It merely calls the private access functions, which write/read data into/from the private field. The example below might explain it better:
class TClass begin private: integer fVal; procedure SetVal(integer V); function GetVal : V; public integer Value read GetVal write SetVal default 0; end;
Here, fVal is the private data member which can only be accessed by the class. The functions SetVal and GetVal are used to access the private field. They are also private, though, meaning they can also only be accessed from within the class. Then you get the Value public field. This is the "interface" which the user sees - it hides the implementation details of the data.
One more interesting aspect of Delphi is published. If you declare a property (or event) published, then it is automatically public, but it is also available at design-time. The object inspector lists published properties and events.
Please email
me and tell me if you liked this page.