There exists quite a number of different component notions with different goals and features. Although component support in Lava is still in an early, conceptual phase, our basic ideas about components can already be outlined:
From the Lava perspective, components are various kinds of containers of "external" objects which in turn may have different types. The type of an object is designated by an Lava-external type identifier, and an object may be processed by the respective Lava client program through one or several "interfaces". For locating the proper object owner, object server, or the memory location of a persistent object we need a "uniform resource locator" (URL) additionally .
The "remote access" components that are presently on the market, like COM/DCOM, Enterprise Java Beans (EJB), CORBA objects and CORBA Component Model (CCM), are examples of component notions that can be interpreted in this unified way.
Moreover, Lava treats all kinds of persistent local or remote objects with "external" identifiers, that can be processed through interfaces, as component objects, for instance files, databases, local and FTP file systems, Web pages and mail-boxes, all kinds of objects that are managed by continuous system services. They are all made accessible through the same operations new, attach, and possibly query interface, for processing through specific interfaces.
E.g., Web pages may be processed through the interface(s) of a "Document Object Model" (DOM), files through read/write interfaces. Databases may be viewed as persistent sets of objects whose interfaces describe the data structure of these database objects. In the last case this requires, of course, an interface notion like that of Lava, that includes not only functions but also attributes, and that supports multiple inheritance (which is needed for CORBA).
The name space of type identifiers is specific to the respective kind of components. E.g., for Microsoft-COM components it is a 16 byte "class ID" (CLSID). The URLs of persistent objects have various formats. For Web pages they consist of the usual Internet URL (http://...), the URL of local files is their usual pathname, etc..
The file menu of the Lava programming environment contains an import command for components. Given a concrete component of any kind, its purpose is to generate a Lava component object specification for all types of component objects that are supported by that component. A component object specification is primarily a list of component object interfaces that are supported by the respective component object.
Lava will also support event handlers (callbacks, notifications) following the conventions of the respective component notion. They enable immediate reaction to events occurring within the component object, provided that the component supports such notifications.
Lava will provide prefabricated component object specifications for various standard types of components (like file, http, ftp, mail) which will render explicit import operations superfluous in these cases.
New component objects are created by a variant of the quite normal Lava new construct in the address space of the containing component. If a component object, for instance a persistent object, has already been created outside the Lava program then it can be attached to the Lava program by the Lava attach operation.
The new and attach operations specify the Lava name of a component object specification and of an interface through that the object is to be processed. For persistent objects the respective URL is specified additionally. An object may have several interfaces, and a query interface operation allows you to navigate forth and back between these. (In this way, objects having many capabilities can be used by non-oo languages or by programming languages that support only single inheritance.)
If you call a method of a component object and this call is directed across the border between address spaces or programming languages then you will be forced generally to pass complex parameter objects "by value", i.e., they are copied to the target address space. Two questions arise in this context:
Is parameter passing "by value" indeed semantically admissible and meaningful in this concrete case?
Which nested sub-objects of the parameter object are really constituents, and which of them are merely acquaintances of the object, that should be viewed as separate, independent objects and thus should not be passed "by value" together with the actual parameter object?
The answer to the first question will generally be "no" if the object is a variable state object with uniqueness semantics.
For instance is the semantics of a bank account not preserved by parameter passing by value, cloning or copying, unless it has just the semantics of copying a snapshot of its current state. But the semantics of such a snapshot differs from that of the actual bank account.
In contrast to this, copying a (signed and thereafter immutable) money transfer order is semantics-preserving, provided it doesn't cause the money transfer order to be executed twice.
In Lava you can distinguish these two object categories explicitly: When declaring a variable you can specify whether the values of that variable are mutable state objects (with uniqueness semantics) or complex value objects that become immutable after they have been constructed completely (i.e., when they leave the Lava new construct); thereafter they may be copied/cloned/passed by value without restrictions. (For function parameters you may also specify that they should be of the same category as the call object of the function call. Local variables and function parameters, but not for member variables of classes, may also be of "any category" (in cases where their treatment doesn't depend on their category).
LLikewise, you have to distinguish explicitly in Lava whether a member variable of some Lava class represents a constituent of the containing object, or else a pointer to a separate object (acquaintance).
As a consequence of these explicit semantic distinctions, parameter passing by value, copying, cloning, and comparison of objects can be performed automatically in Lava, while in other languages the programmer has to resort to the manual programming of individual cases generally.
Note that Lava provides high-level support of form-based user interfaces that are generated in a semi-automatic way from Lava class declarations.