Ringobot log - RingoJS IRC channel: #ringojs on irc.freenode.net
2010-07-20:
[7:00] <gmosx> hey?[7:39] <zumbrunn> regarding extending core prototypes...
[7:39] <zumbrunn> how about changing the core modules to be callable using a syntax like this:
[7:40] <zumbrunn> require('core/string').extend(String)
[7:42] <hannesw> zumbrunn: that would just make things worse imo
[7:42] <zumbrunn> it would?
[7:42] <hannesw> the problem is that code is extending core prototypes, not how it is doing it
[7:42] <zumbrunn> hmm, ok
[7:43] <hannesw> i also want to get rid of the core/* namespace
[7:43] <hannesw> and use ringo/util/* instead, or something similar
[7:43] <zumbrunn> yes, that's fine
[7:46] <hannesw> well the way i see it is the problem is extending core objects per se
[7:46] * zumbrunn doesn't think that is a problem
[7:46] <zumbrunn> but I agree one can see that differently
[7:47] <hannesw> what do you think is the problem?
[7:47] <zumbrunn> I really don't have a problem with the way we are currently doing it
[7:48] <zumbrunn> the require('core/string').extend(String) syntax would maybe be a better "best practice" for doing that
[7:50] <zumbrunn> (just because it makes clear what's happening)
[7:52] <zumbrunn> that way it is the calling module that extends its core prototypes in its own scope
[7:53] <zumbrunn> and the core/object etc modules do not do any dirty magic behind the scenes
[7:53] <hannesw> zumbrunn, to be clear:
[7:53] <hannesw> i don't have any problem with the current way either
[7:53] <hannesw> it's that people using ringo might have problems
[7:54] <zumbrunn> yep
[7:54] <hannesw> and the fact that we're using these extensions in our own ringo/* modules
[7:54] <hannesw> so you cannot not use them
[7:54] <hannesw> that's the problem we need to solve
[7:54] <zumbrunn> yes, I see
[7:55] <hannesw> and the only thing we can do is not touch core objects at all
[8:01] <zumbrunn> regarding a new implementation of skins...
[8:01] <zumbrunn> is it out of question to leverage e4x for that?
[8:03] <zumbrunn> (it may be considered to be limiting, but it would not be to limiting for me)
[8:04] <zumbrunn> (it may be considered to be *to* limiting, but it would not be to limiting for me)
[8:06] <gmosx> how about using
[8:07] <gmosx> var method = require("core/string").method ?
[8:07] <gmosx> ie, just require the functions you like (use functions, not methods)
[8:08] <gmosx> functions are better (faster dispatch, can check for null values, easier to optimize with closure compiler)
[8:10] <hannesw> gmosx yes, that's what I'm planning to do
[8:10] <gmosx> nice...
[8:10] <gmosx> and ringo/util is better...
[8:11] <gmosx> ...than core/*
[8:11] <gmosx> should I add String.unescapeHTML and Object.update to core/* to get rid of narwhal/html and narwhal/hash?
[8:12] <hannesw> yes, but core/* is a moving target now...
[8:13] <gmosx> I know... but let's add them so I can drop the narwhal dependency, and I can change this afterwards...
[8:13] <hannesw> ok
[8:13] <gmosx> unless you plan to work on core/* immediatelly
[8:13] <hannesw> no
[8:13] <gmosx> in this case, I can wait...
[8:13] <gmosx> perhaps I could introduce ringo/utils/string.js and add unescapeHTML there...
[8:14] <gmosx> and we can move the rest from core/string.js afterwards...
[8:14] <gmosx> what do you think?
[8:14] <hannesw> well that move will be quite pervasive
[8:14] <hannesw> lots of files touched
[8:14] <gmosx> we can have ringo/utils/string.js in paralel...
[8:15] <gmosx> we can use it for new code, deprecate core/string.js but still keep it until we update all the code...
[8:15] <hannesw> I'd prefer to have a single clear trasfer
[8:15] <hannesw> transfer
[8:16] <gmosx> OK, I think moving core/* should have a high priority though
[8:16] <hannesw> btw, gmosx your github fork has two commits that are obsolete, you might as well push --force a clean copy
[8:17] <gmosx> git push --force origin master ?
[8:17] <hannesw> that would make merging from your fork easier
[8:18] <gmosx> hannesw: it only says Everything up-to-date
[8:18] <hannesw> well you have two commits in there that are obsolete or already merged:
[8:19] <hannesw> http://github.com/ringo/ringojs/forkqueue
[8:19] <gmosx> dunno how to remove them :(
[8:19] <hannesw> maybe earl could help
[8:19] <gmosx> earl: ??
[8:21] <hannesw> well it's not a big problem
[8:21] <gmosx> OK...
[8:22] <gmosx> Another thing...
[8:22] <gmosx> I think you should release new versions of Ringo more often...
[8:23] <gmosx> for example once per month...
[8:23] <gmosx> it's ok to have less new features per version...
[8:23] <gmosx> have a look at NodeJs, they release a new version, every 2 commits ;-) :-D
[8:24] <gmosx> Another feature request...
[8:24] <hannesw> gmosx yes, possibly
[8:24] <gmosx> hannesw: Can you please, please merge the slf4 jars into ringo.jar (or even better remove the dependency altogether?)
[8:29] <hannesw> gmosx you could make your own build script to merge the jars
[8:29] <hannesw> we may use that in ringo for appengine-like deployments
[8:29] <gmosx> any example how this is done?
[8:29] <gmosx> I have limited experience with ant, etc :(
[8:30] <hannesw> i don't know, but there's good documentation available:
[8:30] <hannesw> http://ant.apache.org/manual/index.html
[8:30] <hannesw> http://ant.apache.org/manual/Tasks/jar.html
[8:31] <hannesw> we may add an ant task like jar-complete
[8:31] <hannesw> or whatever
[8:31] <hannesw> regarding removing the dependency:
[8:31] <hannesw> then we'd have to settle for one logging system, like log4j or java.util.logging
[8:32] <hannesw> and everything other than the latter wouldn't work on appengine
[8:32] <gmosx> i think appengine supports log4j
[8:33] <gmosx> no Appengine supports BOTH log4j and java.util.logging
[8:33] <gmosx> slf4j is not really needed...
[8:34] <gmosx> and it makes this examples more complex for new users...
[8:34] <gmosx> (I got a question regarding the many jars in the aejs group)
[8:34] <hannesw> log4j does not really work
[8:34] <gmosx> we should make ringo and aejs less intimidating for new users?
[8:35] <hannesw> if you log to stdout or stderr it will end up in the log, but that's not really logging
[8:36] <hannesw> ok, so let's make a jar-complete ant task
[8:39] <gmosx> http://code.google.com/appengine/docs/java/runtime.html#Logging
[8:39] <gmosx> jar-complete RULEZ ;-)
[8:39] <gmosx> thanks
[8:39] <gmosx> you are right, seems to support only java.util.logging...
[8:40] <gmosx> I think RingoJS should only support this by default to be lightweight...
[8:40] <gmosx> if the developer needs log4j he can add this...
[8:40] <gmosx> what do you think? ;-)
[8:40] <hannesw> yes, that's an option
[8:41] <gmosx> I vote for simplicity ;-)
[9:43] <gmosx> hannesw: btw, check this out: http://news.ycombinator.com/item?id=1531583
[9:43] <gmosx> it rocks ;-)
[15:04] <emilis_info> I need to check if new files have been added to a directory. What would you propose?
[15:05] <emilis_info> I would compare arrays from fs.list() but there is no Array.diff...
[15:14] <mcepl> write one? ;)
[15:15] <emilis_info> or not to write one ;-)
[15:15] <daian> that is the question
