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, HyperSpaces and ArchitectureDescriptionLanguages.
-- 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