A programming language in which object ''properties'' have specific language constructs.  Examples: CeeSharp, DelphiLanguage, VisualBasic.

In ObjectOrientedLanguage, a ''property'' is merely a pattern of accessor methods.  Somebody please enlighten me on the benefits of promoting them to language constructs.

-- MattRickard

''The benefits are:''
	* '''''A:''' you can follow the standard newbie diktat that all data members should be private without really understanding it, and'''
	* '''''B:''' you can treat as data members properties exposed from remote ebjects thru ComAutomation or EnterpriseCorba. Until you try to take a C++ reference to them.''
''-- PhlIp''

I would posit that a true ComponentOrientedLanguage would differ from an ObjectOriented language by raising design patterns of ComponentBasedProgramming to the level of language features.  That is, it would provide language mechanisms for defining:
	* Rich component interaction protocols (AbstractInteractions).
	* Component implementations that play roles in one or more interaction protocols
	* How components are mapped to deployed packages
	* Composition of components (ThirdPartyBinding)

Properties are only one form of interaction protocol.  Method calls and events are other forms widely used in single-process programs.  Distributed programs have a wide variety of useful interaction forms.

In practice, I think that component based programming requires multiple languages, each specialised for specifying a subset of ComponentDesignPatterns, rather than just one swiss-army-knife language. Examples of this approach include AspectOrientedProgramming, SubjectOrientedProgramming, HyperSpace''''''s and ArchitectureDescriptionLanguage''''''s.

-- NatPryce

----

In addition to providing easy access to properties and methods, a ComponentOrientedLanguage should provide constructs for setting up something as an "observer" or "event sink" for a component.

-- KrisJohnson