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

2008-10-15:

[8:49] <zumbrunn> http://blog.ryanpeterson.net/posts/the-most-underrated-javascript-framework-ever
[9:12] <hannesw> nice :-)
[9:28] * zumbrunn currently isn't sure he can go on living without any kind of meta method/property support
[9:29] * zumbrunn therefor hopes hannesw has something up his sleeves he hasn't communicated yet
[9:31] <hannesw> :-) getters and setters don't cut it?
[9:32] <hannesw> where do you need it most urgently? If you give me some example, I may find a good solution
[9:33] <zumbrunn> getters and setters can't handle properties with unknown key names, right?
[9:34] <zumbrunn> or is there some trick that makes this possible now?
[9:41] <zumbrunn> if I understand it correctly, the proposed Object.defineProperties would cover the meta-method support as well
[9:43] <zumbrunn> or maybe not
[9:43] <hannesw> nope, defineProperty is just to define properties with custom attributes (readonly, dontenum)
[9:44] <hannesw> in fact it is impossible to use defineProperty with getters and setters
[9:44] <hannesw> which is why definePropertyAttributes() is required, I guess:
[9:44] <hannesw> first define getter/setter, then set attributes on it
[9:45] <hannesw> currently when you do "delete foo.bar" and foo.bar is defined by getter/setter, you delete the getter/setter.
[9:45] <hannesw> which is kind of awkward.
[9:46] <hannesw> bottomline: I didn't remove metamethods because I'm evil, just because I think it's worth trying to do without... but if there is a real need, we'll find something
[9:47] <zumbrunn> in addition to writable, enumerable and configurable, the Object.defineProperties proposal also allows for setter, getter and value to be specified
[9:48] <zumbrunn> and value can be a function
[9:50] <zumbrunn> somehow it seems like the right place to add meta support would be as part of that proposal
[9:52] <zumbrunn> the reason why you removed it, though, was because you discovered performance problems, right?
[10:19] <zumbrunn> I just looked through the current spec draft and the rational doc again
[10:20] <zumbrunn> Object.definePropertyAttributes isn't in the draft spec, actually
[10:20] <zumbrunn> it's just mentioned in the rational doc, along with all the other bits that were discussed before arriving at the current spec
[10:22] <zumbrunn> anyway, I didn't spot anything regarding meta method/property support
[10:26] <zumbrunn> if any approach to implementing something like this will remain non-standard, we might as well go for the most elegant one
[10:27] <zumbrunn> and the most elegant one by far was the one you had implemented last
[10:28] <zumbrunn> but, if I interpreted your commit messages correctly, you removed it because of performance issues, right? ...not just because you thought you could do without
[10:30] <hannesw> well, performance issues and I didn't like it anymore, and there were some other issues with it
[10:31] <Helma3> warpapps.sf.net
[10:31] <Helma3> sorry, wrong window.
[10:33] <zumbrunn> the fact that it allowed to add meta methods/properties to already pre-existing objects was really nice in that version
[10:33] <zumbrunn> but I wouldn't really *need* that
[10:34] <zumbrunn> even the JSAdapter would give me enough for what I need
[10:34] <zumbrunn> but your alternatives seemed nicer
[10:36] <hannesw> chris, can you give me a concrete example of how and where you would use this?
[10:36] <hannesw> (if you have one)=
[10:37] <hannesw> I would really like to go about this in a need-based manner, if you know what I mean.
[10:37] <_daniel_> when using openjdk1.6 as compiler, helma1 is broken in helma.doc.DocFunction because of some dependency issue regarding rhino.
[10:37] <hannesw> look at the use case, and find the best solution for it
[10:38] <zumbrunn> many places where I would otherwise have to write obj.getFoo('bar')
[10:38] <hannesw> daniel: are you using ubuntu and openjdk?
[10:38] <zumbrunn> and I would prefer obj.foo.bar
[10:38] <_daniel_> yep.
[10:38] <_daniel_> i already switched back to sun-jdk which solves the issue.
[10:39] <hannesw> It's a known bug: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149
[10:39] <hannesw> my solution is to simply delete the js.jar from the rhino package
[10:40] <zumbrunn> hannesw: situations where I don't know whether a property exists before it is accessed
[10:40] <hannesw> sudo rm /usr/share/java/js.jar
[10:40] <hannesw> sudo rm /usr/share/java/js-1.6R7.jar
[10:40] <hannesw> chris: yes, but I'd like to work on concrete, palpable examples
[10:41] <zumbrunn> now you sound like brendan ;-)
[10:41] <_daniel_> understood, thanks hannes.
[10:42] <hannesw> wait, actually the bug report has a better fix:
[10:42] <hannesw> https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/3
[10:43] <hannesw> chris: this is really the right way to go. adding features, especially non-standard features, has lots of consequences over many years.
[10:43] <hannesw> going for lunch, cu later
[10:43] <zumbrunn> yeah, til later
[10:44] <zumbrunn> going walkign with my dogs myself
[12:51] <zumbrunn> hannesw: while I was walking the dogs, I tried to think of the most important case, where wouldn't want to do without meta methods/properties
[12:52] <zumbrunn> one place where I currently use meta properties is when I want objects to be able to inherit properties from their hierarchical parents in addition to their prototype chain
[12:52] <zumbrunn> for example, in a traditional helma app, you might have a path like root/foo/bar
[12:53] <zumbrunn> and bar would inherit its properties from its prototype chain
[12:54] <zumbrunn> I would like to have an object like bar.views.aaa
[12:54] <zumbrunn> which would return a skin called aaa from bar's prototype chain
[12:55] <zumbrunn> but would in addition also check the parent objects foo and root for a skin called aaa
[12:55] <zumbrunn> does that make sense as an example use case?
[12:59] <zumbrunn> in reality it is slightly more complicated, but not in relevant ways, I don't think
[13:00] <zumbrunn> the lookups for the aaa skin in root and foo only look at instance properties and do not inherit from the prototype chains of foo and root
[13:02] <zumbrunn> and in addition to the lookup of the skin, the code would also check whether there is a "controller" for that skin
[13:02] <zumbrunn> and if a controller exists, it would pass the skin to that controller before returning the result
[13:05] <zumbrunn> it's kind of what the Mocha.resolver does here:
[13:05] <zumbrunn> http://code.google.com/p/e4xd/source/browse/trunk/objectengine/Mocha/core.js?r=75
[13:44] <hannesw> just talking with chris langreiter on jabber
[13:44] <hannesw> who is also complaining :-)
[13:44] <zumbrunn> :-)
[13:44] <hannesw> maybe we can bring the feature back in "reduced" form
[13:45] <zumbrunn> "reduced to the max" is good :-)
[13:45] <hannesw> metamethods performance impact I estimate is 10% to 25%
[13:45] <hannesw> even if you don't use the feature
[13:45] <hannesw> in real world usage
[13:45] <zumbrunn> but JSAdapter doesn't have that problem, I assume?
[13:46] <hannesw> in synthetic tests which are just property access it's more like 50%
[13:46] <hannesw> nope, but it's far less useful IMO. It's nice to have this feature on every object...
[13:46] <zumbrunn> yes
[13:47] <hannesw> what I'm planning to do eventually is to do the metamethod thing only after ordinary property lookup, i.e. for properties that aren't otherwise defined
[13:48] <hannesw> and maybe go back to a metaobject like with JOMP
[13:49] <zumbrunn> I don't know how the walking up the prototype chain is done, but that might mean that lots of lookups of undefined properties are very common?
[13:51] <zumbrunn> (since everything that is inherited from the prototype chain would first pass through a lookup on the instance object, before even starting to climb up the chain)
[13:54] <hannesw> well if the lookup is handled in java it's not a problem
[13:54] <hannesw> currently metamethods are kept as javascript properties
[13:55] <hannesw> which is expensive if done 1000 times per second
[13:55] <hannesw> while checking a java field for null is not a problem
[16:15] <_daniel_> hm. is there any requirement to which sql standard a jdbc driver should or needs to be compatible with?
[16:16] <_daniel_> i am currently using a jdbc driver that does not support some of helma1's sql queries. i am trying to find out if it is helma1's fault by issuing non standard queries or the drivers fault by not supporting them.
[16:31] <_daniel_> for one specific query it seems to be helma1's fault. helma issues a "SELECT * FROM table WHERE 1=0" query for getting the metadata of a table. obviousley the resultset for such a query is empty. i've read that some jdbc drivers do not deliver metadata for empty resultsets.
[16:34] <_daniel_> helma tries to get the metadata of a table when fetching node, so helma could assume that the table is not empty and should better issue a "SELECT * FROM table" query with a maxsize limit of 1 for the resultset or by using limit, top, ... if any of it is standard sql compatible.
[16:35] <_daniel_> is there a standard sql compatible way of limiting the number of rows in a resultset?

 

 

In the channel now:

Logs by date: