Component Oriented Programming Language

Component Oriented Programming Languages:

Proposed Criteria for a ComponentOrientedProgrammingLanguage

So I propose these criterias for a language/development environment to be recognized as component oriented or component based:

Should have a precise definition of what component means. Both in DelphiLanguage and in VisualBasic, component is a very precise term.
Should have a legitimate claim to a standard definition of component, if the definition of component goes against the grain. By legitimate I mean should have been there for some time, not just attach a word component to let's say distributed object because components are very fashionable lately.
Should have been proven by practice. A research language doesn't count too much here, unless it's proven that influenced more practical projects.
Should support a sensibly different way/method/technique of software development. The new way of doing things should provide sensible advantages in terms of productivity, reliability and so on. VisualBasic and DelphiLanguage clearly do that, and their way of doing things have been labeled as ComponentBasedDevelopment for a long time already.

Should adhere to a reasonable concept of component as instituted by the above rules.

Anything that doesn't meet these criteria, and claim to be component oriented and/or component based , is for me just an illegitimate marketing scam. --CostinCozianu

One thing I would add to the list:

Must have a well defined version handling and compatibility procedure.

Once you no longer link together pieces into a single executable, maintaining versions and ensuring interoperability between versions of the various components becomes a major chore. --WayneMack

DependencyHell

In my experience, "component" tends to refer to something that is similar to an instantiated object without implementation inheritance (including cloning and prototyping). -t

Proposed Candidate Languages

VisualBasic (Microsoft)
DelphiLanguage (Borland)
CsharpLanguage (Microsoft)

Premise of MicroSoft marketing

A newly created language, called C#, has been called by Microsoft the 'first' ComponentOrientedProgramming language as part of the C and C++ family. It is designed to combine the power of these languages with the functional ease of modern, rapid application development tools.

There seems to have been a lot of griping about Microsoft claiming C# as the "first" ComponentOrientedProgrammingLanguage. I highlighted the above to point out the quote actually says C# is the first such language in the C/C++ family. Verification is up to someone else. ;)

Responses

That's Microsoft's marketing blurb. What is a component oriented language ? And how does C# fit into that definition ? As far as it concrens me there are only 2 serious (mature enough) development environments (not programming languages) that are component oriented. Borland DelphiLanguage and VisualBasic. See ComponentDefinition. --CostinCozianu

I posture that a language named ComponentPascal would debunk the claim. Interestingly, ClemensSzyperski used it for its example code in his ComponentSoftware book, while he was working at OberonMicrosystems? (I think). He then went on to Microsoft Research, and I believe he worked on the development of MicrosoftDotNet, and quite possibly helped develop this supposed "first" ComponentOriented programming language in question, CsharpLanguage. --PierrePhaneuf

I would guess that what is meant by a 'component oriented' language would be that components were FirstClass in that language. Or possibly that the whole design of the language was predicated around making it simple to work with components (no drawing pentangles or writing IDL). -- BrianEwins

I posture that a language named ComponentPascal would debunk the claim.

Just because the language is called Component Pascal and that the authors declare it component oriented doesn't make it component oriented. Let's debunk the debunk.

If you go to http://www2.fit.qut.edu.au/CompSci/PLAS//ComponentPascal/language_report.html, and do a search fopr component to figure out what is a component in ComponentPascal you find nothing. Actually you find this claim:

: Complete type safety and the requirement of a dynamic object model make Component Pascal a component-oriented language.

Really? Then I'd propose a couple dozen languages as component oriented. I don't know why the classic Pascal or Oberon or Modula-2 wouldn't qualify. A lot of marketing hype has been placed around ComponentBasedDevelopment, including naming a perfectly normal and ordinary language ComponentPascal, including incorrectly designating tons of technology as having to do with components : EnterpriseJavaBeans, COM/DCOM, CORBA, probably .NET will come soon. I for one cannot accept for example that "components" as in COM family is just object-oriented RPC (oh, this qualifier is also ill defined and heavily abused). The only revolutionary products that I know of, which legitimated a component based approach, were used in serious production systems, seriously increased developer productivity and software reliability are VisualBasic (with ActiveX ) and DelphiLanguage. Probably PowerBuilder also has a legitimate claim, but I'm ignorant on the subject.

Features of CsharpLanguage that would Support Claim

What features of CsharpLanguage make it a ComponentOrientedProgrammingLanguage (other than what we have in JavaLanguage)?

The primary feature that has been cited to me is the notion of the assembly as a boundary of naming, deployment, versioning, and security. Everything to do with types, interfaces, type dependencies, and access is granular to the assembly level.

The concentration in C# seems to be the design, creation and use of business-problem-solving classes and components. It seems to be designed to guide the developer/ architect smoothly into blueprinting a class that's intuitive and easy to client-program against.

There's not a great amount of functionality within the language itself, but rather it provides a very good framework (I use that word in a different context; I don't mean the .NET Framework) to leverage language-independent libraries and create and manage business objects that use that leveraged functionality. The learning curve for the language itself is shallow,and distinctly separate from the BCL's.

In Java, there's a bit more of a curve with everything sort of being lumped together under the language itself.

Properties
Robust Versioning
Events/Delegates (NOT inner classes)

Some more with help from the MicrosoftDotNet folks:

The major feature of "componentness" ("componentality"???) is that the component is a self-contained entity that has everything it needs to be a component encapsulated inside of it.

From a feature perspective, I'd say this means:

Properties
Indexers
Events
Attributes
XML docs as part of the code
Explicit override
Parameterized Properties
Filtered Exceptions

In a word: assemblies.

A component tends to consist of more than one class - it's a lump of code that provides some particular facility. (All but the most trivial/apallingly-written components will be implemented in terms of multiple classes.) The unit of packaging in .NET is the assembly, which corresponds to a component.

In Java you have class files, which represent precisely one class, and you had jar files, which represent, well, nothing in particular - just a bunch of class files. Jar files provide a much weaker mechanism for deploying components, because they've never been a fundamental part of Java's programming model. (And neither have packages, which are arguably related to this area.) ? The component model in java is based on EJBs, not individual classes or jars. Jars do represent something if the manifest is used properly; also the jar variants (war, ear, sar) provide other, additional packaging concepts. In this sense the 'COPL' associated with java is not in java itself, its the deployment descriptor which describes how components are assembled into an application. This has the identical concept of 'assembly as a boundary of naming, deployment, versioning, and security' described above.

EJB is an extension library, not the language itself. fair enough - I was just commenting on the comparison of .NET assemblies and Jars. A better way of putting might be to say that in C# the thing equivalent to the java's XML deployment descriptor is also written in C#, which would justify more of a claim to be a component oriented language (I just went to the C# lang spec to figure out what you meant, this seems to be it?).

But I can think of two problems with proposing the EJB component model as a competitor to .NET assemblies:

This is only any good if you're actually writing EJBs
The physical EJB component packaging model is a hack to work around the absence of proper support for components in the Java platform.

To expand on (1), I have come across J2EE systems where everything was written as an EJB. IMO this misunderstands the intent of EJB, and is always a mistake. Unless you are actually writing something which fits into the mould of a Session Bean or an Entity Bean, you really don't want to be an EJB at all. I work on a lot of Java systems [1]*, and a lot of code fits into neither of these roles - I believe there is a place in Java enterprise systems for good honest old fashioned Java classes. In fact many of the systems I work on use nothing but this, Servlets, JSP and JDBC, and don't seem to be any the worse off for it.

Trying to lever everything into the EJB model is more or less directly akin to making all of your .NET classes inherit from ServicedComponent?. Or in the pre-.NET MS world, it would be akin to writing everything to run in MTS/COM+ as a configured component, whether it made sense or not. This would be just as much of a misapplication of technology (and at one stage it was just as rife as misapplications of EJB seem to be today), and it's never a good idea.

So I would maintain that whilst the EJB component model may address some of the shortcomings of Java in this respect, that's of no help to anyone not writing code that fits usefully into the EJB model.

As for (2), I think the existence and nature of the EJB model stands as testimony to the shortcomings of Java in this respect. That they had to invent it for EJB illustrates that it was something the platform was missing. And I never enjoy my experiences with working with this aspect of EJB. (Although this may be a quality of implementation issue...) The mechanism of building a component all seems a bit clunky and half-baked to me. And none of the fruits of your labours seem to be accessible afterwards - as far as I'm aware there are no extensions to the Java Reflection API that enable you to examine EJB components.

That said I do like the concept of the WAR file (Web Archive) - the idea that I can package up everything that a container needs to run my web application in some standard format appeals to me. (So many hours wasted on deployment... WAR files seem to be a step in the right direction.) But that seems to be dealing with a much higher level of granularity.

I am not trying to suggest that all things are equal, nor to argue the merits of one component model or t'other. Most platforms have a component model of some kind, but calling C# the first ComponentOrientedProgrammingLanguage makes us ask what features of other platforms/environments have been included the C# language that aren't in other languages, specifically java. Since the main thrust of (this section of) the page was to ascertain what features of C# make it a component oriented language, I thought it only fair to compare against the features of the java (well, j2ee) platform which are component oriented. If java actually had every feature of C# in the java language, the claim would be nonsense wouldn't it? The whole point is that there are things which are part of one language but not the other! Hence, when it turned out that C# has language features for components that java has to reach outside the language for, I thought the question had been answered? Ho hum. I'll lay the confusion at the door of my (& suns) using java to mean the language, the platform, the runtime, the libraries... :o)

CsharpLanguage Features Seen Before

Many of the above features (probably all), have been already present in ObjectPascal of DelphiLanguage, and in VisualBasic (with probably less flexibility and power than ObjectPascal). They are nice and desirable language features, although some people might prefer language simplicity. For me language features are desirable as long as they don't overlap each other, and offer something really valuable.

But let's imagine that both DelphiLanguage and VisualBasic would have supported only those as language features. And they didn't have a component palette, a property inspector and a composition mechanism that allows one to actually assemble application, with only writing or generating minimal amount of code, but mainly through alternative techniques: configuring component properties in the inspector, and wiring components together (for example binding a datasource to data display fields). Would have they been as successful as they are now ? Would they have presented a significant difference from other ways of doing software development, and lead everybody to talk about ComponentBasedDevelopment ? My thinking is that clearly they would have not. So if these two set precedence and raised the bar to what should be ComponentBasedDevelopment, why should we settle for anything less ? --CostinCozianu

C++Builder (Borland)
JBuilder (Borland)

No way. I'm sure these were put by Costin the Borland lover but neither of these is a language! This does not fit the definition of the topic. Both of these are IDEs/Environments. Actually you are then implying that both of these do not produce standard code then. I haven't put them in there. They are less than DelphiLanguage anyway, and DelphiLanguage is not a language. And by the way, VbDotNet might prove a better component platform than C# - I have nothing against Microsoft. See my comments below. --CC

C++ is the language which the C++Builder includes within the Suite -- It is an environment which includes a language and many very helpful tools allowing quick and easy builds of executables. There is a way that the two mentioned Development tools can be considered to be employed in developing ComponentOrientedPrograms?, it is not an exclusive concept for a limited application.

Read the title of the topic. See that word language? It conveys meaning in this case...

You would have to remove almost all comments on this page if you restrict comment only to "language", you would also object to the introduction of EnterpriseJavaBeans, COM/DCOM, CORBA, .NET

Strictly speaking, this page was about C# and rapid application development tools. The first paragraph on the page's initiation (until someone moved it):

A newly created language, called C#, has been called by Microsoft the 'first' ComponentOrientedProgramming language as part of the C and C++ family. It is designed to combine the power of these languages with the functional ease of modern, rapid application development tools.

Another hypothesis: it is improper to speak of ComponentOrientedLaguage?.

We already have a widely accepted term ComponentBasedDevelopment, and at least two commonly known example: VisualBasic and DelphiLanguage. I'll even submit to the hypothesis that COM and EJB are component models (though I have very serious doubts) and with Visual Studio .NET bETA or whatever you are actually doing CBD. Now I just had a look both at ObjectPascal (the language underneath Delphi ) and C# specs. Did a search for the word component ? Guess what, the word is not there. Both of them are very good ObjectOrientedLanguage, but they don't have a notion of component embedded in their construction.

for .NET components =(assemblies).

What they have is that they do have some specific features that makes it easy for a component writer to create components (properties, events and so on). But even less than that (a framework, or a naming convention can be used as in the JavaBeans example) can be enough.

Thus the component orientation is in all practical cases that we know of one level above the language (in a framework, in an integrated product, and so on). The language is just a support, and it usually is ObjectOriented, but I don't see any reason why it couldn't be a functional programming. Maybe component orientation can't be at the language level. After all my hypothesis ( see ComponentBasedDevelopment) is that components should make design time interaction even easier than programming, because CBD essentially goes to code reduction and reuse even further. A lot of repetitive boring coding tasks are replaced by the property inspector, by connecting an display grid to a query component in a visual editor, and stuff like that. Of corse we shouldn't get rid of coding altogether, but CBD is about the absolute minimization of coding. Coding is for to be reserved for complex things, not for formating texts, displaying data, handling user input and stuff like that. --CostinCozianulololllll?

Research versus Production Languages

There have been many "component oriented" programming languages designed by researchers since the 1980s. An early example was Conic, designed at Imperial College, London. It went on to influence many projects, including the language used to configure software components in Phillips TV sets.

And of course FlowBasedProgramming, which while not technically a language, is very definitely ComponentOriented, and has been helping to run a bank since the early '70s - so does that not make it "production"? --PaulMorrison

CategoryComponents