But IIUC, you're proposing a semantics where you construct a brand new object
P whose __proto__ is SuperClass.prototype and then copy all the
own-properties of the RHS into P.
Not quite. P is a constructor function (class object), SuperClass is a
constructor function. Unless I'm
You can disagree with anything if you're allowed to change the terms of the
discussion. :)
Brendan said JS is run-to-completion, which means that if you call a function
and control returns to you, no intervening threads of control have executed in
the meantime. But then you changed his example
Hi Kris,
Your proposal has a lot of similarities to
http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions
which was proposed this past spring.
I'm not sure I follow what's top-down vs bottom-up about the two different
approaches. Let me suggest some terminology that has
[1] http://wiki.ecmascript.org/doku.php?id=strawman:dicts [D.H. already
mentioned that this proposal does not reflect his current thinking, so beware]
FWIW, I don't really know what my current thinking is. :)
Dave
___
es-discuss mailing list
These are all good points. I'm not sure (1) is worth bringing back in all the
we won't let you say things you can't enforce complexity, but (2) is maybe
non-obvious enough not to be worth it. I'm backing off my please make it null
position now. :) It actually seems pretty reasonable just to
There are other alternatives, such as supporting both alternatives with two
different entry points (con: API proliferation), taking an optional boolean
flag indicating to return the pair (con: too dynamic a type), taking an
optional outparam object (con: what is this? C?). OK, so most of those
We could even allow for direct proxies to acquire non-standard internal
properties from their target object. This could be a useful principle when
wrapping host objects.
This seems important in order to make host methods work, e.g., the ones that
access the [[Value]] property. I guess
Hi Tom, this looks very promising. Some comments below; quoting the wiki page
inline.
* target is the object which the direct proxy wraps
Just checking: presumably this proposal doesn't allow for target to be a
primitive, right? (Other than the special case of null you mention later.)
I.e.,
(Dave Herman has another way to say this: [ ] and . can be viewed as
operating on two separate property name spaces, but for legacy/normal ES
objects those namespaces are collapsed into a single shared namespace.)
Lest the above be construed as a tacit approval on my part... ;)
IMHO the
I do not yet fully understand the rationale behind dicts.
Nothing fancy, really. Just an idiomatic way to create a non-polluted
string-to-value map. In ES5 you can use Object.create(null), which is not bad
but still kind of a hack. Wouldn't it be nice to have sweet literal syntax for
a
a certain aesthetic that says that's icky, but JS makes it so
convenient that it's the obvious thing to do.
Dave
On Oct 17, 2011, at 4:15 PM, Allen Wirfs-Brock wrote:
On Oct 17, 2011, at 3:34 PM, David Herman wrote:
IMHO the single property name space of es-current is a feature, not a bug
If you want to create a clean-slate proxy object -- for example, a dictionary
-- then you can't predefine toString or valueOf. But this means your object
will always fail at the semantic operations [[ToString]] and [[ToPrimitive]].
For example:
var obj = Proxy.create(myEmptyHandler,
TypeError: can't convert obj to primitive type
Dave
On Oct 16, 2011, at 1:46 PM, David Herman wrote:
If you want to create a clean-slate proxy object -- for example, a dictionary
-- then you can't predefine toString or valueOf. But this means your object
will always fail at the semantic
Forgive me that I've not kept track of where we are in the discussion about the
additional receiver argument.
I think I just found a pretty important use case for the receiver argument. Say
you want to keep some information about a proxy object in a Map or a WeakMap,
and you want the handler
D'oh -- of course, you're right. The use case I'm describing wants the proxy,
not the receiver.
Thanks,
Dave
On Oct 16, 2011, at 2:44 PM, David Bruant wrote:
Le 16/10/2011 23:02, David Herman a écrit :
Forgive me that I've not kept track of where we are in the discussion about
message I sent this afternoon.
(Well, that and performance, which quite possibly sucks. So this may not be a
viable idea. It was an interesting experiment, anyway.)
Dave
On Oct 16, 2011, at 2:49 PM, David Bruant wrote:
Le 16/10/2011 23:02, David Herman a écrit :
Forgive me that I've not kept track
If you want to stratify toString/valueOf in general and for all objects, I
would very much support that.
I'm not sure I understand what you mean. Do you mean something like:
js var obj = Object.create(null, {});
js String(obj)
TypeError: can't convert obj to string
js
I agree with Andreas. The implicitly-called base level methods are not
meta-methods or (spec language) internal methods. They do not need their
own traps. They are base-level property accesses.
Well, certainly that's the way the language currently works. But the way it
currently works is
I have some thoughts about how to use Narcissus as a basis for a compiler to
ES3 as well. It's obviously not necessary to do separately from Traceur, but it
might be interesting to experiment with alternative implementation strategies.
I haven't really done anything in earnest yet, including
,
but not vice versa.
Dave
On Oct 11, 2011, at 8:00 PM, John J Barton wrote:
On Tue, Oct 11, 2011 at 6:17 PM, David Herman dher...@mozilla.com wrote:
Traceur is very good! I'd just like to have something that compiles to ES5
without intermediate libraries, the way CoffeeScript works, so that it's
Fixed, thanks.
Dave, digging his way out of a massive backlog...
On Sep 23, 2011, at 12:18 PM, Axel Rauschmayer wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:string_extras
I’ve found a small bug:
String.prototype.endsWith = function(s) {
var t = String(s);
return
On this particular issue, I'm inclined to agree -- I think we should be
extremely sparing with how many new sigils, if any, we introduce into the
language. You'll notice Brendan has repeatedly said similar things about | and
.{ for example. Syntax matters.
But I feel like now might be a good
I mostly have a similar approach in mind for tail calls. Precise about the
interface, imprecise/informative about the implementation requirements. For
WeakMaps, that means a well-defined API with informal English describing the
expectations about memory consumption. For tail calls, it means a
I don't think we can get away with repurposing _ as a pattern sigil, since it's
already a valid identifier and used by popular libraries:
http://documentcloud.github.com/underscore/
In my strawman for pattern matching, I used * as the don't-care pattern:
A couple reactions:
- strings are already interned in current engines for symbol-like performance;
there's no need to introduce symbols into the language
- private names are overkill for most uses of enums; just use string literals
- in SpiderMonkey I think you get better performance if your
, not dismissive.)
Wasn’t it David Herman a while ago who listed a minimal feature list? For me
it would be:
1. Super property references (mainly methods)
2. Super constructor references
3. Subclassing (mainly wiring the prototypes)
4. Defining a class as compactly as possible (with subclassing
!)
/be
On Sep 2, 2011, at 3:33 PM, David Herman wrote:
Object.getPropertyDescriptor
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Mozilla has evalInSandbox built-ins. We've talked about them, but no one has
produced a strawman based on this work. The module loader API:
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
provides enough functionality.
In fact, I think sandbox is a pretty good intuition for
Yep. Sorry, editing snafu -- I'd started to call it a non-issue when it
occurred to me that proxy authors would still have to know not to string
coerce keys. No big deal -- proxy authors should know better than to rely on
es5 invariants.
Agreed.
Throw at the point where a unique name
I've been exploring private name objects [1] and I'm a bit confused by a few
things in the proposal, especially the Reflection example...
The page was out of date, sorry. I've updated the page to reflect the agreement
we came to in the last face-to-face, which was that private names should
Understood WRT the forgeability of strings -- I was more concerned with the
potential hazard of toStringing the values of an own-names array, only to
find out you have several keys with the string value undefined. Sure you're
doing it wrong, but string keys are an es5 invariant -- it's
Hi Luke,
The idea is definitely to subsume typed arrays as completely as possible.
* Array types of fixed length
The current design fixes the length of an ArrayType instance as part of the
ArrayType definition, instead of as a parameter to the resulting constructor.
I'm not sure I
Putting private properties on a proxy or storing it in a weak map are simple
protocols you can use to keep track of proxies that you know about. You can
hide or expose this information then without however many or few clients you
like. If you want to give people access to knowledge about your
My understanding of generators was naively that they are syntactic sugar for
defining an iterator.
Well, I think I understand what you're getting at: there's a sense in which
generators don't add the ability to do something that's *absolutely impossible*
to express in ES5.
OTOH, generators
My point is that the map spec is a deterministic algorithm because
side-effects would be noticeable otherwise. However, this prevent
implementations where function calls would be done in parallel for instance
(for better performances). In some cases (like the one I showed), the exact
, at 8:11 PM, David Herman dher...@mozilla.com wrote:
According to the module grammar, the following is valid:
691module car {
function startCar() {}
module engine {
function start() {}
}
export {start:startCar} from engine;
}
It seems like there would be issues
Adding a non-enumerable Array.prototype method seems doable to me, if the
name is clear and not commonly used.
We can probably still add Array.prototoype.isArray if that would help to
establish the pattern. Document as being preferred over Array.isArray
This doesn't make sense to me.
I'm not so sure about this now. I was just reviewing with Dave how the design
evolved. We had Function.isGenerator, analogous to Array.isArray. For taskjs,
Dave had thought he had a use-case where the code has a function and wants to
know whether it's a generator. It turned out (IIUC) that
So from this viewpoint (and regarding that example with squares), it's good
to have also `Array.seq(from, to)` method (the name is taken from Erlang, I
just frequently uses lists:seq(from, to) there):
bikeshedArray.range seems like an intuitive name as well./bikeshed
Array.seq(1,
I mentioned two benefits I can see to Array.of over []-literals here:
https://twitter.com/#!/littlecalculist/status/89854372405723136
1) With Array.of you know you aren't going to accidentally create holes, and
2) if you're passing it to a higher-order function you know you aren't going to
I'm not sure what Array.prototype methods would or wouldn't work on
instances of SubArray.
All of them. They are all generic.
We're speaking too broadly here. It depends on what we want to work how. For
example, .map can't magically know how to produce a SubArray as its result if
that's
Agreed. I think that's a pretty common way people think about null vs
undefined, and it's consistent with the language's behavior.
Dave
On Jul 10, 2011, at 3:09 PM, liorean wrote:
On 10 July 2011 22:23, David Herman dher...@mozilla.com wrote:
Another common and useful fusion of two
According to the module grammar, the following is valid:
691module car {
function startCar() {}
module engine {
function start() {}
}
export {start:startCar} from engine;
}
It seems like there would be issues with exporting module elements after the
module has been
I'm not sure. I briefly checked the private names proposal
http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects and I
think the detailed interaction with proxies still has to be fleshed out.
Sure, I'll be happy to work with you on this.
The proposal does mention: All
, Brendan Eich wrote:
On Jul 8, 2011, at 7:17 AM, David Herman wrote:
The proposal does mention: All reflective operations that produce a
property name, when reflecting on a private name, produce the name’s
.public property instead of the name itself.
Would the same hold for reflective
And just to be clear, I meant produce in the sense of producer/consumer
relationship on the trap functions, not in the generative sense.
Dave
On Jul 8, 2011, at 8:40 AM, David Herman wrote:
Sorry, yes. Too early in the morning for me. :)
Indeed, handler traps are exactly the place where
I think I still haven't fully grokked what | means on array literals, but
could it also be used to subclass Array? For example:
function SubArray() {
return SubArray.prototype | [];
}
SubArray.prototype = new Array;
I'm not sure what Array.prototype methods would or
2011/7/6 Andreas Rossberg rossb...@google.com
While putting together some test cases for Object.keys, I wondered: is
it intended that property names are always passed to traps as strings?
That is indeed the intent.
Unless they are private name objects, right?
Dave
the AST API strawman - given the positive discussions on this list, I
thought the idea was implicitly accepted last year, modulo details,
so I was surprised not to see a refined strawman promoted.
It hasn't really been championed so far. I was concentrating on other proposals
for ES.next.
Thanks-- missed one when manually doing s/ImportPath/ImportBinding/g. Fixed.
Thanks,
Dave
On Jul 1, 2011, at 9:55 AM, Kam Kasravi wrote:
Should this
ImportDeclaration(load) ::= import ImportBinding(load) (,
ImportBinding(load))* ;
ImportPath(load) ::= ImportSpecifierSet from
Yeah, tough questions. I don't know. I tried to make the API flexible by
allowing custom builders, and in fact if you look at the test suite you'll see
I did a proof-of-concept showing how you could generate the format that Mark
mentioned:
I've been concerned about the schedule risk of classes for ES.next; following
are some thoughts about a minimal class feature that I believe satisfies the
most important needs while leaving room for future growth.
I think the bare-minimum requirements of classes would be:
- declarative class
- providing idiomatic syntax for calling the superclass constructor
But what about subclass method calling superclass method(s)?
In terms of priorities, I think super-constructors are the single most
important use case for super. But I think super-methods fall out naturally from
the
Hi David,
[A propos of nothing, can I ask that you either change your font or use
plain-text email? Your font shows up almost unreadably small in my mail client.]
I'm currently working on the WeakMap documentation [1] and I have thought of
two points:
1) myWeakMap.set(key, value) doesn't
The point is to encourage people to write *more* well-thought-out proposals
than can fit in an email, not less. Hence Allen's suggestion of blogs,
websites, or github. If language design issues can be resolved in bursts of 140
characters then I think I will need to find a new line of work. ;)
P.S.: another question I have -- is it worth and makes sense to raise a topic
on considering/standardizing the pattern matching (Dave's proposal)?
http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching Brendan
mentioned on Twitter that it's too late (?), but IMO this proposal is
To a first, approximation, it would look something like this:
http://doc.racket-lang.org/reference/contracts.html
;-)
Seriously, the idea is to create contracts that can check structural properties
by wrapping values with proxies that lazily do the checking. The core idea,
known as
Mark and Tom used Ometa for http://code.google.com/p/es-lab/ --
slo-o-o-o-w.
Yeah it has no memoization. Pretty cool nevertheless as far as what he was
able to do. Though I really like what Dave is doing on narcissus.
No credit to me on the Narcissus parser; it was originally written
IANA Rubyist, but I *think* the goal was for blocks to be downwards-only, so
that upvars could live on the stack and everything could be nice speedy. So
they had to syntactically restrict blocks to enforce that they couldn't outlive
the frame in which they were created.
As Brendan says,
Oh, it wasn't clear to me that we really want to have static members.
I may be biased here, but I always viewed static members as just a
poor man's substitute for a proper module system. Fortunately, it
looks like we will have a real one instead!
I'm sympathetic to that view, but statics also
: Claus Reinke claus.rei...@talk21.com
To: David Herman dher...@mozilla.com
Cc: es-discuss@mozilla.org
Sent: Friday, May 20, 2011 2:51 PM
Subject: Modules first or second class (Re: I noted some open issues on
Classes with Trait Composition)
I think modules are a construct that evaluates
Just a note on this: for me, that means Harmony modules
are a step back from what I can implement in JS/now.
How is it a step back, if you can already implement it? We're not taking
objects away from JavaScript.
Not
having first-class modules has been a major drawback in
Haskell (which has
- they can share static information, such as sets of bindings (not that
import * would not work with first-class modules)...
Oops, meant to say: note that import * would not work
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
Wouldn't introducing a new built-in constructor in some module scope
actually have less risk (none?) of producing name clashes than messing
with an existing object?
Yes, and I think it's worth considering. We still need to work out the
organization of the standard library in modules.
Dave
Yes, we've talked about this. One of the issues I don't know how to resolve is
if we want to allow the specification of class properties aka statics, then
those need *not* to be in the scope of the constructor arguments, which ends up
with very strange scoping behavior:
var x = outer
All exports of all declared/required modules are computed before execution
starts. So it doesn't matter what order things run in, you won't get any no
such export errors if you import a valid export.
Dave
On May 19, 2011, at 2:13 PM, James Burke wrote:
Looking at harmony modules[1], I wanted
Using new for the constructor is one of my favorite feature's of Allen's
proposal. Things I like about it:
1. It's terse. Since almost every class defines a ctor, this is helpful.
constructor is a mouthful and repeating the full class name (like in Java,
C++, etc.) is redundant.
2. I
It's okay in Courier New but not in lots of other popular monospaced fonts. See
attached image.
Dave
inline: Screen shot 2011-05-18 at 4.19.01 PM.png
On May 18, 2011, at 3:30 PM, Allen Wirfs-Brock wrote:
On May 18, 2011, at 3:14 PM, David Herman wrote:
I think I like : about as much
Yes, I agree that separating them out is a good idea. Allen and I have been
working on this lately, and I've signed up to present private names at the
upcoming face-to-face. Our thinking has been along similar lines to what you
describe here.
Dave
On May 17, 2011, at 6:55 PM, Luke Hoban
How do you define non-method?
A function that is not invoked as method. Right now, the same kind of
construct is used for both true functions and methods. I’m proposing a new
construct (similar to the distinction that Python makes): a function that
does not have an implicit |this|
- self is just another parameter, it can be called anything.
- Function.prototype.call() and Function.prototype.apply() would have one
parameter less.
- IIRC, this is more or less how Python works.
- Probably not worth it, migration-cost-wise.
This breaks the web, so regardless of whether
There's no perfect answer. Shorter return syntax (^ with an ASI change, or
my empty label idea, function f(){:g()}) is ugly, adds overhead, and can
still be left off by mistake (making for the opposite problem from the
capability leak one: returning undefined instead of the intended result
Evidence is good, but that's not exactly scientific. In particular, I'd wager
there's a material difference in this phenomenon between a language in which
*all* functions implicitly return and one in which this is only the case for a
specific convenience form.
That said, we could also consider
Based on what evidence are we concluding that the majority of the
javascript developers want - syntax for functions? The fact that
coffeescript is the hot buzzword? Was there some developer-community wide
voting or poll that I missed? Or is it that a few vocal people on these lists
like
But, JSConf has just 150-200 JavaScript developers in attendance.
Right. The JS community has no borders, no government, no constitution, no
membership cards, no census... We welcome everyone. So we have no way of
instituting democratic institutions.
they are definitely not a representative
That sounds like a grammar bug -- no time to debug at the moment but I'll
address. A Program should be able to import but not export.
Dave
On May 2, 2011, at 12:50 PM, Erik Arvidsson wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:modules
IMO, writing these issues up as strawmen was a nice way to spark discussion but
I don't see any need for them to clutter the harmony: namespace with extra
proposals.
Why don't we just take the decisions and fold them into the existing proxy
proposals. Does that seem reasonable?
Dave
On Apr
Hi Claus,
Thanks for the bug report. I'm afraid I just don't have time for site
sysadminning at the moment. Eventually we are hoping to upgrade the wiki and
move it to our own (more reliable) servers, rather than the 3rd party server
it's currently hosted on. But I won't be able to work on
OTOH we don't need to standardize __proto__. We might instead poison-pill it
in Harmony, so opting in involves an early error on every use of __proto__,
and you have to migrate by switching to Object.getPrototypeOf or an object
initialiser extension that allows presetting the new object's
The const functions proposal isn't about referential transparency. They still
encapsulate mutable state. What makes them const are the frozen property
table (recall that functions in ES are objects) and the local name that's bound
to the function.
Dave
On Apr 17, 2011, at 1:06 AM, Claus
I don't understand. What is overwriting an operator?
Dave
On Apr 17, 2011, at 7:52 AM, Adam Stankiewicz wrote:
Hello everyone,
My idea is to disallow overwriting of === operator, and make 'compare'
operator implement == instead. Why?
1. === means for me that two variables have reference
We've talked about this on TC39. We'll probably do something, but exactly what
is hard to say at this point. Designing future-proof pragma syntax requires a
bit of gazing into the crystal ball...
Dave
On Apr 17, 2011, at 2:13 AM, Claus Reinke wrote:
Pragmas (ignorable source hints to an
I don't like this idea. It's inconsistent with the behavior of the other traps,
it relies too subtly on a funky stateful idiom, and it's hard to predict when
the traps will actually fire (since it depends on how clients use the proxy).
If there's something being set once-and-for-all I prefer it
Claus,
Thanks for the suggestions. Let me see if I can summarize them and respond
briefly:
* functions with expression bodies
This was proposed for ES4 and implemented in SpiderMonkey. I believe there are
some unfortunate ambiguities in the grammar that came up, and I think they've
been
.)
Dave
On Apr 17, 2011, at 8:55 AM, Adam Stankiewicz wrote:
By overwriting I meant creating a trap for === operator. Sorry for confusion.
Adam
2011/4/17 David Herman dher...@mozilla.com:
I don't understand. What is overwriting an operator?
Dave
On Apr 17, 2011, at 7:52 AM, Adam
Forms like `fluid-let' don't actually make dynamic decisions about *scope* --
they just mutate an existing, statically-scoped variable. We're really just
talking about dynamic decisions about *where a variable is bound*, not *what
the current value of its binding is*. That said, I happen to
P.S.: so having this issue as already solved (as a runtime error, but still
-- the error!, not a typo-hazard!)
It doesn't always produce a runtime error. If the property happens to be there,
there's no error. Also, take a look at the confusing issues that arise from the
dynamic semantics of
that important.
Regardless, it's clear I caused confusion by my usage. I'll make an effort on
es-discuss to be explicit about which I mean.
Dave
On Apr 15, 2011, at 6:48 PM, Mark S. Miller wrote:
On Fri, Apr 15, 2011 at 6:28 PM, David Herman dher...@mozilla.com wrote:
The fact is that dynamic scope
Think of it this way: dynamic binding no, dynamic assignment yes.
So this means, no function expressions depending on the condition? I.e.:
this[foo] = isDebug ? function () { ... } : function () { ... }
var foo = isDebug ? function() { ... } : function() { ... }
Or I guess, such cases will
Dynamic binding is bad, mmmkay? ;)
Seriously, it's not an efficiency thing. Dynamic scope is easy to write but
hard to predict. JS is lexically/statically scoped almost everywhere, except
for with, eval, and the global object. Strict mode solves with and eval.
Harmony solves the global object.
It'll be the WindowProxy as usual, in top level code. Dave has addressed
what it will be in a module recently.
I have to look on Dave's explanation, seems I missed it. But this WindowProxy
won't be assessable then, right? Will it be possible to define a new global
property/variable at
Cool -- is this spec'ed yet?
http://wiki.ecmascript.org/doku.php?id=harmony:modules#this
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I don't think this feature is worth all this discussion or time, which is why I
haven't said very much. But I don't like the idea.
It *is* ambiguous, in the sense that if you wrote the grammar in the natural
way it would be an ambiguous grammar, so you have to rewrite the grammar in
such a way
, and to date there's sadly not enough good, authoritative
material with that kind of advice (how not to be anti-modular).
Dave
On Apr 11, 2011, at 7:07 AM, Mark S. Miller wrote:
On Sun, Apr 10, 2011 at 11:21 PM, David Herman dher...@mozilla.com wrote:
I wondered if someone was going to make this point
Yes, that's the idea.
Best,
Dave
On Apr 11, 2011, at 7:45 AM, Axel Rauschmayer wrote:
My understanding is limited, but here it goes:
You load modules in ES.next as follows:
module JSON = require('http://json.org/modules/json2.js');
A custom module loader (loosely related to a Java
function getDefiningObject(obj, key) {
if (!(key in obj))
throw new Error(key + key + not found);
while (!obj.hasOwnProperty(key))
obj = Object.getPrototypeOf(obj);
return obj;
}
On Apr 10, 2011, at 10:24 AM, Axel Rauschmayer wrote:
As far as I am aware, there is
The module system was designed to make it as easy as possible to use, both for
general ease of use and to encourage modular programming. Once you move to an
approach where programmers have to write their own linking specifications, it
tends to get much more complicated. When you make modules
I wondered if someone was going to make this point.
That should be
while (!{}.hasOwnProperty.call(obj, key))
which works even if obj has an own property named 'hasOwnProperty'.
Not if someone mutates Object.prototype.hasOwnProperty or
Function.prototype.call. I don't think we
We shouldn't be making backwards-incompatible changes for features just because
they can be abused. Every feature can be abused. And simplifying the completion
type is not even remotely an important goal.
Sometimes labels are just necessary. Sometimes you have a loop that needs an
early
, just an unfortunate overloading of
terminology. Nothing to see here, move along.
On Apr 9, 2011, at 10:24 AM, Wes Garland wrote:
On Sat, Apr 9, 2011 at 12:47 PM, David Herman dher...@mozilla.com wrote:
When people say Tennent's correspondence principle to mean something like
beta-conversion
401 - 500 of 654 matches
Mail list logo
