On Mon, Oct 22, 2012 at 6:10 PM, Andrew Grieve wrote:
> Not sure I follow your intended purpose for the "header files". Are they
> for documentation purposes?
>
Here's the typescript "header file" for node.js:
http://typescript.codeplex.com/SourceControl/changeset/view/fe3bc0bfce1f#samples%2fn
Patrick,
Not sure I follow your intended purpose for the "header files". Are they
for documentation purposes?
docs for CC interfaces:
https://developers.google.com/closure/compiler/docs/js-for-compiler#tag-interface
On Mon, Oct 22, 2012 at 3:43 PM, Brian LeRoux wrote:
> > My primary interest
> My primary interest here would be to do something similar to what Isaac was
> suggesting: have a separate "header file" (prolly header-file-per-plugin)
> that describes the API of the plugin using a typed description language.
> Then make use of that typed information in various ways.
FWIW, the
On Mon, Oct 22, 2012 at 10:05 AM, Andrew Grieve wrote:
> I'm well accustomed to writing typed JS from my past experience with
> Closure Compiler. I haven't looked enough at TypeScript yet to know which
> tool might give better type checking, but if people are interested in type
> checking, it'd be
On Mon, Oct 22, 2012 at 10:04 AM, Gord Tanner wrote:
> My main idea with sweet.js would be to replace a couple of the build time
transforms we already do in cordova.js:
>
> module.exports = {
> };
>
> to
>
> define("filename", function (require, define, module) {
> module.exports = {
> }
Don't want to see this veer into a huge theory discussion. FTR I
really like Typescript approach but I do not want barriers (real or
imagined) to contribution so from my perspective its out.
Now that said, I really love the concepts in Traceur and SweetJS and
fully support prototyping to remove bo
If it's for making ES6 features work with older JS engines, then I'm for
it. The first example on sweetjs.org is for making JS look like python
though.
Are you saying you want to use syntax like
http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples
and then sweetjs can be used in the co
Just a friendly nudge away from typescript ;) Sweet.js has nothing to do
with typescript.
The idea is more for using macro's to add new and upcoming syntax support
to our javascript layer.
On Mon, Oct 22, 2012 at 10:28 AM, Braden Shepherdson wrote:
> From my indirect knowledge of TypeScript, I
>From my indirect knowledge of TypeScript, I think one of its major points
is that it's a strict superset of JS. That means that normal JS is valid
TypeScript, so it can be used with other libraries and tools that are plain
JS.
On Mon, Oct 22, 2012 at 10:05 AM, Andrew Grieve wrote:
> Sounds like
Sounds like a fun discussion :)
There are two things about sweet.js that make me iffy about it:
1. Looks like it might make our code look not like JS, and contributors
would need to learn a new language to figure out what's going on
2. It might make it easier to write bloated code
I think if we r
Yes, the TypeScript comment was trolling ;)
My main idea with sweet.js would be to replace a couple of the build time
transforms we already do in cordova.js:
module.exports = {
};
to
define("filename", function (require, define, module) {
module.exports = {
};
};
as well as the version
There was some chit-chat on Twitter this weekend about using the sweet.js
[1] macro processor in Cordova. Somehow. Not quite sure how. Also, a - I
believe trolling - mention of using TypeScript [2]. Somehow.
I'd be interested in hearing more about either.
w/r/t TypeScript - note that Isaac Sc
12 matches
Mail list logo
