false.hasOwnProperty('whatever');
1.0.isPrototypeOf({whate:'ver'});
'string'.propertyIsEnumerable('whatever')
these are already examples of an over-polluted prototype with methods
nobody uses ... I thought 4 extra methods everyone is using same way except
for Rick that honorees Tesla in this day would not hurt much but once
again, my point is that it's really about the time to put some standard
mechanism to deal with events in ES code.
The fact Object.observe is already accepting a handler with an argument
which is fired as an event smells to me ... I'd rather define upfront a
common definition of handlers then propose any extra method based on them
;-)
Best Regards
On Wed, Jul 10, 2013 at 4:04 PM, K. Gadd <k...@luminance.org> wrote:
> I think at this point we have a long history of language designs where
> random stuff has been tacked onto the core base class (i.e. Object) that
> really shouldn't have gone there - hashCode/toString in Java/C#, etc - such
> that any proposal to put something on Object instances deserves extreme
> skepticism. Static methods on Object aren't nearly so bad.
>
> In this case, the problem being solved can almost certainly be solved
> through composition or some other design mechanism. Bolting it onto every
> instance of Object, even if the only universally paid cost is a reserved
> name on the prototype, is simply not the right solution unless the
> downsides of other approaches are intolerable. Which they aren't.
>
> In practice a lot of these use cases call for event subscription and
> broadcasting to occur through a separate coordinator ('event bus') object
> and not through the object in question, anyway. This addresses a bunch of
> reference cycle problems that are caused when you subscribe directly to an
> object. You don't need to look much further than the DOM for examples...
>
>
> On Wed, Jul 10, 2013 at 3:57 PM, Rick Waldron <waldron.r...@gmail.com>wrote:
>
>> I don't want any of this on my Object objects. Not all objects represent
>> something that can or should emit/publish/trigger/broadcast.
>>
>> For example...
>>
>> class Light {
>> constructor() {
>> // initialize Light control instance
>> }
>> on() {
>> // send bits to turn Light on
>> }
>> off() {
>> // send bits to turn Light off
>> }
>> }
>>
>>
>> So what happens now? All of my Led instances have emit, trigger, once and
>> boundTo methods that are actually useless now. No thanks. I also don't want
>> Object.prototype.* and Object.* to suffer the same way that the [[Global]]
>> (window) object in browsers has suffered. Give a hoot, don't pollute.
>>
>> Post ES6 world makes creating emitter objects trivial—so why not a
>> blessed standard lib module that can be imported and used to extend a class
>> declaration?
>>
>>
>> import { Emitter } from "@event";
>>
>> class Foo extends Emitter {}
>>
>> Easy.
>>
>> More inline...
>>
>>
>>
>> On Wed, Jul 10, 2013 at 3:58 PM, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> I know but people use prefixes and unique ids for events too and I am
>>> not sure if that would work so well.
>>>
>>> Also, this is not backward compatible, or better, this is impossible to
>>> polyfill so it won't bring benefits to the current scenario.
>>>
>>> If only I could already `Object.mixin(Object.mixin({}, EventEmitter),
>>> EventTarget)` and alias those prolix names as `on()` and `off()` it would
>>> be already great but this is too much in between the DOM, behind WebIDL,
>>> and ECMAScript ... something I know already historically incompatible,
>>> that's why I've proposed new names hopefully one day (and hopefully soon)
>>> in core, something that will be inherited in current implementation in any
>>> case, as it was in my case simply polluting the `Object.prototype` with
>>> those non enumerable properties luckily inherited in hosted DOM objects too.
>>>
>>> best regards
>>>
>>>
>>> On Wed, Jul 10, 2013 at 12:46 PM, Matthew Robb
>>> <matthewwr...@gmail.com>wrote:
>>>
>>>> You can do chainability at object define time with the sugar form:
>>>>
>>>> var obj = {
>>>> on type1(){},
>>>> on type2(){},
>>>> on type3(){}
>>>> }
>>>>
>>>
>> This is the dark days of DOM element properties as event handlers:
>>
>> elem.onclick...
>>
>> Assigning to this paves over the previous assignment, leaving no way to
>> have multiple handlers registered for the same event type.
>>
>>
>>
>>
>>>
>>>> OR add to it using one of the following options:
>>>>
>>>> Object.mixin(obj, {
>>>> on type1(){},
>>>> on type2(){},
>>>> on type3(){}
>>>> })
>>>>
>>>> obj.{
>>>> on type1(){},
>>>> on type2(){},
>>>> on type3(){}
>>>> }
>>>>
>>>> obj := {
>>>> on type1(){},
>>>> on type2(){},
>>>> on type3(){}
>>>> }
>>>>
>>>>
>>>> On Wed, Jul 10, 2013 at 12:41 PM, Andrea Giammarchi <
>>>> andrea.giammar...@gmail.com> wrote:
>>>>
>>>>> my implementation works already with `DOM` nodes and browser
>>>>> environment, including `window`.
>>>>>
>>>>> I've also already written an `EventTarget` mixin object but in my case
>>>>> I'd use that via `Object.mixin(Object.prototype, EventTarget);` 'cause
>>>>> almost every object I use in my logic should be observed or should emit
>>>>> something to some other object.
>>>>>
>>>>
>> Standard lib approach (a la node) works today and tomorrow.
>>
>>
>>>
>>>>> Of course Dictionaries are out of the game but that's OK, as long as
>>>>> it's possible to promote them later on via `Object.setPrototypeOf(dict,
>>>>> Object.proottype)`
>>>>>
>>>>> I find the `Object.addEventListener(obj, "type", handler)` approach
>>>>> very boring for the simple reason that it does not make sense to use
>>>>> chainability there, another de-facto thing when it comes to events.
>>>>>
>>>>
>> It's also (subjectively) hideous.
>>
>>
>>
>>>
>>>>> ```javascript
>>>>> // current eddy.js status
>>>>> var obj = {}
>>>>> .on(type1, handler1)
>>>>> .on(type2, handler2)
>>>>> .on(type3, handler3)
>>>>> ;
>>>>> ```
>>>>>
>>>>
>> That's great for your use case, but I would never want this by default.
>>
>>
>> Rick
>>
>> (snip)
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
