Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try to connect on EADDRNOTAVAIL #3

Closed
wants to merge 4 commits into from
Closed

Try to connect on EADDRNOTAVAIL #3

wants to merge 4 commits into from

Conversation

oleics
Copy link
Contributor

@oleics oleics commented Mar 19, 2012

This lets a slave-hook connect to an distant server and react on incomming events, eg emit back to master.

I hope you understand the purpose of this. If not, I can give some code to show details.

@oleics oleics closed this Mar 20, 2012
@sergeyksv
Copy link
Owner

Original hook.io has hook.connect and hook.listen methods to partially address this issue. So if you know that you want to be a slave you can directly use hook.connect instead of hook.start. Do you think its worth to reimplement this?

@oleics
Copy link
Contributor Author

oleics commented Mar 20, 2012

To be able to connect to hosts on other machines is one minimum functionality i am expecting from such a library. And as one python mantra says "explicit is better than implicit", exposing .listen and .connect is the way to do it.

There should be no impact on performance, so yes, for me it is worth to reimplement this.

@oleics
Copy link
Contributor Author

oleics commented Mar 20, 2012

Have a look at this: https://github.com/oleics/tinyhook/blob/prototype-rewrite/hook.js

Had no time to run the tests, so there might be little bugs. Background is this issue and that I think it is better to use Object.prototype in terms of memory consumtion. Object.prototype might also improve overall performance, but I am not sure on that.

And it gets rid of the underscore dependency.

@sergeyksv
Copy link
Owner

Well, I have no any significant objections about object.prototype to define objects, this is kind of style issue for me. Methods inside class functions allows to have kind of "private" variables and methods which are not visible to inherited classes so less chances to damage parent class logic by defining properties with same name. As a drawback this has kind of performace penalties that introduced during object creation. I.e. if you instance thousands of hooks and code size is much bigger than we have now then this can be a problem.

@oleics
Copy link
Contributor Author

oleics commented Mar 20, 2012

I think the author of the extending class has the responsibility not to damage parent class logic. This is also some kind of an old python mantra - and it works. Why give up on performance to protect "stupid" authors from themselves? Set them free, let them do errors and let them create instances with maximum speed and minimum memory consumption :-)

@sergeyksv
Copy link
Owner

Ok. I picked up your branch, fix it to make test passing and merge into master. We will test it more later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants