[MUD-Dev] (no subject)

[Bruce]

John Buehler wrote:
> >From: "Joe Andrieu" <joe at andrieu.net>
> >Date: Tue, 21 Nov 2000 09:42:02 -0800
> 
> >It seems like the value of components is that it forces
> >you to be strict and define your relationships clearly
> >and cleanly, while inheritance allows a programmer to
> >just run with the inheritance and do whatever, dealing
> >with conflicts when they are a problem.  Or put 
> >differently, components allows the diligent programmer
> >to write tight, clean code, while inheritance allows
> >a looser mechanism for building out the codebase.
> 
>   Yup.  As long as we continue to write applications
> from the ground-up and never reuse software, we can
> continue to get away with inheritance as our means of
> structuring code.  But when we want to start building
> software by grabbing bits and pieces of other
> applications, we'll need that strict formation.
> The alternative is to keep pouring more and more into
> big toolkits (like operating systems, graphics systems
> and the like) so that we can continue to write from
> the ground-up - and the ground level just keeps
> going up.

John,

I mean you no disrespect, but I think that perhaps you have been
a bit overly enthusiastic in some of your posts on this topic.

Many aspects of this topic are active areas of research and
development, with differing ideas coming out of them.  (Note
that I am not a fan of inheritance.  I've been arguing with
people against is-a relationships in MUD-type applications for a
couple of years now.)

A good programmer, should have a wide variety of tools at his
beck and call and choose those which are appropriate to the
situation.  Every task is different, with different goals,
requirements, and users.  It is important that someone designing
and/or implementing a system have the freedom to choose those
tools which they feel will work best within the context of a
problem and the values that comprise that problem.  In many
cases, yes, I agree, components will be useful.  Although, what
exactly is meant by components and the scope of that definition
may vary depending upon other decisions made during the course of
design and implementation.

Some interesting examples of research or prior studies that
haven't come up at all on this topic could include:
 * The Law of Demeter
 * Component coupling and cohesion problems.
 * Physical component design (ala Lakos) and related
   physical issues.
 * Aspect Oriented Programming
 * Dynamic/Reflective systems
 * Languages with constructs to add in re-usability and
   extensibility of code.
   * Many aspects of the TOM programming language.
   * Categories and protocols within Objective C.
 * MS's Intentional Programming
 * Generative Programming
 * Metaprogramming

After all, without taking these and other concepts into
consideration and just accepting/believing/arguing that
components are a Silver Bullet (Hi Mr. Brooks!), you could just
as well end up with a sea of new problems: piles of components,
horrible build systems, coupling and cohesion problems that limit
re-use as new versions of components are shipped and details have
changed, and so on.  The work of Lakos and the Law of Demeter are
especially interesting when looking at some of those problems.

Your above response also seems to indicate that components _can_
be designed to be widely re-usable outside of their original
application.  While this is true in some cases, it remains to be
seen how widely true this becomes in the general sense.  Many
proposals for increasing reusability of code (OO, frameworks,
patterns to some extent) have come and gone over the years, each
yielding incremental results, but no silver bullet.  (Or in the
case of something like OpenStep, whether or not it even manages
to be commercially successful.)

At the other end of the spectrum are things like extreme
programming, refactoring, which encourage constant design and
change in the sources, keeping stability and remaining functional
through extensive use of unit tests and working closely with
peers.  This seems to be working remarkably well for some people
and aiding them in becoming  more productive and have higher
quality code.  (Although some of the precepts like "You ain't
gonna need it" (YAGNI) are admitted to not work well when
developing a library or framework, despite it being invaluable in
other types of projects, such as an application.)

Although, I may be over-reacting to this because I'm a freak and
love to see different ways of implementing the same types of
systems.  Some of the generative programming stuff is absolutely
fascinating!  But at the same time, I love large tracts of Common
Lisp and SmallTalk.  There are some great techniques for helping
to avoid some common bugs in Cecil with its predicate objects.  

(I'll be happy to provide URLs or other sources of information on
any of the above topics if anyone is interested.)

 - Bruce
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev