is it possible to create your own condition/control flow syntax in js? for example:
when( condition ) {
// execute code
}
this would add some sort of listener to a variable/object and execute whenever the condition is true.
I may just have to create my own programming language.
This is actually two questions:
Can syntax be added to JavaScript directly?
Can I set up code that runs when a condition changes?
The answer to the first is no. You can use preprocessing like sweet.js macros to accomplish that but its non-trivial.
The answer to 2 is yes, you can accomplish this in any ES 5 compliant environment (IE 9+):
var condition = {val: null};
Object.defineProperty(condition, "isTrue", {
set: function(val) {
if (val && !this.val) {
runSomeCodeYouWantRun();
}
this.val = val;
},
get: function() {
return this.val;
}
});
So whenever any code changes condition.isTrue the specified code will be run if the change is truthy. But for situations like this I prefer less ad-hoc approach. ES 2015 Proxy traps make this much cleaner (IMHO) but support isn't quite there yet. What you really are looking for here to get the job done today is an Observable.
Also note that writing a language to solve a problem like this is roughly equivalent to building a car out of spare parts to drive to the store for groceries. Just buy a car.
Welcome to the wonderful world of JavaScript transpilers.
JavaScript in and of itself does not have any utilities for creating your own syntax. In response to this, many tools exist online and in the NPM repositories that add just this sort of feature to JS by translating it to browser-compatible JavaScript. Here's a small sampling:
Babel.js adds ES6 syntax to ES5 JavaScript
Browserify adds Node.JS's require() functionality
Uglify.JS compresses JS into the smallest form possible that will still execute the same way
TypeScript (while more technically its own language) adds static type-checking to JavaScript
All of these transpilers, however different, all work the same way: they parse the source file(s) to an abstract syntax tree (or AST), run some transformations on that tree, and then spit out the resulting JavaScript file. If you wanted to create your own special syntax in JavaScript, you would do more or less the same thing. (Uglify.JS stands out as being particularly customizable in this regard).
All of that said, none of these transpilers fundamentally change the way that JavaScript works - you still have to translate whatever fancy syntax you want to use into plain, browser-executable JavaScript. This means that although you will be able to write your when(){} block syntax, the expression inside the parentheses cannot be a simple Boolean expression, but must involve something like an Observable object that inserts a callback (Knockout.JS does have a tool for doing this out of an expression built from its Observables).
Related
I understand the scoping rules of Node/JavaScript, and from, for example, Understanding Execution Context and Execution Stack in Javascript, I think I understand the principle of how Execution Contexts work: the question is can you actually get access to them?
From an answer to the 2015 question How can I get the execution context of a javascript function inside V8 engine (involving (ab)using (new Error()).stack), and the answer to the 2018 question How can we get the execution context of a function?, I suspect the answer is "no" but just in case things have changed: is it possible to access/modify the Execution Context of a Node module/function?
(I'm very aware this screams either XY Problem or a desire to abuse Node/JavaScript: hopefully the Background section below will provide more context, and – if there's a different way of achieving what I want – that will work as well.)
In a nutshell, I want to achieve something like:
sharedVar = 1 ;
anotherModule.someFunction() ;
console.log( sharedVar ) ; // Where 'sharedVar' has changed value
Having a function in a different module being able to change variables in its caller's scope at will seems the definition of "A Dangerous Thing™", so – if it's possible at all – I expect it would need to be more like:
sharedVar = 1 ;
anotherModule.hereIsMyExecutionContext( SOMETHING ) ;
anotherModule.someFunction() ;
console.log( sharedVar ) ; // Where 'sharedVar' has changed value
and anotherModule would be something like:
let otherExecutionContext ;
function hereIsMyExecutionContext( anExecutionContext ) {
otherExecutionContext = anExecutionContext ;
}
function someFunction() {
//do something else
otherExecutionContext.sharedVar = 42 ;
}
and the question becomes what (if anything) can I replace SOMETHING with?
Notes / Things That Don't Work (for me)
You shouldn't be trying to do this! I realize what I'm trying to achieve isn't "clean" code. The use-case is very specific, where brevity (particularly in the code whose value I want changing) is paramount. It is not "production" code where the danger of forgotten, unexpected side-effects matters.
Returning a new value from the function. In my real use-case, there would be several variables that I would like someFunction() to be able to alter. Having to do { var1, var2, ... varN } = anotherModule.someFunction() would be both inconvenient and distracting (while the function might change some of these variables' values, it is not the main purpose of the function).
Have the variables members of anotherModule. While using anotherModule.sharedVar would be the clean, encapsulated way of doing things, I'd really prefer not to have to use the module name every time: not only is it more typing, but it distracts from what the code that would be using these variables is really doing.
Use the global scope. If I wasn't using "use strict";, it would be possible to have sharedVar on the global object and freely accessible by both bits of code. As I am using strict-mode (and don't want to change that), I'd need to use global.sharedVar which has the same "cumbersomeness" as attaching it to anotherModule.
Use import. It looks like using import { sharedVar } from anotherModule allows "live" sharing of the variables I want between the two modules. However, by using import, the module using the shared variable has to be an ES Module (not a CommonJS Module), and cannot be loaded dynamically using require() (as I also need it to be). Loading it dynamically the ESM way (using import() as a function returning a promise) appears to work, but repeated loadings come from a cache. According to this answer to How to reimport module with ES6 import, there isn't a "clean" way of clearing that cache (cf. delete require.cache[] that works with CommonJS modules). If there is a clean way of invalidating a cached ESM loaded through import(), please feel free to add an answer to that question (and a comment here, please), although the current Node JS docs on ESMs don't mention one, so I'm not hopeful :-(
Background
In early December, a random question on SO alerted me to the Advent of Code website, where a different programming problem is revealed everyday, and I decided to have a go using Node. The first couple of problems I tackled using standalone JS files, at which point I realized that there was a lot of common code being copy-pasted between each file. In parallel with solving the puzzles, I decided to create a "framework" program to coordinate them, and to provide as much of the common code as possible. One goal in creating the framework was that the individual "solution" files should be as "lean" as possible: they should contain the absolute minimum code over that needed to solve the problem.
One of the features of the framework relevant to this question is that it reloads (currently using require()) the selected solution file each time, so that I can work on the solution without re-running the framework... this is why switching to import and ES Modules has drawbacks, as I cannot (cleanly) invalidate the cached solution module.
The other relevant feature is that the framework provides aoc.print(...) and aoc.trace(...) functions. These format and print their arguments: the first all the time; the second conditionally, depending on whether the solution is being run normally or in "trace" mode. The latter is little more than:
function trace( ... ) {
if( traceMode ) {
print( ... )
}
}
Each problem has two sets of inputs: an "example" input, for which expected answers are provided, and the "real" input (which tends to be larger and more involved). The framework would typically run the example input with tracing enabled (so I could check the "inner workings") and run the "real" input with tracing disabled (because it would produce too much output). For most problems, this was fine: the time "wasted" preparing the parameters for the call, and then making the call to aoc.trace() only to find there was nothing to do, was negligible. However, for one solution in particular (involving 10 million iterations), the difference was significant: nearly 30s when making the ignored trace; under a second if they calls were commented-out, or I "short-circuited" the trace-mode decision by using the following construct:
TRACE && aoc.print( ... )
where TRACE is set to true/false as appropriate. My "problem" is that TRACE doesn't track the trace mode in the framework: I have to set it manually. I could, of course, use aoc.traceMode && aoc.print( ... ), but as discussed above, this is more to type than I'd like and makes the solution's code more "cluttered" than I'd ideally want (I freely admit these are somewhat trivial reasons...)
One of the features of the framework relevant to this question is that it reloads the selected solution file each time
This is key. You should load not leave the loading, parsing and execution to require, where you cannot control it. Instead, load the file as text, do nefarious things to the code, then evaluate it.
The evaluation can be done with eval, new Function, the vm module, or by messing with the module system.
The nefarious things I was referring to would most easily be prefixing the code by some "implicit imports", whether you do that by require, import or just const TRACE = true;. But you can also do any other kind of preprocessing, such as macro replacements, where you might simply remove lines that contain trace(…);.
Looks like you're heading the wrong way. The Execution Context isn't meant to be accessible by the user code.
An option is to make a class and pass its instances around different modules for your purpose. JS objects exist in the heap and can be accessed anywhere as long as you have its reference, so you can control it at will.
I have to use this.state.<name> multiple times, how should I replace it with a simple variable name? Like we use global variables in other languages such as C, C++.
#Thomas yes, but there are a lot of functions in my code and even many items inside state for which i want shorter alias. So it is not ideal to do it with "const" in all functions. so by the word "globally", i meant how to declare those shorter alias only once ?
you can't. Javascript simply doesn't provide that feature.
JavaScript as a Language doesn't have the compile-step where these aliases would be filled in with the real commands.
There are preprocessors, like babel for wich you could write a plugin.
There are task-runner like gulp for wich you could write a script to build that aliasing syntax (although it's most likely not valid JS)
You can check out sweet.js maybe its functionalities already get you covered.
But maybe you'd consider learning JavaScript; realizing that JavaScript is not C and that you can't just transfer your coding style 1:1.
imo. the best Solution to get a bunch of shorter handles is Object destructuring. But this ain't aliases either; you need to understand what JS does here, and what the limits to this are.
Don't be too lazy to write a few more characters. Every modern JS IDE has an autocompletiton feature.
You can so something like this in render.
const { name } = this.state;
return(
<div>{name}</div>
)
Now you can use it just with name as many times you want in render as well you can do in methods.
It is not like creating alias but we can optimize code.
Let's say you would get a bunch of .js files and now it is your job to sort them into groups like:
requires at least JavaScript 1.85
requires at least E4X (ECMAScript 4 EX)
requires at least ECMAScript 5
or something like this.
I am interested in any solution, but especially in those which work using JavaScript or PHP. This is used for creation of automated specifications, but it shouldn't matter - this is a nice task which should be easy to solve - however, I have no idea how and it is not easy for me. So, if this is easy to you, please share any hints.
I would expect something like this - http://kangax.github.com/es5-compat-table/# - just not for browsers, rather for a given file to be checked against different implementations of JavaScript.
My guess is, that each version must have some specifics, which can be tested for. However, all I can find is stuff about "what version does this browser support".
PS: Don't take "now it is your job" literally, I used it to demonstrate the task, not to imply that I expect work done for me; while in the progress of solving this, it would be just nice to have some help or direction.
EDIT: I took the easy way out, by recquiring ECMAScript 5 to be supported at least as good as by the current FireFox for my projekt to work as intendet and expected.
However, I am still intereseted in any solution-attemps or at least an definite answer of "is possible(, with XY)" or "is not possible, because ..."; XY can be just some Keyword, like FrameworkXY or DesignPatternXY or whatever or a more detailed solution of course.
Essentially you are looking to find the minimum requirements for some javascript file. I'd say that isn't possible until run time. JavaScript is a dynamic language. As such you don't have compile time errors. As a result, you can't tell until you are within some closure that something doesn't work, and even then it would be misleading. Your dependencies could in fact fix many compatibility issues.
Example:
JS File A uses some ES5 feature
JS File B provides a shim for ES5 deficient browsers or at least mimics it in some way.
JS File A and B are always loaded together, but independently A looks like it won't work.
Example2:
Object.create is what you want to test
Some guy named Crockford adds create to Object.prototype
Object.create now works in less compatible browsers, and nothing is broken.
Solution 1:
Build or find a dependency map. You definitely already have a dependency map, either explicitly or you could generate it by iterating over you HTML files.
Run all relevant code paths in environments with decreasing functionality (eg: ES5, then E4X, then JS 1.x, and so forth).
Once a bundle of JS files fail for some code path you know their minimum requirement.
Perhaps you could iterate over the public functions in your objects and use dependency injection to fill in constructors and methods. This sounds really hard though.
Solution 2:
Use webdriver to visit your pages in various environments.
Map window.onerror to a function that tells you if your current page broke while performing some actions.
On error you will know that there is a problem with the bundle on the current page so save that data.
Both these solutions assume that you always write perfect JS that never has errors, which is something you should strive for but isn't realistic. This might; however, provide you with some basic "smoke testing" though.
This is not possible in an exact way, and it also is not a great way of looking at things for this type of issue.
Why its not possible
Javascript doesn't have static typing. But properties are determined by the prototype chain. This means that for any piece of code you would have to infer the type of an object and check along the prototype chain before determining what function would be called for a function call.
You would for instance, have to be able to tell that $(x).bind() o $(x).map are not making calls to the ecmascript5 map or bind functions, but the jQuery ones. This means that you would really have to parse out the whole code and make inferences on type. If you didn't have the whole code base this would be impossible. If you had a function that took an object and you called bind, you would have no idea if that was supposed to be Function.prototype.bind or jQuery.bind because thats not decided till runtime. In fact its possible (though not good coding practice) that it could be both, and that what is run depends on the input to a function, or even depends on user input. So you might be able to make a guess about this, but you couldn't do it exactly.
Making all of this even more impossible, the eval function combined with the ability to get user input or ajax data means that you don't even know what types some objects are or could be, even leaving aside the issue that eval could attempt to run code that meets any specification.
Here's an example of a piece of code that you couldn't parse
var userInput = $("#input").val();
var objectThatCouldBeAnything = eval(userInput);
object.map(function(x){
return !!x;
});
There's no way to tell if this code is parsing a jQuery object in the eval and running jQuery.map or producing an array and running Array.prototype.map. And thats the strength and weakness of a dynamically typed language like javascript. It provides tremendous flexibility, but limits what you can tell about the code before run time.
Why its not a good strategy
ECMAScript specifications are a standard, but in practice they are never implemented perfectly or consistently. Different environments implement different parts of the standard. Having a "ECMAScript5" piece of code does not guarantee that any particular browser will implement all of its properties perfectly. You really have to determine that on a property by property basis.
What you're much better off doing is finding a list of functions or properties that are used by the code. You can then compare that against the supported properties for a particular environment.
This is still a difficult to impossible problem for the reasons mentioned above, but its at least a useful one. And you could gain value doing this even using a loose approximation (assuming that bind actually is ecmascript5 unless its on a $() wrap. Thats not going to be perfect, but still might be useful).
Trying to figure out a standard thats implemented just isn't practical in terms of helping you decide whether to use it in a particular environment. Its much better to know what functions or properties its using so that you can compare that to the environment and add polyfills if necessary.
One of the problems, for some of us, with Javascript is the lack of operator overloading. This makes writing numeric libraries awkward. For instance, we might want to write something like:
var a = new BigInteger(5);
var b = new BigInteger(10);
var c = a + b;
A possible solution is to transpile a language with operator overloading to Javascript. While feasible -- by replacing operators by function calls and type checks -- the consensus seems to be that this is impossible without killing performance. CoffeeScript has rejected the idea for this reason:
https://github.com/jashkenas/coffee-script/issues/846
But are there really no clever solutions?
For instance, it might be possible hoist type checks out of tight loops or to use some other pipeline where modern JS compilers can optimize away added cruft when the types are numeric.
Ideas?
Are you really sure you need your big numbers to be useable by old functions written with normal numbers in mind (that use the traditional operators)? If you only need the overloading for your own convenience on functions you cave control over you might be able to get by by using a different, custom operator for bignums.
For example, you could write a compiler to safely convert
var d = a <+> b <*> c;
into
var d = (a).add((b).multiply(c));
or perhaps, if you want automatic conversions...
var d = toBignum(a).add(toBignum(b).multiply(toBignum(c)));
I don't really see you being able to force overloading on an existing implementation without a big hassle. While you could teoretically replace all occurences of + with <+> and so on, current Javascript implementations are not optimized for this and I don't even want to start thinking what would happen if you tried to pass a bignum to one of the native C++ functions that are under the hood.
edit: Not needing to override the base integer class is the important point here (note how in the link you gave, overriding is the first thing the guy wants...). I don't think you will be able to find some kind "magic" optimization though as you have no control over which of the many JS implementations is being used by the client.
If you really don't like a custom operator like <+> the only way to distinguish a normal + operator (you shoudln't meddle with) from a fancy + operator (you want to do bignum stuff with) would be forcing some kind of ad-hoc typing system on top of Javascript, perhaps via comments, custom syntax or (as mentioned in a comment) hungarian notation. Just settling for a custom operator name you hate less would be less hackish, IMO.
Have a look how Scala implemented Operator Overloading:
They defined that every operator is a method call on an object, so your example would be:
var c = a["+"](b);
If you stop here, you could trivially implement method overload, the function would have to check the values passed by param. If you want to develop a better solution take Odersky's Programing in Scala book and some time to read all their ideas how they've solved the problem (which is a very nice solution!)
Is there a way to enforce types in JavaScript? I'm thinking of a pre-processor which takes an input file written in ActionScript 3 or Java and converts it to JS.
I do not need a big run-time apparatus, I just need to introduce the idea of compile-time in my workflow and run the trivial compile-time checks on my code (and also use interfaces). Neither I need the API from Java or Flex, just the syntax.
The standard browser-functions could also be checked against the IDL definitions, but it is not a must.
Whilst I'm a little late to this party, I think it's definitely worth mentioning Dart (which is a Google product) and TypeScript (which is a Microsoft product).
JavaScript is fast becoming an extremely popular language as applications become more web based. However as you have pointed out, JavaScript lacks type safety, and to name a few other things; classes, interfaces and packages/namespaces/modules.
This is where Dart and TypeScript step in. These languages are essentially supersets of JavaScript. When you write Dart or TypeScript code, it is compiled into clean, standards compliant JavaScript.
The benefits of Dart and TypeScript are that they provide type safety, interfaces, classes etc. Thus allowing you to write cleaner, scalable, manageable applications, which still run in the browser.
Being a Microsoft oriented programmer, I've had a lot of experience with TypeScript, including being somewhat active in the development of the language (you can find information for TypeScript development at codeplex)
My only concern at the moment is that TypeScript is lacking in some fundamental features. It seems that some of the current implementation (0.9.0 alpha) has some equally gaping holes that might deter the savvy developer from using it at the moment (subject to change of course).
I cannot really comment on Dart, as I have only used this a few times, but my overall experience with Dart was good!
You should take a look at the haxe project.
Haxe is a very nice typed language that uses type inference (i.e. you're not forced to write a lot of type declarations) but that enforces type correctness at compile time.
The language has a javascript-like syntax and the compiler can generate code for the neko virtual machine, for javascript, as3, c++ or PHP.
Update
Today the most popular choice is probably Typescript, a superset of Javascript that allows optional type declarations that are enforced compile time.
GWT does what looking for, but its a way oversized for the most cases. You could take a look at googles closure framework which fakes the typed safe with anotations
There are many statically-typed languages that are designed with the specific goal of compiling down to JavaScript (the so-called assembly of the web):
Flow by Facebook
Dart by Google
TypeScript by Microsoft
JXS by DeNA
While typeof will return 'object' for every object or array, you can use the instanceof statement. Say you have a class Person, and want to see whether the object passed to your function is a Person, you can do this:
function someFunc(person){
if(! person instanceof Person)
throw('argument needs to be an instance of Person.');
/* ... do your stuff ... */
}
If you just want to make sure a variable is the number 3 instead of a string '3', you only need to use === instead of ==:
if( var === 3 ){
/* ... do your stuff ... */
}
I agreed that Javascript is a beautiful language, with some glaring holes, the worst and most unremarked of which is the absence of static type-safety.
As eskimoblood pointed out, there are some half-measures in the form of GWT and Closure but the right answer, imo, is Scala, which combines Javascript's flexibility and expressive power with a type system much better than Java's -- or that would be the right answer except that the Scala-GWT project seems to have gotten bogged down.
For now, we wait...
Infernu is a type-safe subset of JavaScript. It doesn't compile into JavaScript - it can run as-is in your browser! The type checker supports full type inference, so no type annotations are needed (in the future they will be supported for documentation and for deliberate distinction between structurally identical types). It isn't ready yet for usage, but a work in progress.
Here's a lightweight typesafe function wrapper for nodejs/browser:
https://www.npmjs.com/package/typeshave
Its 3.9K gzipped, supports jsonschema, and works pretty much everywhere. So:
foo = function(bar){
}
could be rewritten like so:
foo = typesafe({
bar: { type: "object" }
}, function(bar){
}
Or just wrapped later on, including validating deepnested structures, and optional args:
foo = typesafe({
bar: {
type: "object",
required: true,
properties: {
foo: { type: "string", required:true },
items: [{
type: "integer"
}]
}
}
}, foo );
foo({ foo: "helloworld", items:[1,2,3] });
It looks less noisy in coffeescript imho