[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: dynamic loading of native code modules]
From: |
Thien-Thi Nguyen |
Subject: |
Re: address@hidden: dynamic loading of native code modules] |
Date: |
Tue, 14 May 2002 13:54:48 -0700 |
From: Bill Gribble <address@hidden>
Date: 14 May 2002 11:11:12 -0500
On Tue, 2002-05-14 at 05:57, Thien-Thi Nguyen wrote:
> it looks like a plan to just implement something and throw it against
> the wall to see if it sticks. in particular, having the interface
> number encoded in the name doesn't sound like fun for anyone.
For someone who spends so much time hopping up and down about process
and development culture, you sure don't hesitate to start throwing
around derogatory and inflammatory language. Put a cork in it, please!
Language like this makes you part of the problem, not part of the
solution.
The whole idea of encoding interface numbers in the name was explicitly
and exclusively a temporary hack. It certainly wasn't proposed by
_anybody_ as a final solution.
the two areas you mention are independent; i don't see the connection.
good process demands open exchange of different ideas, including the
evaluation of "is this idea sound or will there be problems?" by people
besides one's nanny.
i don't see how hacks that touch /usr/local/lib and require third party
cooperation (by some who are extremely vociferous in their disgust of
bad design, trust me) can be called "temporary". but let's say that
this does go into code and (less discerning) people buy into it. what
exactly is the final form of the "guile plugin"? will it be compatible
w/ this scheme? if not, what help will you provide to keep me from
cursing your name and switching to SCM+SLIB+Hobbit? etc.
if you want to dissuade discerning people from characterizing your work
as "throwing it against a wall to see if it sticks", you have to answer
these kinds of questions (by asking them of yourself, or finding some
unpleasant person to ask them for you ;-). which means you have to know
how your current scheme relates to its final form. which means you have
to design for the long term. this is not easy to do, granted.
the general principle applicable here is (once again) encapsulation.
some of these annoying questions can be rendered moot (you could be free
to encode favorite color and zodiac sign in the name, why not?) if the
shared objects need not live in a public dir. other questions (like how
you help ford incompatibilites) are always in play.
thi