Tobie,
If that's so, then we should explictly forbid memo not being an object,
shoudln't we? Or at least make this crystal-clear in the docs. The
current docs only state "memo: metadata for the event."
Otherwise, you can pull my commit b1bfdd5, fresh off the current main
master :-)
Le 26/03/2010 12:30, Tobie Langel a écrit :
The reason for this design choice was to avoid the following
altogether:
if (event.memo) {
foo = event.memo.foo;
}
and allow this instead:
foo = event.memo.foo;
There are memory costs involved with this design choice, but these can
easily be mitigated by passing in a value to the second argument of
Event.fire.
The contract this API tries to make is to systematically return an
object.
I think we should respect that.
Best,
Tobie
On Mar 26, 9:50 am, Christophe Porteneuve<t...@tddsworld.com> wrote:
Hey C dric,
Hmmm, I'd have to double-check the codebase for justification of this
defaults, but even if it turns out to be useful, the implementation
seems clearly faulty. It should go something like:
event.memo = (undefined === memo ? {} : memo);
Thanks for the heads up.
--
Christophe Porteneuve aka TDD
t...@tddsworld.com
--
Christophe Porteneuve aka TDD
t...@tddsworld.com
--
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
To unsubscribe from this group, send email to prototype-core+unsubscribegooglegroups.com
or reply to this email with the words "REMOVE ME" as the subject.
