Hopbot log for 2007-07-25 - Helma IRC channel: #helma on irc.freenode.net

2007-07-25:

[5:05] <jakehow> jsp: it works when i removed my seperate rhino install
[5:13] <jsp> that's good news.
[5:13] <jsp> it may be a helma bug that it didn't use its bundled version even with yours around
[5:26] <jakehow> jsp: well to install it i put it in java/extensions and that might be before helmas version in the loading hierarchy
[5:36] <jsp> hrm, yeah. that makes sense
[10:49] <zumbrunn> a tutorial for a mini-blog, written by Fabian (but it's in German):
[10:49] <zumbrunn> http://www.fabianbartsch.net/?p=16
[17:17] <rjb> root.get(13) and root.get("13") return quite different results
[17:17] <rjb> talk about confusing
[17:19] <jsp> yeah. seems like a misfeature. get(13) gets the thirteenth child of root, get("13") gets the HopObject with _id==13
[17:21] <rjb> unless you got it the other way around
[17:21] <rjb> (which i believe to be the case)
[17:21] <jsp> I didn't
[17:21] <jsp> hmmm
[17:22] <rjb> ok i'll check with the shell
[17:22] <jsp> http://helma.zumbrunn.net/reference/core/HopObject.html#get
[17:22] <rjb> as soon as i get some coffee
[17:22] <jsp> documentation says what I said. so I hope the shell does, too
[17:22] <jsp> the reason for it is:
[17:28] <jsp> /myobject/whatever has to get the child of myobject with the name "whatever"--fine. but some _children collections are not mapped by name, so logically you'd expect /myobject/12 to get the 12th child of whatever. But the ordering of the children is something known only to the parent, so the child's .href() method can't tell you that it's the twelfth child, so the mapping of children by number has to be done on some property known to
[17:30] <rjb> yeah seems you're right and i'm the more confused one
[17:30] <jsp> note: I'm not saying that was the right decision, but that's how it ended up that way, I think
[17:30] <rjb> point is it's very un-javascripty
[17:30] <rjb> to make a function work differently
[17:31] <rjb> depending on whether the arg is a number passed as string, or as int
[17:32] <jsp> yeah, except in the sense that javascript is also broken in that way elsewhere b/c of overloading + for concatenation. I think the problem came from the apparent necessity of get()ing children through the same function whether they had names or not
[17:33] <jsp> it would be better if get() were named something that made it more obvious it was for url mapping and there was a separate getChild() function. It wouldn't be hard, incidentally, to make it so, since you can overload any function you like.
[18:03] <rjb> somehow the overloaded + doesn't bother me at all
[18:05] <jsp> leads to errors all the time when dealing with user data, e.g., a form field with value '85':
[18:05] <jsp> if(field.value < 1000) field.value+=100;
[18:05] <jsp> yields field.value=='85100'
[18:07] <rjb> the issue here is type coertion rather than operator overloading
[18:09] <jsp> yes, yes. I agree .get() is confusing. I'm just saying they're really the same issue b/c a+100 yields different things depending whether a=85 or a='85'
[18:12] <rjb> not really that surprising - you're adding 100 to a different object in each case
[18:13] <rjb> it's not a good excuse for forgetting to call parsInt() ;-)
[18:13] <rjb> parseInt() even
[18:14] <jsp> heh. that's easy to turn around: you're passing two different objects to obj.get()--why would you expect to get the same result?
[18:15] <rjb> good point. because i sort of expect js to do type coertion?
[18:18] <jsp> incidentally, I use 1*a rather than parseInt(a). it's shorter and does the obvious thing in more cases
[18:21] <jsp> i.e., you have to explicitly pass the base to parseInt to get predictable results, e.g., parseInt(a,10). If I actually want to get an int from a string representing another base, then parseInt is the way to go.
[18:23] <jsp> cents = parseInt('99.09'.split('.')[1]);
[18:23] <jsp> but now cents==0, not 9 !!

 

 

In the channel now:

Logs by date: