<adambeynon>
yeah, thats due to bridged classes. we cant really overcome that limitation
<adambeynon>
or not easily, anyway
<meh`>
I see
GitHub43 has joined #opal
GitHub43 has left #opal [#opal]
<GitHub43>
[opal-rails] boberetezeke opened pull request #12: Update the readme to specify the correct spec directory (master...master) http://git.io/h8kXTg
<adambeynon>
meh`: how much need is there for Native::Array ?
<meh`>
adambeynon, quite a lot
<meh`>
there are many array-like objects
<meh`>
arguments is one
<meh`>
and in the DOM API there are a fuckton
<meh`>
adambeynon, any way to run opal-repl with phantomjs?
<adambeynon>
meh`: no - couldnt figure out a good way to do it
<meh`>
snab
<adambeynon>
meh`: opal-parser.js can run code from script tags
<adambeynon>
if you want a quick browser test of something
<meh`>
nah, I can test it another way
<meh`>
adambeynon, when are we doing the corelib stdlib move?
<adambeynon>
meh`: cant we move Native::Array to opal browser?
<meh`>
adambeynon, it's useful outside of it
<meh`>
it's not uncommon in javascript to return array-like objects
<adambeynon>
I really dont think so. we are not going to start making wrappers for every lib out there
<adambeynon>
opal-browser is the exception
<meh`>
adambeynon, trust me, it's a common pattern
<adambeynon>
fine, but Native::Array isnt something that belongs in opal core
<meh`>
why not?
<meh`>
it's just few lines anyway, and the pattern is present in the core of javascript
<meh`>
arguments is just one example
<adambeynon>
why would we ever need to wrap `arguments`?
<meh`>
no clue, but there are other examples with stuff like typed arrays
<meh`>
they're part of the core language
elia has quit [Ping timeout: 245 seconds]
<adambeynon>
so are for and for-in loops, but we dont want to start offering a wrapper for those ^_-
<meh`>
it's not the same
<meh`>
in javascript you can have array-like objects, and you don't need to care about it being a real or not array
<meh`>
because you use a for loop using the length attribute
<meh`>
and if it's accessed using other functions on the object
<meh`>
you don't care all the same
<meh`>
because you use a for loop
<meh`>
in Ruby it has to be an Enumerable
<meh`>
and Native::Array does it
<meh`>
prototypejs had $A that converted array like objects to real arrays
<meh`>
but we don't need to create a real array out of it, since we have Enumerable
<adambeynon>
so, we are creating an abstraction on top of another abstraction of an array
<meh`>
array-like objects aren't an abstraction
<meh`>
they're common in javascript
<meh`>
for instance, you can pass an array-like object to Function.prototype.apply
<meh`>
they're pervasive in the language
<meh`>
and it needs a specific wrapper
<adambeynon>
right, but I dont get why we need a specific wrapper for those sort of objects in opal?
<[spoiler]>
I think jQuery() returns an array-like object
<meh`>
adambeynon, because it's pervasive in the language
<meh`>
adambeynon, you don't use native, and that's fine, but that doesn't mean it doesn't belong in the core
<meh`>
if something is part of javascript, it should be available in some way or another
<meh`>
and native wrapping is useful if you don't have or don't want to use a full blown wrapper
<meh`>
also what [spoiler] said, jQuery returns an array-like object
<meh`>
and it's not just jQuery, it's also in the core of the language
<adambeynon>
Native should be a very minimal class: #method_missing, #[], #[]=, #include?
<meh`>
it's a pervasive pattern
<adambeynon>
thats all we need Native to do
<[spoiler]>
Well, it's not very common, AFAIK and I only ever used it twice myself (and I work often with JS). However, I can't see why you need that in opal/ruby
<adambeynon>
if you are actually digging deeper, and trying to use these very small parts of javascript like passing array-like objects to slice() and call() and apply() etc, then some wrapper isnt going to help, and its probablly better writing that code in javascript anyway
<meh`>
[spoiler], I think you might be dealing with those objects and not realize it :)
<[spoiler]>
meh`: I rarely use libraries, though. Got an example where vanilla JS uses those?
<meh`>
[spoiler], typed arrays, arguments, most of the DOM stuff
<meh`>
the DOM is full of array like objects
<[spoiler]>
Oh, I never realised arguments were array-like. I always figured they were just an array
<meh`>
nope
<[spoiler]>
and typed-arrays is a godo example actually, yeah
<[spoiler]>
good*
<adambeynon>
so, class TypedArray < Native; include Enumerable; def each; ...; end; end
<meh`>
adambeynon, that's not enough, and it shouldn't be a child of Native but include Native::Base like it does now
DouweM has quit [Ping timeout: 260 seconds]
<adambeynon>
meh`: thats the other thing, why do we need Native and Native::Base ?
<adambeynon>
Native.new(obj) for general cases
<adambeynon>
or extend from Native for custom classes
<meh`>
because we had Native::Object
<meh`>
and you wanted Native
<meh`>
Native was Native::Base before
<meh`>
a Native::Object is a full blown wrapper for a native object
<meh`>
Native::Base is the contract your class has to fulfill to be treated as a native wrappre
<meh`>
*wrapper
<meh`>
so #to_n
<meh`>
and getting created with a native
<adambeynon>
meh`: but lots of objects can act as a native
<meh`>
adambeynon, you should look at more general cases than your specific ones
<adambeynon>
meh`: its also about performance. looking at the code you just comitted now, we are talking about going from 1 js function call into using 20 or 30 to send 2 arguments to an object
<adambeynon>
thats not going to be useful
<adambeynon>
thats huge performance loss
<adambeynon>
custom wrappers are the only decent solution
<meh`>
if you want array-like objects to be usable in Ruby, you need Native::Array
<meh`>
Native won't work
<adambeynon>
meh`: we cant pretend that working with native objects is seamless, it isnt. Native is there purely as a convenience for very small, simple interactions
<adambeynon>
anything more complex needa a wrapps
GitHub54 has joined #opal
<GitHub54>
opal/master 69c96e1 meh: Add Native#to_a and Native#to_ary
<adambeynon>
meh`, it's the exact reason you have built opal-browser
<adambeynon>
simple wrappers dont do the job
<meh`>
they do, full blown wrappers are just nicer
<meh`>
Native won't get any more complex than that, it does all that is needed
<meh`>
just a method_missing as you put it, doesn't cut it
<meh`>
it cuts it in your limited usage, but Native has to be general
<meh`>
we're running on javascript, that won't change
<meh`>
we need a way to wrap natives when we don't have a full blown wrapper
<adambeynon>
meh`: we are running a ruby-like runtime on top of javascript. we cant pretend that our ruby is suddenly able to work 1:1 with javascript objects
<meh`>
well, guess what, it can now
ylluminate has quit [Quit: Bye!]
<meh`>
Native does the right thing in any case
<adambeynon>
but in that commit you just pushed
<adambeynon>
to_ary
<adambeynon>
isnt that better just to create an Array of natives?
<meh`>
no, it's slower
elia has quit [Ping timeout: 240 seconds]
elia has joined #opal
<elia>
adambeynon, meh`, reprise: put the file into stdlib, that's the right place, that's where fundamental libs like FileUtils and Pathname live
<jakeblue>
Hi can anyone help me with a javascript question
adambeynon has joined #opal
ryanstout has quit [Quit: ryanstout]
<fkchang>
jakeblue: no guarantees I know the answer, but I'll give it a shot
cogitator has joined #opal
<cogitator>
Hi there. I have a question while working with Opal. How can you build two Ruby files at once. This " s.main = 'rubycanvaslib' " is only for one?
<meh`>
cogitator, the simplest way is requiring the two from the main
<cogitator>
What's the syntax, please?
<meh`>
I mean having `require 'a'; require 'b'` in rubycanvaslib