[DGD]EPP 2.0

[Jason Cone]

----- Original Message -----
From: "Felix A. Croes" <felix at dworkin.nl>


> "Jason Cone" <jcone at uscdev.com> wrote:
>
> > From: "Ludger Merkens" <balduin at uni-paderborn.de>
> >
> >
> > > [...]
> > > development) and where performance matters. A bridge to call
c-functions
> > > from lpc would help alot. Writing kfuns for this purpose is possible,
but
> > > I don't like to populate the driver with lots of functions because I
think
> > > that would be bad design.
> >
> > I would have to agree here.  I, too, would like to see this as it
negates
> > having to distribute custom driver sources for use with specific libs
(if
> > made publically available).
>
> This comes up every now and then.  I am not sure if it is simply too
> difficult to add kfuns -- perhaps I should write a doc? -- or if there
> really is a good reason for linking to C code in another way.

Well, no matter the end result of this discussion, adding a fairly detailed
document on how to extend the driver is a _great_ idea.

> If the latter, I have never seen this convincingly argued.  Therefore
> I invite you, and anyone who agrees with you, to come up with good
> arguments.  Don't just tell me what is bad about the kfun interface,
> also mention how it should be.

The aforementioned scenario of having to distribute a customized driver
source tree along with a lib that uses specialized functionality in the
driver is a great reason to introduce run-time external function binding.
Given that fact that there are already numerous oft-used package extensions
out there, though, I can see how this scenario can be dismissed.

To further explain, though, LPC is great so long as you're content to settle
for the advantages and limitations that come from LPC and LPC alone.  To me,
both Apache and Perl got it right when they started using dynamic extension
modules in their language/program.  They recognized the fact that the
functionality that was originally created was not designed to be extendable
enough so as to allow for the solution of real-world problems.  In order to
do so, you have to allow the end-user to extend the language/environment in
such a way that it doesn't mandate a total rebuild of the foundation in
order to accomodate their approach.  In your case, even if/when you figure
out how to extend the kfun set, you have to totally rebuild the program.  An
_excellent_ starting point would be to add the ability to bind modules at
run time that can register new kfuns without the need to recompile the
program.  This creates a robust platform with which the ideas that have been
presented of late (encryption, compression, XML, Unicode, native OS API
calls, etc.) can be distributed and used with the greatest of ease.

I'm not an advocate of creating a pure "inside-to-outside" bridge (a la, a
single kfun to call any external function -- there are too many OS-specific
issues to deal with there), but rather the ability to extend DGD at
run-time.

I haven't given this much thought, so I don't have specific
suggestions/solutions for you at this time.  I would encourage you, though,
to seeks ways that would allow DGD to adapt to the general case be it via
the kfun implementation document (better than present) or a revised approach
to the extension of DGD's core functionality (ideal solution).

Jason



List config page:  http://list.imaginary.com/mailman/listinfo/dgd