<div dir="ltr"><div>I was on board with potentially making `has()` receiver-dependent but you lost me when you expected `getOwnPropertyNames` to trigger a trap on a proxy-as-prototype. Adding `receiver` to every MOP method is a no-go. It fundamentally changes the meaning of these operations and it would destroy the pay-only-when-you-use-it performance model of proxies, since operations that used to be local to only the 'own' object would now need to search the proto-chain for a potential proxy trap.</div><div><br></div><div><div><div>Using a proxy-as-prototype was never intended as a way to be able to intercept arbitrary operations on whatever object happened to inherit from the proxy. A proxy-as-prototype still emulates only a single object. It just happens to be an object that serves as a prototype for other objects.</div><div><br></div></div></div><div>Cheers,</div><div>Tom</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-18 23:18 GMT+01:00 Michael Theriot <span dir="ltr"><<a href="mailto:michael.lee.theriot@gmail.com" target="_blank">michael.lee.theriot@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think I figured out how to make inheritance work...<div><br></div><div>```js</div><div><span style="font-family:Consolas,'Lucida Console',monospace;font-size:12px;white-space:pre-wrap">var wm1 = new WeakMap();

function A() {
  let proxy = new Proxy(this, {
    get: (target, property, receiver) => property === 'bacon' || target[property]
  });
  wm1.set(proxy, {});
  return proxy;
}

var wm2 = new WeakMap();

function B() {
  let proxy = A.call(new Proxy(this, {
    get: (target, property, receiver) => property === 'ham' || target[property]
  }));
  wm2.set(proxy, {});
  return proxy;
}

var a = new A();
var b = new B();

wm1.has(a); // true
wm2.has(a); // false

wm1.has(b); // true
wm2.has(b); // true</span><br></div><span class=""><div><span style="font-family:Consolas,'Lucida Console',monospace;font-size:12px;white-space:pre-wrap"><br></span></div><div><span style="font-family:Consolas,'Lucida Console',monospace;font-size:12px;white-space:pre-wrap">a.bacon; // true</span></div><div><span style="font-family:Consolas,'Lucida Console',monospace;font-size:12px;white-space:pre-wrap">a.ham; // undefined</span></div><div><span style="font-family:Consolas,'Lucida Console',monospace;font-size:12px;white-space:pre-wrap"><br></span></div></span><div><span style="font-family:Consolas,'Lucida Console',monospace;font-size:12px;white-space:pre-wrap">b.bacon; // true</span></div><div><span style="font-family:Consolas,'Lucida Console',monospace;font-size:12px;white-space:pre-wrap">b.ham; // true</span></div><div><span style="font-family:Consolas,'Lucida Console',monospace;font-size:12px;white-space:pre-wrap">```</span></div><div><span style="font-family:Consolas,'Lucida Console',monospace;font-size:12px;white-space:pre-wrap"><br></span></div><div><span style="font-family:Consolas,'Lucida Console',monospace;font-size:12px;white-space:pre-wrap">I can't imagine this is good for optimizations though. But I guess it does what I need.</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 4:45 PM, Michael Theriot <span dir="ltr"><<a href="mailto:michael.lee.theriot@gmail.com" target="_blank">michael.lee.theriot@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">Michael’s preferred approach also introduces observable irregularity into the standard JS inheritance model for ordinary objects.<br>Consider an object created using Michael’s preferred approach:<br>```js<br><span>var arr = [0, 1];<br></span>console.log(Reflect.has(arr,”0”));  //true, arr has “0” as an own property<br>var subArr = Object.create(arr);<br>console.log(Reflect.has(subArr,”0”));  //true, all unshadowed properties of proto visible from ordinary objects<br>var b = new ArrayView2(arr);<br>console.log(Reflect.has(b,”0”));  //true, prototype proxy makes array elements visible as if properties of b<br>var subB= Object.create(b);<br>console.log(Reflect.has(subB,”0”));  //false, some unshadowed properties of proto is not visible from subB<br>```</blockquote></span><div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I think this relates to the original concern; if you could pass the receiver this could be resolved. That still leaves `getOwnPropertyNames` reporting wrong values though and I see no foreseeable way to resolve that without returning an actual proxy itself.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The reason I'm trying this approach is because I read on the MDN that when used in the prototype a `receiver` argument is passed that references the instance, so I assumed this was the intent behind it. The only other explanation I could think of is that proxies have a receiver to mimic the `Reflect.set`/`Reflect.get` methods which need a receiver for getters/setters to work properly, not so you can use them on the prototype chain.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The other case I would make is every instance would have an identical proxy, and it just makes sense to put that on the prototype for the same reasons you put shared methods/properties there.</div><span><div style="font-size:12.8px"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">Note that we are not really talking about a new capability here. Michael’s first design shows that ES proxies already have the capability to implement the object level semantics he desires.</span></blockquote><div><br></div></span><div>To be fair I had several obstacles with inheritance using the first version.</div></div><div><br></div><div>```js<br></div><div>var wm1 = new WeakMap();<br></div><div><div><br></div><div>function A() {<br></div><div>  wm1.set(this, {});<br>  return new Proxy(this, {});</div><div>}</div><div><br></div><div>var wm2 = new WeakMap();</div><div><br></div><div>function B() {</div><div>  A.call(this);<br></div><div>  wm2.set(this, {});</div><div>  return new Proxy(this, {});</div><div>}</div></div><div><br></div><div>var a = new A();</div><div>var b = new B();</div><div><br></div><div>wm1.has(a); // true</div><div>wm2.has(a); // false</div><div><br></div><div>wm1.has(b); // false</div><div>wm2.has(b); // true</div><div>```<br></div><div><br></div><div>As you can see storing a reference to `this` can't work anymore, since we actually return a proxy. You can try to work around this...</div><div><br></div><div><div>```js</div><div>var wm1 = new WeakMap();<br></div><div><div><br></div><div><div>function A() {</div><div>  let self = this;</div><div>  if(new.target === A) {</div><div>    self = new Proxy(this, {});</div><div>  }</div><div>  wm1.set(self, {});</div><div>  return self;</div><div>}</div></div><div><br></div><div>var wm2 = new WeakMap();</div><div><br></div><div>function B() {</div><div><div>  let self = this;</div><div>  if(new.target === B) {</div><div>    self = new Proxy(this, {});</div><div>  }</div><div>  A.call(self);</div><div>  wm2.set(self, {});</div><div>  return self;</div></div><div>}</div></div><div><br></div><div>var a = new A();</div><div>var b = new B();</div><div><br></div><div>wm1.has(a); // true</div><div>wm2.has(a); // false</div><div><br></div><div>wm1.has(b); // true</div><div>wm2.has(b); // true</div><div>```</div></div><div><br></div><div>But then problems arise because the new proxy doesn't go through the old proxy. So anything guaranteed by A()'s proxy is not guaranteed by B()'s proxy.</div><div><br></div><div>```js</div><div><div>var wm1 = new WeakMap();</div><div><br></div><div>function A() {</div><div>  let self = this;</div><div>  if(new.target === A) {</div><div>    self = new Proxy(this, {</div><div>      get: (target, property, receiver) => property === 'bacon' || target[property]</div><div>    });</div><div>  }</div><div>  wm1.set(self, {});</div><div>  return self;</div><div>}</div><div><br></div><div>var wm2 = new WeakMap();</div><div><br></div><div>function B() {</div><div>  let self = this;</div><div>  if(new.target === B) {</div><div>    self = new Proxy(this, {</div><div>      get: (target, property, receiver) => property === 'ham' || target[property]</div><div>    });</div><div>  }</div><div>  A.call(self);</div><div>  wm2.set(self, {});</div><div>  return self;</div><div>}</div><div><br></div><div>var a = new A();</div><div>var b = new B();</div><div><br></div><div>wm1.has(a); // true</div><div>wm2.has(a); // false</div><div><br></div><div>wm1.has(b); // true</div><div>wm2.has(b); // true</div></div><div><br></div><div>a.bacon; // true</div><div>a.ham; // undefined</div><div><br></div><div>b.bacon; // undefined</div><div>b.ham; // true</div><div>```</div><div><br></div><div>(I'm open to solutions on this particular case... One that doesn't require me to leak the handler of the A proxy)</div><div><br></div><div>Ultimately I can actually achieve both what I want with the ArrayView example and inheritance by using a **lot** of `defineProperty` calls on `this` in the constructor, but performance is a disaster as you might expect.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 2:55 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">AFAIK the reason there is a `receiver` is to deal with prototype cases ... if that was a good enough reason to have one, every prototype case should be considered for consistency sake.<div><br></div><div>We've been advocating prototypal inheritance for 20 years and now it's an obstacle or "not how JS is"?</div><div><br></div><div>```js</div><div>class Magic extends new Proxy(unbe, lievable) {</div><div>  // please make it happen</div><div>  // as it is now, that won't work at all</div><div>}</div><div>```</div><div><br></div><div>Best Regards</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 7:30 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I agree with Allen. I am certainly willing -- often eager -- to revisit and revise old design decisions that are considered done, when I think the cost of leaving it alone exceeds the cost of changing it. In this case, the arguments that this extra parameter would be an improvement seem weak. Even without the revising-old-decision costs, I am uncertain which decision I would prefer. Given these costs, it seems clear we should leave this one alone.<div><br></div><div>Unless it turns out that the cost of leaving it alone is much greater than I have understood. If so, please help me see what I'm missing.</div><div><br></div><div><br></div><div><br><div><br></div><div><br></div></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 12:17 PM, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Mar 18, 2016, at 9:24 AM, Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Agreed with everybody else the `receiver` is always needed and `Proxy` on the prototype makes way more sense than per instance.</div></div></blockquote><div><br></div></span>I don’t agree.  While you certainly can imagine a language where each object’s “prototype” determines that object’s fundamental behaviors and provides the MOP intercession hooks(in fact that’s how most class-based languages work).  But that’s not the JS object model.  Each JS object is essentially a singleton that defines it’s own fundamental behaviors.  Whether or this model is better or worse than the class-based model isn't really relevant, but in the context of JS there are advantage to consistently adhering to that model,</div><div><br></div><div>For example, in Michael’s  desired approach, the instance objects of his ArrayView abstraction are “ordinary objects”.  One of the fundamental behavioral characteristics of ordinary objects is that all of there own properties are defined and available to the implementation in a standard way. Implementations certainly make use of that characteristic for optimization purposes. Michael’s approach would make such optimizations invalid because every time an own property needed to be access a prototype walk would have to be performed  because there might be an exotic object somewhere on the prototype chain that was injecting own property into the original “receiver”.</div><div><br></div><div>Michael’s preferred approach also introduces observable irregularity into the standard JS inheritance model for ordinary objects.</div><div><br></div><div>Consider an object created using Michael’s preferred approach:</div><div><br></div><div>```js</div><div><span><div>var arr = [0, 1];</div></span><div>console.log(Reflect.has(arr,”0”));  //true, arr has “0” as an own property</div><div>var subArr = Object.create(arr);</div><div>console.log(Reflect.has(subArr,”0”));  //true, all unshadowed properties of proto visible from ordinary objects</div><span><div><br></div><div>var b = new ArrayView2(arr);</div></span><div><div>console.log(Reflect.has(b,”0”));  //true, prototype proxy makes array elements visible as if properties of b</div><div>var subB= Object.create(b);</div><div>console.log(Reflect.has(subB,”0”));  //false, some unshadowed properties of proto is not visible from subB</div><div>```</div><div><br></div><div>Note the his original Proxy implementation does not have this undesirable characteristic. </div><div><br></div><div>So what about the use of `receiver` in [[Get]]/[[Set]].  That’s a different situation.  [[Get]]/[[Set]] are not fundamental, rather they are derived (they work by applying other more fundamental MOP operations). The `receiver` argument is not used by them to perform property lookup (they use [[GetOwnProperty]] and [[GetPrototypeOf]]) for the actual property lookup).  `receiver` is only used in the semantics of what happens after the property lookup occurs.  Adding a `receiver` argument to the other MOP operations for the purpose of changing property lookup semantics seems like a step too far. The ES MOP design is a balancing act between capability, implementability, and consistency. I think adding `receiver` to every MOP operation would throw the design out of balance.</div><div><br></div><div>Finally,</div><div><br></div><div>Note that we are not really talking about a new capability here.  Michael’s first design shows that ES proxies already have the capability to implement the object level semantics he desires. So, we are only talking about exactly how he goes about using Proxy to implement that semantics. He would prefer a different Proxy design than what was actually provided by ES6. But that isn’t what was specified or what has now been implemented. We can all imagine how many JS features might be “better” if they worked somewhat differently. But that generally isn’t an option. The existing language features and their implementations are what they are and as JS programmers we need to work within that reality.</div><span><font color="#888888"><div><br></div><div>Allen</div><div><br></div></font></span></div><div><div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Also the `getPrototypeOf` trap is really pointless right now</div><div><br></div><div>```js</div><div><div>function Yak() {}</div><div>Yak.prototype = new Proxy(Yak.prototype, {</div><div>  getPrototypeOf: (target) => console.log('lulz')</div><div>});</div><div><br></div><div>var yup = new Yak;</div><div>Object.getPrototypeOf(yup);</div></div><div>```</div><div><br></div><div>The `target` is actually the original `Yak.prototype` which is already the `yup` prototype: useless trap if used in such way.</div><div><br></div><div>Being also unable to distinguish between `getOwnPropertyNames` vs `keys` is a bit weird.</div><div><br></div><div>`Proxy` looks so close to be that powerful but these bits make it kinda useless for most real-world cases I've been recently dealing with.</div><div><br></div><div>Thanks for any sort of improvement.</div><div><br></div><div>Regards</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 1:54 PM, Michael Theriot <span dir="ltr"><<a href="mailto:michael.lee.theriot@gmail.com" target="_blank">michael.lee.theriot@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm trying to make the proxy-as-a-prototype pattern work but I've just discovered the `ownKeys` trap is never called on traps on the prototype. So even if the `has` trap is allowed to see the `receiver`, and thus verify the properties "0", "1" exist, this pattern would fail to return the properties "0", "1" exist on an `Object.getOwnPropertyNames` call. Disappointing! I'd rather use a proxy on the prototype than create one for each instance but without a correct `ownKeys` return it just doesn't come full circle. Is there a trick to make this work or am I out of luck here? I can only think of actually defining the properties to make it work, which defeats the idea of using a proxy on the prototype to begin with.<div><br></div><div>Regardless I agree that traps called on a prototype chain should always receive the `receiver` as an argument. I think the only trap other than `set`, `get`, and `has` that can do this is the `getPrototypeOf` trap (currently does not have a `receiver`) when the `instanceof` check needs to climb the prototype chain.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 17, 2016 at 6:29 PM, Tom Van Cutsem <span dir="ltr"><<a href="mailto:tomvc.be@gmail.com" target="_blank">tomvc.be@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The rationale for not having a `receiver` argument to `has` is that the value produced by the "in" operator is not normally dependent on the receiver. This is in contrast with `get` and `set` which may find an accessor up the proto chain that needs to run with a `this` bound to the receiver.</div><div><br></div><div>That said, I follow your line of reasoning and it is true that `has`, `get` and `set` are the three traps that can be called on a proxy-used-as-prototype (now that `enumerate` is considered deprecated), so it would be consistent to allow all of them to  refer back to the original receiver. This enables the general pattern that you illustrate.</div><div><br></div><div>As you note, the weirdness of this is apparent because it doesn't normally make sense to pass a `receiver` argument to Reflect.has(). However, if `receiver` would be made visible in a Proxy handler's `has` trap, then `Reflect.has` should nevertheless be likewise extended so that one can faithfully forward the `receiver` argument.</div><div><br></div><div>Spec-wise, I think the only significant change is that <a href="http://www.ecma-international.org/ecma-262/6.0/#sec-hasproperty" target="_blank">7.3.10 HasProperty</a>, step 3 must be changed to `O.[[HasProperty]](P, O)` and all [[HasProperty]] internal methods must likewise be extended with an extra argument (which they ignore). Only the Proxy implementation in 9.5.7 would then actually refer to that argument.</div><div><br></div><div>Cheers,</div><div>Tom</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>2016-03-17 11:46 GMT+01:00 Michael Theriot <span dir="ltr"><<a href="mailto:michael.lee.theriot@gmail.com" target="_blank">michael.lee.theriot@gmail.com</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div>I feel like it should, or I am misunderstanding something fundamental. I made a basic scenario to explain:</div><div><br></div><div>```js</div><div>var arrays = new WeakMap();</div><div><br></div><div>function ArrayView(array) {</div><div>  arrays.set(this, array);</div><div><br></div><div>  return new Proxy(this, {</div><div>    set: (target, property, value) => (arrays.has(this) && property in arrays.get(this))  ? arrays.get(this)[property] = value : target[property] = value,</div><div>    get: (target, property)        => (arrays.has(this) && property in arrays.get(this))  ? arrays.get(this)[property]         : target[property],</div><div>    has: (target, property)        => (arrays.has(this) && property in arrays.get(this)) || property in target</div><div>  });</div><div>}</div><div><br></div><div>ArrayView.prototype = Object.create(Array.prototype, {</div><div>  arrayLength: {</div><div>    get() {</div><div>      return arrays.get(this).length;</div><div>    }</div><div>  }</div><div>});</div><div>```</div><div><br></div><div>When `new ArrayView(somearray)` is called the reference to `somearray` is stored in the `arrays` weak map and a proxy is returned that allows you to manipulate indices on it, or fallback to the object for other properties.</div><div><br></div><div>This could be simplified by putting the proxy on the prototype chain to reduce overhead and actually return a genuine `ArrayView` object instead:</div><div><br></div><div>```js</div><div>var arrays = new WeakMap();</div><div><br></div><div>function ArrayView2(array) {</div><div>  arrays.set(this, array);</div><div>}</div><div><br></div><div>var protoLayer = Object.create(Array.prototype, {</div><div>  arrayLength: {</div><div>    get() {</div><div>      return arrays.get(this).length;</div><div>    }</div><div>  }</div><div>});</div><div><br></div><div>ArrayView2.prototype = new Proxy(protoLayer, {</div><div>  set: (target, property, value, receiver) => (arrays.has(receiver) && property in arrays.get(receiver))  ? arrays.get(receiver)[property] = value : Reflect.set(target, property, value, receiver),</div><div>  get: (target, property, receiver)        => (arrays.has(receiver) && property in arrays.get(receiver))  ? arrays.get(receiver)[property]         : Reflect.get(target, property, receiver),</div><div>  has: (target, property)                  => (arrays.has(target)   && property in arrays.get(target))   || Reflect.has(target, property)</div><div>});</div><div>```</div><div><br></div><div>Under this setup `target` refers to the protoLayer object which is useless here, but we can use the `receiver` argument in its place to access the weak map, and replace our set/get operations with Reflect.set/Reflect.get calls to the target (protoLayer) using a receiver (the instance) to pass the correct `this` value to the `arrayLength` getter and prevent infinite recursion.</div><div><br></div><div>One problem - handler.has() lacks a receiver argument. So in this scenario when using the `in` operator it will always fail on array properties because we cannot check the weak map by passing in the instance.</div><div><br></div><div>```js</div><div>var arr = [0, 1];</div><div><br></div><div>var a = new ArrayView(arr);</div><div>a.arrayLength; // 2</div><div>'arrayLength' in a; // true</div><div>'0' in a; // true</div><div>'1' in a; // true</div><div>'2' in a; // false</div><div><br></div><div>var b = new ArrayView2(arr);</div><div>b.arrayLength; // 2</div><div>'arrayLength' in b; // true</div><div>'0' in b; // false</div><div>'1' in b; // false</div><div>'2' in b; // false</div><div>```</div><div><br></div><div>Without a receiver argument on handler.has(), it is practically useless for proxies used as a prototype. You can't reference the instance calling it and your target is simply the parent prototype.</div><div><br></div><div>Is there a reason the handler.has() trap should not obtain the receiver when used on the prototype chain? I can understand why Reflect.has() wouldn't have a receiver argument (that wouldn't make sense) but this seems like a legitimate use for it. Otherwise I don't see a reason to use the handler.has() trap at all on prototype proxies except for bizarre behaviors that have nothing to do with the instance. It will always have the same behavior across all instances since you can't differentiate them.</div></div>
<br></div></div>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></blockquote></div></div></div><br></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div>    Cheers,<br>    --MarkM</div>
</font></span></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>