Thoughts on Native namespaces and constructors #2204

warning! You can't really splat a constructor, I'm afraid.
You can mostly fake it:

// var client = new Client(...args);
var client = function(func, args, ctor) {
  ctor.prototype = func.prototype;
  var child = new ctor, result = func.apply(child, args), t;
  return (t = typeof result)  == "object" || t == "function" ? result || child : child;
})(Client, args, function(){});

But it's an incomplete shim and won't work with "special constructors" like Date's.

See jashkenas/coffeescript#2183

Yeap, it's annoying, which is why our switch/case statement would have to cover the first x-number of args, and then resort to a faked subclass or similar.

The above example code also does not take into account blocks, so if one is given to #new, then we would want to append that to args as well.

Alright, just wanted to make sure you didn't fall into the same trap I did once!

Everything looks right. The only thing that comes to mind is whether Native has any constant already defined that can shadow other stuff, pretty minor though.

@adambeynon I'm pretty sure $$.Faye.Client should work.

@meh The .Client bit breaks it. As Client is actually a function, Native tries to call it - it actually needs to be called as a constructor with new. Also, in this case Faye is an object, in some other client libs the "namespace" is sometimes also a function, which tries to get called.

@adambeynon ah yeah, forgot about those things.

rest arguments allow this natively:

> A = function(a,b){console.log(a,b,arguments)};
< function (a,b){console.log(a,b,arguments)}
> a = [1,2,3,4]; new A(...a)
[Log] 1 – 2 – Arguments [1, 2, 3, …] (4)
Arguments [1, 2, 3, 4]Arguments (4)
< A {}

My idea would be to leave Native as-is and deprecate it while we work on a new alternative version of Native. Below I paste my other ideas regarding a new Native module from the Opal Slack channel:

A question to you all, there's a method Kernel#Native provided by the "native" module. Everything works fine, it wraps a JS object into a nice Ruby-working thing, but
if an object is bridged, it of course returns the bridged object. In opal-browser we actually don't bridge, but wrap the objects ourselves
now the first question is, what if we add a method like

Native.for `HTMLElement` do |i|
   Browser::DOM::Element.new(i)
end

so that when a person does

Native(`document.getElementById("test")`)

he will be given a Browser::DOM::Element instead of Native::Object?
the second question is sort of more complicated... Ruby is mostly standarized on use of snake_case while JS on camelCase. I know it wasn't a case when Opal was first conceived but... what if Native actually took that into mind? the answer is probably an astounding no, because we already rely on the behavior of Native as-is. the idea is rather to create a new version of Native, say Native2 or N that would take those things into mind and create a more robust representation of internal JS objects?