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