[Prev][Next][Index][Thread]

Re: Tim Sweeney on Programming Languages

In article <1e5j7vy.1wbl2xsdh8on8N%schuerig@acm.org>,
schuerig@acm.org (Michael Schuerig) wrote:

>Bruce Hoult <brucehoult@pobox.com> wrote:
>
>> In article <1e5idqr.d56wo98jb9i2N%schuerig@acm.org>, schuerig@acm.org
>> (Michael Schuerig) wrote:
>> 
>> > I don't remember Sweeney's article very well, but the lasting impression
>> > _why_ he wants this kind of mechanism seems to be that it allows to
>> > change/enhance classes that live "in the middle" of a framework.
>> 
>> I'm not entirely sure that's why he wanted it.  Maybe I missed something.
>
>
>Here's the (IMHO) relevant part from
><http://www.gamespy.com/articles/devweek_e.shtm>:
>
><QUOTE>
>[quote snipped]
></QUOTE>
>
>So, he wants to express abstractly the relationship among a bunch of
>classes. This is exactly what he can get with interfaces and factories.

Yes, you can fabricate this kind of thing with interfaces and factories.
BUT, that requires that the original author of the library/framework built
in those interfaces and factories so that others can use that to extend the
framework.

It comes down to something that's repeatedly mentioned in the article: It's
possible to build higher level constructs without language support, but
it's a lot of work and generally not really compatible with other libraries
at those higher level constructs.

Like it is possible to build an object oriented program in plain (non-++) C
using function pointers and structs.

The advantage of having this in the language is that it gets standarized,
and thus various frameworks and libraries will be compatible at least on
the technology used to implement the framework construct. Secondly,
programmers of libraries/frameworks need not worry about this sort of
thing, and can concentrate on their own functionality rather than on
inheritance mechanisms.


As for why such a framework construct can be very useful, the first quote
from Michael above about covers it, with the remark that this will be
especially useful in cases where the base framework might get revised, as I
recall has happened to the Unreal engine once or twice. :-)  Tim knows why
he want such a language construct.

Maarten
Follow-Ups: References: