Proposal: Typeof Trap
Proxy’s typeof trap. Example:
```js
class ClassA {}
const proxyHandler = {
type(target) {
return target instanceof ClassA ? `object_a` : typeof target
}
}
const instanceA = new ClassA
const proxyA = new Proxy(instanceA, proxyHandler)
typeof proxyA // ‘object_a’
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Removing the space in `a+ +b`?
Lexer already sees `++` as operator, not `+` operator**s**. It can be hard to implement something like that. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: native XML object support.
> the client, it could still somehow shine in NodeJS though. The only way it can shine is only passing HTML objects as arg to website. That’s it. And still, you can use string to do that for you. People already use JSON and I don’t think they would use XML in Node js. There are already tons of libs for XML stuff, yet they don’t have a lot of downloads, as far as I remember. So basically, Node js doesn’t need XML. That would be useless. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: native XML object support.
> With strings and even E4X, you don't get the same experience that react
> supports. Things like property completion in XML mode, XML internal logic,
> etc.
Pretty sure you can do this:
```js
// ... xml function definition
/**
* @type {Element}
* @prop {string} href
*/
const xmlObj = xml`something`
```
This should make editor auto-complete xml object for you.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: native XML object support.
XML in JS without React could totally bring usage in Node js, not only JS. For
example, you could pass XML object as parameter to website from server and
server would change it to right way, so XML object would be turned to HTML
element.
However, in non web-development environment, it would have no usage. Since
sometimes Node js is used for general-purpose and not web-development, XML
would be practically useless and JSON would be used. And things such as E4X
already exist.
The benefit of XML is that you can do `d `(which is
equivalent to
```json
{
‘//name’: ‘a’,
‘//inner’: [‘d ’, {...}],
b: ‘c’
}
```) and it’s more readable than JSON version of it.`
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: Static Typing
> Hello, to play the devils advocate: why does JavaScript need static typing? > Your proposal doesn't really answer that. Sure, it mentions tooling and IDEs > that can provide you with type hints and complain on mistakes I actually did. It keeps unwanted type mutations and bad values away. For example, This: ```js let a = 10 a += ‘1’ // ‘101’ // or a += undefined // NaN ``` VS this: ```js let a: number = 10 a += ‘1’ // Error, cannot convert type string to type number. // or a += undefined // Error, number doesn’t have nullable mark. ``` This can help developer itself, in runtime, not only at development time. “But IDE wouldn’t allow that.” But what if property in required json(node js), is undefined? Some IDEs don’t have JSON intellisense, so this is where it can get annoying. > but things like Flow and Typescript do this today already. Yes, but they are compile-time only. Meaning, that in runtime, type mutation and unwanted values can happen. > What's your goal, to have JS engines run Typescript(-like) code natively > without transpiling? First of, this is compiling. TypeScript is higher level than JS, so it’s compiling. Second, TypeScript code is completely compile-time only. Classes(And other ES8+ code), imports, exports and probably namespaces are the only things which are at runtime also. > What's the point of building this feature into engines? It just provides > additional complexity. I said reasons above. Also as I said, they are optional. Meaning, new comers can still learn old js code without static types. Besides, doesn’t async, await, classes and other new stuff add complexity to new people to JS? > Where (when) do you expect types to be checked? Should the engine throw early > errors (during parsing)? Languages normally check types during compile-time. I expect JS to throw errors in runtime, meaning that if you make code which would throw type error and it’s untouched, then it doesn’t throw an error. > What does "static typing" even mean to you in a dynamic scripting language? Same thing as in real statically typed languages. Type checking. > and what happens when you introduce new types with `eval` or by loading > another script? Since as I said, they are runtime only type checking. > However I would be curious to know if anybody has a usage for them at run time They have. `eval` can make type mutation(and if it checks the string, you can still overcome them(inputs or array joining)). Also, if transpiling and compiling is better, why not leave JS dead? I mean, compilers can do job instead of JS. It’s just basically useless, compilers can do awesome stuff, so “no need for new features in JS”(and then if we did, wasm would take over in web development, or browsers would overcome ES and use something else instead). --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Proposal: [Symbol.equals]
What about having Symbol.equals?
For example, for now this is what it does:
```js
class Position {
constructor(o) {
this.x = o.x instanceof Number ? o.x : 0
this.y = o.y instanceof Number ? o.y : 0
this.z = o.z instanceof Number ? o.z : 0
}
}
console.log(new Position({x: 10, y: 10, z: 10}) === new Position({x: 10, y: 10,
z: 10})
```
Output is of course, false.
With `Symbol.equals`, we could make it easier, instead of
`instance.equals(otherInstance)`.
For example:
```js
class Position {
[Symbol.equals](oIn) {
return oIn.x === this.x && oIn.y === this.y && oIn.z === this.z
}
constructor(o) {
this.x = o.x instanceof Number ? o.x : 0
this.y = o.y instanceof Number ? o.y : 0
this.z = o.z instanceof Number ? o.z : 0
}
}
console.log(new Position({x: 10, y: 10, z: 10}) === new Position({x: 10, y: 10,
z: 10})
```
Now output would be true.
This would save most of the time, instead of writing .equals and then
surrounding everything with ().
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: Class Templates
But then `Abc(4, 5, 6) !== Abc(4, 5, 6)`. Using `Abc.constructor = class Abc$
{}` and then returning `Abc.constructor` won’t make it work.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: Class Templates
Also, using `new (Abc(4, 5, 6))(1, 2, 3)` causes error ` Uncaught TypeError: Abc(...) is not a constructor`. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: Class Templates
You could use ```js new Abc`abc`(‘abc’) ``` But you could only use strings. What about constructors? You would need to use ```js const thatConstructor = (new Function(‘return ’ + t))() ``` But it would only give what is defined in that constructor. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: Class Templates
Yes, you can do that. But then doesn’t that look ugly? `new (Abc(1, 2, 3)(4, 5, 6)`, vs `new Abc<4, 5, 6>(1, 2, 3)`. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: Class Templates
“Strongly typed” Strongly typed is not Statically typed. Python is strongly typed for example. Strongly typed language means that `”something” + 1` will throw error, Weakly typed means that `”something” + 1` will turn `1` into string and add it to `something`, which will result in `something1`. Statically typed language means that once you do `Boolean Abc = true`, or `let Abc: Boolean = true`, you can’t change it to number, but you can change it to `false`, or `true`. Did you mean Statically typed language? Also, I think that there can be usefulness in class templates, without language being Statically typed. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: Symbol Linked to `typeof`
I could definitely see usage of this when using custom Constructors. But this
could confuse current code of JS:
```js
function A(B, C) {
if(typeof B === ‘string’) // ...
}
A({[Symbol.typeof]: ‘string’})
```
This would make new code to use not only `typeof B === ‘String’`, but also `B
instanceof ‘String’`.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
