From: David Bruant bruan...@gmail.com
Subject: Event properties on objects, a proxy experiment
Date: October 12, 2011 15:38:02 GMT+02:00
To: es-discuss es-discuss@mozilla.org
[…]
So I wondered what if events were part of an object and exposed as such?.
What if an object, instead
Le 16/10/2011 22:16, Axel Rauschmayer a écrit :
*From: *David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
*Subject: **Event properties on objects, a proxy experiment*
*Date: *October 12, 2011 15:38:02 GMT+02:00
*To: *es-discuss es-discuss@mozilla.org mailto:es-discuss@mozilla.org
Thinking of events as methods helps greatly with understanding them.
I really think events as something different than methods, no a particular
sort of methods. fire as [[Call]] is a convenience rather than considering
the event as a method.
But what does “firing an event” really mean? If
something like this ? ...
(function () {
function dispatch(callback) {
callback.call(this.r, this.e);
}
function add(callback) {
this.handlers.indexOf(callback) 0
this.handlers.push(callback);
}
function remove(callback) {
var i = this.handlers.indexOf(callback);
-1 i
Le 15/10/2011 18:26, Andrea Giammarchi a écrit :
something like this ? ...
My email client says that you're responding to my initial message, but
you may as well be responding to my concern about |this| binding.
I'll assume the former.
(...)
gisted already: https://gist.github.com/1289809
naaa, event is just a placeholder ... most likely is gonna be
var event = @__event__ + Math.random();
and most likely that code should be on top with all other native prototypes
shims or improvements.
the correct this is bound as expected, the click function will have this ===
object indeed
Le 15/10/2011 19:52, Andrea Giammarchi a écrit :
naaa, event is just a placeholder ... most likely is gonna be
var event = @__event__ + Math.random();
Or rather a private name (when this is implemented)?
Or with some WeakMap trickeries?
and most likely that code should be on top with all
I meant that IE alert case indeed ... but yeah, you wrote better examples.
Nothing block me to create a function and remove some magic to the on
getter so that I can set directly the proxy there.
In few words mine was a proof of concept on how we could do it and how to
bring the right this
I love it!
With some minor nits. I feel like [[Call]] should map to dispatch/fire.
And with some sugar on top to sweeten the deal.
var obj = {
onfoo: event(a, b, c) { ... }
};
// addListener
obj.onfoo.add(function(a, b, c) {
assertEquals(this, obj);
...
});
// Syntactic sugar for add
On Fri, Oct 14, 2011 at 13:49, Erik Arvidsson erik.arvids...@gmail.com wrote:
var obj = {
onfoo: event(a, b, c) { ... }
};
I guess I was too lazy here. The idea, which is not very baked was to
allow a body here as a default action.
Still I like where this is going and we (me and Alex Russel
Le 14/10/2011 22:49, Erik Arvidsson a écrit :
I love it!
I'm glad to create such a reaction :-)
With some minor nits. I feel like [[Call]] should map to dispatch/fire.
Not only do I like this idea, but it may solve a problem I had regarding
|this| binding with inherited events.
in
On Fri, Oct 14, 2011 at 16:09, David Bruant bruan...@gmail.com wrote:
By the way, do anyone know how the binding with 'elem' is made? Is it
before or after the compilation? Because maybe I miss something, but by
the time you reach add, you have lost both elem and on
Dart only has lexical this.
Le 15/10/2011 01:09, David Bruant a écrit :
(...)
I'll try to find some time to implement the fire as [[Call]] this week-end.
Well, actually, it took me a couple of minutes to implement the things
you mentionned (fire as [[Call]] and a default behavior):
Hi,
I have started a little experiment and I'd like to share it here.
_Context_
We've been taught that objects are attributes and methods.
Consequently, object clients can inspect attributes (though these are
most often private, but there can be constants) and actively call methods.
However,
On Wed, Oct 12, 2011 at 6:38 AM, David Bruant bruan...@gmail.com wrote:
Hi,
I have started a little experiment and I'd like to share it here.
_Context_
We've been taught that objects are attributes and methods. Consequently,
object clients can inspect attributes (though these are most
On Oct 12, 2011, at 6:38 AM, David Bruant wrote:
Hi,
...
So I wondered what if events were part of an object and exposed as such?.
What if an object, instead of being attributes+methods was
attributes+methods+events?
(as I learned later having that thought, what I'm describing is
Le 12/10/2011 16:42, John J Barton a écrit :
Rather than properties, how about modeling events with promises or await?
Could you describe what you mean and add some code of how it would look
like?
One of the problems I want to solve is to have events as first-class
constructs of objects in
On Wed, Oct 12, 2011 at 10:42 AM, John J Barton johnjbar...@johnjbarton.com
wrote:
On Wed, Oct 12, 2011 at 6:38 AM, David Bruant bruan...@gmail.com wrote:
Hi,
I have started a little experiment and I'd like to share it here.
_Context_
We've been taught that objects are attributes and
On Wed, Oct 12, 2011 at 9:38 AM, David Bruant bruan...@gmail.com wrote:
Hi,
I have started a little experiment and I'd like to share it here.
_Context_
We've been taught that objects are attributes and methods. Consequently,
object clients can inspect attributes (though these are most
On Wed, Oct 12, 2011 at 9:50 AM, Dean Landolt d...@deanlandolt.com wrote:
On Wed, Oct 12, 2011 at 10:42 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Wed, Oct 12, 2011 at 6:38 AM, David Bruant bruan...@gmail.com wrote:
Rather than properties, how about modeling events with
Le 12/10/2011 19:32, John J Barton a écrit :
Is their any hope of solving the GC problem with events? By that I
mean the tedious business of matching removeEventListener to every
addEventListener. If I take an event-thingy from an object, then drop
the reference, the remove is automatic:
21 matches
Mail list logo
