[ANN] noxe - fully type-safe node.js for Haxe (alpha)

[TheHippo]

Hi,

I am currently working together with Juraj (aka back2dos) on a type-safe wrapper for node.js. Today this project reached a status where we think this could be interesting for other people and we would love to get some feedback/ideas/reviews/suggestions.

The source could is currently only available on Github: https://github.com/42labs/noxe 

Why we think noxe it better then other wrappers before:

• it's type-safe. If a node function could accept different types for an argument there will be different functions for this instead of just accepting Dynamic . This is all done by some macro magic so there will be no runtime overhead.
• Events are handled the way events should work in Haxe. Instead of object.on("something", ...) noxe will generate a function for you (that also will be available for auto-completion) object.watchSomething(...). And of course the parameters of the events will be fully typed too. [Example]
• You do not need to require a node module if you want to use its functionality, just use the classes.

If you are interested in this feel free to test, contribute and give us some feedback. I tried to make the readme comprehensive enough so everyone is able to do something with noxe.

Philipp

[Franco Ponticelli]

This is very interesting. If I can find the time I want to see if I can use your effort to make UFront work with your lib.

Franco

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

[Nicolas Cannasse]

Le 06/06/2012 19:52, TheHippo a �crit :

> Hi,
>
> I am currently working together with Juraj (aka back2dos) on a type-safe
> wrapper for node.js. Today this project reached a status where we think
> this could be interesting for other people and we would love to get some
> feedback/ideas/reviews/suggestions.
>
> The source could is currently only available on Github:
> https://github.com/42labs/noxe
>
> Why we think noxe it better then other wrappers before:
>

> * it's type-safe. If a node function could accept different types for

> an argument there will be different functions for this instead of
> just accepting Dynamic . This is all done by some macro magic so
> there will be no runtime overhead.

Just a question : what's the reasons for using macros instead of
@:overload ?

Best,
Nicolas

[ritchie turner]

Glad to see more interest in this space.

As Nicolas mentioned @overload does a pretty good job at covering most of typing issues on multiple arguments, so the api is pretty well covered on the typesafe front.

bd.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

-- 
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci

[Justin Donaldson]

Yep, I've had good luck with it as well.. a recent nightly enabled parameters in the overloads.  It's a great fit for externing js libraries.

http://code.google.com/p/haxe/issues/detail?id=627

I'm finishing up a d3 extern that utilizes this soon... it's pretty amazing to code js like this... especially with the new "minimizing" js output options.

-Justin

blog: http://www.scwn.net
aim: iujjd
twitter: jjdonald

[Juraj Kirchheim]

On Wed, Jun 6, 2012 at 9:01 PM, Philippe Elsass
<philipp...@gmail.com> wrote:
> Sounds great!

>
>> Just a question : what's the reasons for using macros instead of
>> @:overload ?

> <troll>Hum, because Juraj is involved? ;P</troll>

Of course ;)

The drive to reinvent the wheel aside, the primary reason we didn't
just stick with Ritchie's work, is that we want full type safety,
starting with events. The way we achieved this would be very tedious
without macros,

Now with macros in place, there was the option to @:overload or not to
@:overload. Personally I've always felt @:overload to be rather alien
and there has been a number of issues with it. Choosing descriptive,
non-ambiguous names seemed like a sensible alternative to explore.

Either way, the library is currently in a very early stadium. We'll be
soon using it for two projects, which will give us the chance to
actually learn something about our design decisions.

Regards,
Juraj

[Nicolas Cannasse]

Le 07/06/2012 13:44, Juraj Kirchheim a �crit :

> On Wed, Jun 6, 2012 at 9:01 PM, Philippe Elsass
> <philipp...@gmail.com> wrote:
>> Sounds great!
>>
>>> Just a question : what's the reasons for using macros instead of
>>> @:overload ?
>> <troll>Hum, because Juraj is involved? ;P</troll>
>
> Of course ;)
>
> The drive to reinvent the wheel aside, the primary reason we didn't
> just stick with Ritchie's work, is that we want full type safety,
> starting with events. The way we achieved this would be very tedious
> without macros,
>
> Now with macros in place, there was the option to @:overload or not to
> @:overload. Personally I've always felt @:overload to be rather alien
> and there has been a number of issues with it. Choosing descriptive,
> non-ambiguous names seemed like a sensible alternative to explore.

Yes for the record @:overload was introduced quite recently and suffered
several issues. We have improved it recently and we will make it a
strong feature, since it is necessary for interoperability reasons for
C# and Java.

Best,
Nicolas

[Laurence Taylor]

Middleware tends to attach things to the request object, is that one of the use cases you have covered?

regards,

Laurence

[Juraj Kirchheim]

I'm not sure what you mean, so the answer is probably "no". If you
could send me some links on this, I'll be happy to look into how this
can be done ;)

Regards,
Juraj

[Laurence Taylor]

here, if you look under the 'Route' heading, you'll notice that passport has left a user field on request that is used for serialization / deserialization once a session has been authorised.

I think it's the way state is generally done in node, using middleware to either modify known state, which types can reasonably handle, and to add namespaces, which seems a good deal more complicated using regular inheritance.

regards,

Laurence

[Laurence Taylor]

Iv'e been thinking about this and traits in general, and to do things like typed clone / copy, and say

class Node<T:NodeHttpReq,U:NodeHttpResp>

so that the leaf classes as implemented can make use of it.

The traits implementation in scuts had a nice syntax, so that

class Traited implements Trait{

 public function somefunction(){

  //implementation 

 }

}

Is valid syntax, and the autobuild on Trait strips out the method implementation and then reattaches it later on.

The complicated part comes whilst using type annotations

public function somefunction(v:T){//implementation}

would require that the macro follow the params through the hierarchy and find the concrete type.

Once that is done, I think one could replace that concrete type with <NT : ConcreteType >, so that each class can

have properly typed parameters / returns whilst allowing any subclasses to do the same.

regards,

Laurence

[TheHippo]

Create a subclasses and add the stuff added by the middleware.

So instead of function(request:noxe.http.ServerRequest, response:noxe.http.ServerResponse) you could do function(request:middleware.ServerRequest, response:middleware.ServerResponse) The middleware classes could extend the original noxe/node.js "classes" or just define their own if the differences are to big.

[Laurence Taylor]

I'll go rtfm, cheers :)

--