Component programming

[H. S. Teoh]

On Wed, Jul 31, 2013 at 12:20:56PM +0200, Chris wrote:
> This is only losely related to D, but I don't fully understand the
> separation of component programming and OOP (cf. https://en.wikipedia.org/wiki/Component-based_software_engineering#Differences_from_object-oriented_programming).
> In an OO framwork, the objects are basically components. See also
> 
> "Brad Cox of Stepstone largely defined the modern concept of a
> software component.[4] He called them Software ICs and set out to
> create an infrastructure and market for these components by
> inventing the Objective-C programming language." (see link above)
> 
> Walter's example (http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321)
[...]

Thanks for the link to Walter's article, it was a very insightful read.

I can't say I'm that clear about the difference between component
programming and OO, so I'll decline comment.

One question that the article did raise, though, was what to do when
your algorithms require non-linear interconnectivity between components.
For example, say I have an expression evaluator that takes an object
that represents a math expression, and another object representing a set
of identifier-to-value mappings, and returns the value of the expression
given those mappings:

	Value evalExpr(Expr,Ident,Value)(Expr e, Value[Ident] mappings)
	{
		...
	}

In the spirit of component programming, one would conceivably have an
expression parsing component that takes, say, an input stream of
characters and returns an expression object:

	Expr parseExpr(InputRange)(InputRange input)
		if (is(ElementType!InputRange : dchar))
	{
		...
	}

And conceivably, one would also have a variable assignment parser that
parses an input stream of characters containing user-typed value
assignments, and returns a Value[Ident] hash (obviously, this last bit
can be generalized to any AA-like interface, but let's keep it simple
for now):

	Value[Ident] parseBindings(InputRange)(InputRange input) { ... }

So now, my main code would look like this:

	void main(string[] args) {
		assert(args.length == 3);
		parseExpr(args[1])
			.evalExpr(parseBindings(args[2]))
			.copy(stdout);
	}

Which is not as pretty, because of the non-linear dependence on args[1]
and arg[2]. I've a hard time turning this into its own reusable
component, because it requires multiple disparate inputs. It's also easy
to come up with examples with multiple outputs, and, in the general
case, components with n-to-m input/output connectivity. How do we still
maximize reusability in those cases?


T

-- 
There are two ways to write error-free programs; only the third one works.