Bugzilla – Bug 647
Support __defineGetter__ and __defineSetter__ for HopObjects
Last modified: 2008-11-05 16:36:56
You need to log in before you can comment on or make changes to this bug.
As Walter Krivanek pointed out on the Helma-user mailing list already, __defineGetter__ and __defineSetter__ do currently not work for HopObject properties. Here a simple fix to make this to work. I am curious to hear if this might be considered clean enough for inclusion in Helma 1.6.3 or later.
Created an attachment (id=100) [details] The patch to add support for __defineGetter__ and __defineSetter__ to HopObjects
The one thing that disturbs me about this patch is the implementation of delete(). If the property is defined via ScriptableObject slot, the ScriptableObject slot is deleted, but the Node property is left untouched. That's not what delete() should do IMO. IIRC remember you said via IRC you needed this behaviour for your special purposes, but I think it's somewhat questionable to twist ECMA functionality according to personal needs. Is it ok with you to actually delete the property in delete()?
I completely agree and I am fine with your proposed change. In fact I do not need __define[GS]etter__ functionality any longer on HopObject instances, only on HopObject prototype objects, so maybe we could consider not applying this patch at all. After all, HopObjects also dont support dontEnum, setAttribute, and other things like that for db fields right now.
Created an attachment (id=103) [details] revised patch Make delete() actually delete the property, plus add an explanatory comment.
Is it necessary to check if the node has a property before unsetting it? I am sure that for super it is not needed, and only slows things down. So it is safe to just call super.delete. Maybe it could be as simple as: node.unset(name); super.delete(name);
Created an attachment (id=104) [details] revised patch I guess you are right. New patch version with simplified delete()
I committed the last patch.