<adambeynon>
meh`: I cant reproduce that - have you got a bigger code sample?
<meh`>
adambeynon, it's lost in the ether forever
<adambeynon>
meh`: Hash#to_n and co are useful outside of Native, so Im going to move those methods back into their core classes
<meh`>
adambeynon, please don't
<meh`>
that's inconsistent as fuck
<adambeynon>
how?
<adambeynon>
to_n doesnt turn them into a Native
<adambeynon>
its two opposite things
<meh`>
it isn't, it's part of the Native bridging
<adambeynon>
Hash#to_n is useful for inline x-strings, not just Native
<meh`>
it's like having #to_json inside the corelib because it can be useful outside of it
<meh`>
can you give me an example?
<adambeynon>
passing a hash to jQuery.ajax()
<meh`>
then you have to require native
<meh`>
I can agree with an attr_reader :map
<meh`>
but #to_n is part of the native bridging
<meh`>
and it converts the internal values to native if it can
<meh`>
so you need all of native to use it
<meh`>
if you need to pass an hash to a native function, you require 'native'
<adambeynon>
require 'native' should just provide Native. all the #to_n methods are useful in a lot more places
<meh`>
adambeynon, which is why it was in the corelib in the first place
<adambeynon>
possibly native/ext.rb
<meh`>
but all the #to_n methods depend on the Native module
<meh`>
for conversion and wrapping
<meh`>
so it's all or nothing
<adambeynon>
#to_n doesnt need Native at all
<meh`>
yes, it does
<meh`>
Native.try_convert
<meh`>
or well, it's doing recursive stuff
<adambeynon>
none of the #to_n methods use it
<meh`>
I think it's wrong, native should take care of all the native bridging
<meh`>
not have spaghetti here and there
<meh`>
it's useful when you're wrapping a native library
<meh`>
which is exactly the case where you should require 'native'
<meh`>
if you're just writing Ruby you don't need any of that
<adambeynon>
but thats the thing, Native is just one approach to wrapping
<meh`>
just require 'native' in opal-jquery
<meh`>
adambeynon, Native::Object and Native::Array are just generic wrappers part of the native bridging
<meh`>
#to_n is part of the native bridging, Hash.new and Struct.new supporting native objects is part of native bridging
<meh`>
if you're not using those classes, amen, just require it instead of spraying the code all around
<meh`>
what if you don't use enumerators? move them to a library? except when you start needing them?
<meh`>
don't make spaghetti code just because you don't want a hundred lines added to your resulting js, it's basically irrelevant as far as size goes
<adambeynon>
fine, but all the #to_n stuff has nothing to do with Native. they handle 2 opposite things
<adambeynon>
its like requiring rails just to use some acive_suport things
<meh`>
how does it have nothing to do with it? #to_n is the other side of the same coin
<meh`>
come on, that's not a fair comparison and you know it
<adambeynon>
but Native is only 1 use of native objects in opal. we can wrap, we can bridge, and #to_n is useful for both those, not just for Native stuff
<meh`>
bridge_class and friends are mostly an internal hack
<meh`>
native.rb has all the #to_n stuff, the .new stuff that deals with natives, and Object and Array
<meh`>
they aren't separate things, they're cohesive
<meh`>
you don't use Object or Array? it's fine, you're going to `include Native` to get the helpers like alias_native doing the proper thing and free #initialize and #to_n
<meh`>
if you have #to_n, you need .new supporting natives too, or it's incoherent
<meh`>
and if we start scattering it around it will be harder to maintain
<meh`>
the JSON stuff stays in one place, the Native stuff in another
<meh`>
and in the corelib the core stuff
<adambeynon>
overriding the #initialize on core classes is another thing Im not a fan of
<meh`>
but it's needed for consistency
<meh`>
adambeynon, anyway, how did you like lazy enumerators?
<adambeynon>
oh yeah, awesome stuff ;) havent tried them out yet, but I sure will
<meh`>
adambeynon, how do you feel about removing the deprecated `Enumerator.new object, method, *args`?
<meh`>
it will make the code a lot easier to read
<meh`>
adambeynon, also I think I found a bug in the compiler
<meh`>
not
<meh`>
mh
<adambeynon>
lol, possibly?
elia has quit [Quit: Computer has gone to sleep.]
<meh`>
bin/opal-repl:22:in `run': Unexpected reserved word at <eval>:3626:15 (V8::Error)
<meh`>
oh
<meh`>
my fault
<adambeynon>
meh`: im going to bump a release, 0.5.1 today or tomorrow
<adambeynon>
is it best to leave native in corelib until 0.6?
<adambeynon>
breaking changes and all that
<adambeynon>
we can leave it in stdlib, but require it from opal.rb
<meh`>
sincerely, I'd bump to 0.6
<meh`>
lazy enumerators
<meh`>
infinite enumerators
<meh`>
and there are some usage changes in native, if you used Native::Base
<meh`>
but I think I was the only one using it
<meh`>
so that shouldn't be a problem
<adambeynon>
well, im happy enough with 0.6.0
<adambeynon>
there are quite a few small changes to push as well, which will get rspec mocks working too
<meh`>
also make it tomorrow please
<meh`>
I still have to implement few missing methods in Enumerator::Lazy and few in Enumerable
<meh`>
then we will have a complete enumerable set
<meh`>
suck on that anything that compiles to js
<adambeynon>
:D
<adambeynon>
sure, tomorrow is fine
<adambeynon>
Im thinking perhaps a pre rubyconf thing though, have 0.6.0 ready and available
<adambeynon>
with full rspec support
<meh`>
well, you can make it tonight, it shouldn't take much :)
<meh`>
adambeynon, is verbose still unset?
<meh`>
I'm getting a bunch of Exception: 'undefined' is not an object (evaluating '$gvars["VERBOSE"]['$nil?']')
<meh`>
and it should be false by default anyway
<adambeynon>
yeah, we need that set in corelib
<adambeynon>
I will do that before we release tomorrow
<meh`>
adambeynon, I already added some stuff
<meh`>
$VERBOSE = false
<meh`>
$DEBUG = false
<meh`>
$SAFE = 0
<adambeynon>
ah, yeh thats fine then
<meh`>
and now I'm trying to understand what the fuck is going on in this spec