«

Hi,

I have a general JavaScript library API design question based on some
examples I have seen. There seem to be two options

The first option is used by the AJAX libraries and by Matt Kruse's AJAX
library. These seem like functional programming.

YAHOO.util.connect.asyncRequest('GET', '/the/url',
{success:function(o){alert(responseText)};});
AjaxRequest.get({'url':'/the/url','onSuccess':function(req){
alert(req.responseText);}});

The other option is more OOP and is used by prototype.js for the AJAX
part. This would allow for a more layered library design with
increasing complexity. Perhaps a form request class inheriting from a
non-form request class. I can imagine things like

var request = new Ajax.request('GET', '/the/url',
{success:function(o){alert(responseText)};});
if (request.inProgress()) {}
/* I suppose the request object isn't eligible for garbage collection
even after the request is completed */

-------

Similarly the Yahoo! UI event library uses functional programming like
the following.

function handler(e){alert('event!');}
YAHOO.util.event.addListener('element_id', 'mouseup', handler);
YAHOO.util.event.removeListener('element_id', 'mouseup', handler);

For an event library I can imagine a more OOP style that allows

function handler(e){alert('event!');}
var listener = new Listener('element_id', 'mouseup', handler);
listener.suspend();
listener.resume();
listener.remove();
/* I suppose the listener object isn't eligible for garbage collection
here */

Any words of wisdom or cautions about using the OOP style? It seems
like Yahoo! has gone with the functional style in most cases and this
causes a bit of a mess to keep track of all the different concurent
listeners and requests.

Thank you,
Peter

wrote:
> I have a general JavaScript library API design question
> based on some examples I have seen. There seem to be two
> options
>
> ... . These seem like functional programming.
<snip>
> The other option is more OOP ...
<snip>
> Any words of wisdom or cautions about using the OOP style?
> It seems like Yahoo! has gone with the functional style in
> most cases and this causes a bit of a mess to keep track of
> all the different concurent listeners and requests.

Recently we have seen a link to a definition of "to beg the question". If
someone asks the question "When making an automobile gearbox out of
cheese; is it better to cook the cheese firs or just to leave it to dry
out?" the answer is not one of the two choices offered but rather to
question the rational of making a gearbox out of cheese.

Objects are encapsulations of state and behaviour, usually modelling a
concept. Functions are things that 'act', usually on parameters.
Generally the application would dictate the strategy. If you are working
with concepts that can be modelled as state and behaviour then objects
would be the obvious choice, while a desire to act suggests a function.
With the situation slightly muddied by javascript being a functional
language where functions are actually objects and may be used to
implement 'class' instances.

Rather than letting yourself be directed by someone's opinion of how to
implement things in javascript (to the exclusion of all else) I would
recommend spending some time trying the alternatives out and seeing what
issues follow from them for yourself. To be honest I don't think anyone
starting to learn javascript is going to produce anything worthwhile
without at least 6 months of fairly intensive trial and error experience
(preferably with critical feed-back), and anything published prior to
that is likely to do more harm than good.

Richard.