Soup Up the PubSub? about p2.js

[schteppe]

Hi,
While I think your code is nice, I'm not sure if it is necessary to have it in p2.js. It is already possible to subscribe the same handler to different event types. It is also already possible to control the order of the handlers (if there are more than one). What else will it add other than the .one() mechanism and a nicer API? I'm trying to keep the code base size as small as possible.

I think I found your 30% slowdown btw... Here you create a new Object() for each emit. If you have 10^6 emitted events per frame in 60Hz, you will allocate 24_10^6_60 bytes/s = 1440 megabytes per second (!?). It would probably be nicer if you could reuse this 24 byte event object for each emit.

(btw, I'm not 100% sure that the plain javascript object weighs 24 bytes, it might be some other number)

[wellcaffeinated]

actually the slowdown is caused by something else. i tried a copy/paste of your emit method and it had no difference. I think it's a combination of things.

But i think you're right, it would be better to reuse the same object :)

I can understand your wanting to keep the codebase small.

The major benefits are...

// event data having the "handler" and "type" reference so that one can do things like this:
ps.on( 'type', function( e ){
    // since i'm using a reverse while() loop, removing a listener won't interfere with the rest of the callbacks
    if ( something ) ps.off( e.type, e.handler );
});

// multiple events in one shot (works with .off() too)
ps.on({
    'type1': function( e ) {
        // handle
    },
    'type2': function( e ) {
        // ...
    }
    // ...
});

// bind to different "this"
ps.on( 'type', function( e ){
    this === scope; // true
}, scope);

// remove all events bound to "type"
ps.off( 'type', true );

// remove all events
ps.off( true );


// priority management
ps.on( 'type', function( e ){
    // runs last
}, 1 );
ps.on( 'type', function( e ){
   // runs first, no matter where/when this .on() is called
}, 100);

[schteppe]

I have thought some about this and I think that it's not necessary for a library focusing on lightweight and physics. I searched for other physics engines implementing these patterns and found nothing. If you know a physics engine other than PhysicsJS implementing this, please point me to that...

Anyway, all these mechanisms can be implemented in the (game) application layer if they are needed. Better keep the physics library as small and maintainable as possible.

[wellcaffeinated]

sounds good

[schteppe]

Yeah, sorry, but that's what I think right now. Thanks for the offer though!