Comments on: AS3 Property Observer Implementation

By: Max

Max — Sun, 21 Mar 2010 18:07:21 +0000

In my opinion, a full replacement of [Bindable] introduces quite a lot of risk. I think a new bit of custom metadata however ([Observable] perhaps?) would be a welcome addition. Thanks for sharing this great Observer implementation!

By: An Alternative to using PropertyChangeEvent - Jacob Wright – Flex, AIR, PHP, etc.

Wed, 17 Mar 2010 20:47:50 +0000

[...] A post about a trial implementation, and the final [...]

By: karfau

karfau — Sun, 21 Feb 2010 20:04:28 +0000

Just from reading, without having used it:
1) I very much like the idea/ implementation of Observe.
2) I can imagine that there maybe could be a use for the checks, so keep them.
3) I can not imagine anything where I would need/use this.

Both checks and hooks look a bit like aspect-oriented programming to me, which I had no chance to dive into yet and which I am not sure about I more like or fear it.
So as u said:
“With great power comes great responsibility and jazz like that.” Yep, thats the price!

Maybe there is a way to make those things more visible in development, e.g. by the need of implementing a class or using extra metadata or implementing Observe, CheckObserve, HookObserve, CheckHookObserve (or just Check, Hook and Observe that explicitly need to be linked together if needed)… not sure. In a way that it is easier to track the usage of it, and keep this functionality seperate / out if I don’t want to use it.
(No idea if it is possible in a way, that is not making the code that uses it more diffucult to write… )

Just my 2 cents,
Karfau

By: Jacob Wright

Jacob Wright — Wed, 17 Feb 2010 20:59:41 +0000

Max: I agree about release(), but even if you don’t call it your objects will still be garbage collected. release() is a fail-proof mechanism or one you could use for object pools.

Because of this, one problem I still want to tackle is all the checks/hooks/observers are stored in a weak-referenced dictionary, so the order in which they are called is random.

By: Max

Max — Wed, 17 Feb 2010 20:33:18 +0000

Woohoo! I folded your Observable class into an example app I’m building at: http://flexamusements.blogspot.com/2010/02/robotlegs-slightly-less-simple-example.html

I especially like the release() method, which allows one to make about-to-be-destroyed Observable classes available for garbage collection.

By: Paul Taylor

Paul Taylor — Wed, 17 Feb 2010 19:47:16 +0000

“So I have a dilemma and need your feedback. Checks and Hooks could be really cool, allowing you to change stuff at run-time, inserting code into the setter as it were. However, this could also cause headache, security issues, difficult to diagnose bugs, and other potential issues. With great power comes great responsibility and jazz like that.”

I could foresee a scenario where multiple hooks (for formatting or whatever) is malforming the data before its set. I could also foresee a scenario where multiple checks are added to a property incorrectly, and are preventing setting a legitimate value. Both cases should be caught by thorough unit tests, but assuming you don’t have those, maybe releaseChecks|Hooks|Observers(target:IEventDispatcher) methods could be added, just in case?

Overall I think checks and hooks are sweet as they encourage and empower functionality composition. I vote for keeping them and including them in Reflex.

Great ideas Jac!