Hopbot log for 2008-10-13 - Helma IRC channel: #helma on irc.freenode.net

2008-10-13:

[9:32] <hannesw> So what are the preferences out there regarding regular expression based url resolving vs. an object graph/name convention based scheme?
[9:33] <hannesw> I just checked out cherrypy last week, and it's probably the closest to Helma 1 in terms of url resolving you can get.
[9:34] <hannesw> I do think the _action based convention had some merits, or something like setting a "action" or "exposed" flag on functions...
[9:35] <hannesw> But something I don't want anymore is resolving url paths by object references. That just mixes up things that shouldn't be mixed.
[9:35] <hannesw> Any comments?
[9:37] <zumbrunn> I like the object graph/name approach for much of what I do
[9:37] <zumbrunn> but over all, I agree the regular expression based url resolving offers a better foundation
[9:38] <zumbrunn> the object graph based behavior can always be added on top of that
[9:39] <zumbrunn> the two approaches aren't mutually exclusive, in by opinion
[9:40] <hannesw> no, they're not.
[9:40] <zumbrunn> in other words, +1 for using regular expression based url resolving as the default way of going about that
[9:41] <hannesw> IMO the object graph approach is viable if we also add some explicit expose mechanism.
[9:41] <hannesw> similar to explicit __export__, maybe:
[9:41] <hannesw> __expose__ = ["index", "list", "someSubModule"]
[9:41] <hannesw> ?
[9:44] <zumbrunn> yes, something like that would be nice
[9:44] <zumbrunn> but even if it needs to be custom coded whenever an object graph based approach is needed, that would be fine
[9:47] <zumbrunn> btw, regarding the dropping of Object.dontEnum.... it probably will not make sense for __defineProperty__ to actually make its way into Rhino either
[9:48] <zumbrunn> since there are now other proposals for ES3.1 that have been discussed in a lot of details
[9:49] <zumbrunn> Object.defineProperty and Object.defineProperties
[9:49] <zumbrunn> and some other methods, I believe
[9:50] <zumbrunn> (they do not work exactly like __defineProperty__ does now)
[9:50] * zumbrunn looking for where that was discussed...
[9:52] <zumbrunn> http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:rationale_for_es3_1_static_object_methodsaug26.pdf
[9:54] <zumbrunn> If I remember correctly, the way it is specified there is now pretty much agreed between the various ecmascript stack holders
[9:58] <zumbrunn> apparently, the 9/22 draft even contains "specs" for it:
[9:58] <zumbrunn> http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:tc39-es31-draft22sep08.pdf
[10:00] <zumbrunn> (there is nothing wrong with having __defineProperty__ as a dontEnum replacement in helma for now... I'm just saying, it probably doesn't make sense to push for it going into Rhino)
[10:02] <hannesw> thanks for that info, chris
[10:03] <zumbrunn> regarding __expose__.... how would the "someSubModule" part work? not sure what you meant with that
[10:03] <zumbrunn> "someSubModule" would be the name of a module that would handle the request somehow?
[10:03] <hannesw> that would be the name of a imported module that is also exposed
[10:04] <zumbrunn> what inside the module would be exposed?
[10:04] <hannesw> yep, for a request /someSubModule/index the lookup would then proceed to look for "index" in someSubModule
[10:04] <hannesw> basic delegation
[10:04] <zumbrunn> I'm confused because it doesn't resolve to a function
[10:04] <zumbrunn> ok, I see
[10:06] <zumbrunn> that's kind of cool, actually :-)
[10:06] <hannesw> yep
[10:08] <hannesw> ok, the defineProperty() proposal is actually very similar to what we have, except the flags are packed into a {writable: ..., enumerable: ...} descriptor
[10:09] <hannesw> off for lunch...

 

 

In the channel now:

Logs by date: