{"comment":{"created_at":"2011-10-20T19:27:54Z","body":"I can see an argument for not allowing namespacing of plugins in raphael core using the original method from 1.4.7. Having code just go through and do binds on all the functions in a given namespace so that they execute in the context of the paper instance just seems to sidestep the problem without actually solving it. If an implementing library wanted to namespace itself, it could use that method to do so, but I feel like that method is too dirty to be a part of raphael core (I'm guessing that this is the reason it was removed from 2.0 based on DmitryBaranovskiy's comment above)\r\n\r\nWith that, I can also see how gRaphael can be refactored to not use namespaces, similar to how DmitryBaranovskiy removed the primatives from gRaphael and put them in as a plugin in the main raphael repo so it's not paper.g.flower, it's just paper.flower\r\n\r\nThe g namespace is pretty clobbered and messy. If the idea is simply not allowing namespaced plugins in raphael (in which case, I recommend updating the documentation, because it still says that you can), then I will gladly clean up the library to make it use closures to manage the code, rather than just keys on the g object, and then simply have the main gRaphael functions live on the fn object (the paper prototype) so you would just do paper.barchart() instead of paper.g.barchart(). \r\n\r\nIn my opinion, this is the best of both worlds. Adding a 'me' property to the gRaphael lib does nothing but duct tape a fix together and further add more properties to that g namespace that really could be cleaned up instead.\r\n\r\nI think this is a great opportunity to do with gRaphael what DmitryBaranovskiy did with raphael core 2.0: a significant overhaul of the codebase itself, rather than a few patch fixes here and there.","updated_at":"2011-10-20T19:27:54Z","url":"https://api.github.com/repos/DmitryBaranovskiy/raphael/issues/comments/2473209","id":2473209,"user":{"avatar_url":"https://secure.gravatar.com/avatar/fad5ce9e4a9c756abe504ded667b6cd1?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"fad5ce9e4a9c756abe504ded667b6cd1","url":"https://api.github.com/users/rzurad","id":418224,"login":"rzurad"}},"action":"created","issue":{"number":424,"created_at":"2011-10-19T21:58:57Z","pull_request":{"diff_url":"https://github.com/DmitryBaranovskiy/raphael/pull/424.diff","patch_url":"https://github.com/DmitryBaranovskiy/raphael/pull/424.patch","html_url":"https://github.com/DmitryBaranovskiy/raphael/pull/424"},"body":"I don't know why you removed this code from Raphael (I'm still new to this very useful library), but after putting it back (with some adjustments), it makes g.Raphael to work.\r\n\r\nAnd Raphael seems to work too, as far as I tested.\r\n\r\nIntegration tests are not passing, but they're not passing with the 2.0 release either, so I guess I did not break anything here.","comments":5,"title":"With these commits, g.Raphael is working","updated_at":"2011-10-20T19:27:54Z","url":"https://api.github.com/repos/DmitryBaranovskiy/raphael/issues/424","id":1999115,"assignee":null,"milestone":null,"closed_at":"2011-10-19T23:19:43Z","user":{"avatar_url":"https://secure.gravatar.com/avatar/e815e852e96b7d5fabe001cdd9c78ba3?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"e815e852e96b7d5fabe001cdd9c78ba3","url":"https://api.github.com/users/ghusse","id":527245,"login":"ghusse"},"html_url":"https://github.com/DmitryBaranovskiy/raphael/issues/424","labels":[],"state":"closed"},"legacy":{"issue_id":1999115,"comment_id":2473209}}