Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What happens with native functions #2

Open
geuis opened this issue Mar 5, 2015 · 4 comments
Open

What happens with native functions #2

geuis opened this issue Mar 5, 2015 · 4 comments

Comments

@geuis
Copy link
Owner

geuis commented Mar 5, 2015

How would this work if you did set("foo", window.setTimeout)

@dzautner
Copy link

dzautner commented Mar 5, 2015

As far as I know, native functions are global by definition, so it will be possible to check if a function is native with something like this:

if  (fn.toString().indexOf('[native code]')) {
 ...
}

And then store only the function name. When resolving that item from storage, you could return a reference to the native function with return window[resolvedFunctionName]

@Eeems
Copy link

Eeems commented Mar 5, 2015

This would work for global functions, but it doesn't work with non-globals.
set('foo',document.body.click); would result in an undefined value coming back (window.click is undefined). Some more checking might be in order.

if(fn.toString().indexOf('[native code]')){
    for(var i in window){
        if(window[i] instanceof Function && window[i] === fn){
            ...
            break;
        }
    }
}

@dzautner
Copy link

dzautner commented Mar 6, 2015

Yeah, in this case I don't see a way to get the full path to the function in the global scope.

It's possible to save a reference to the function in memory, but it will be deleted when refreshing.

Of course it's always possible to let the user pass the path to the function as a string, but that makes an ugly API.

@geuis
Copy link
Owner Author

geuis commented Sep 28, 2015

What if argon simply prevents storing references to native functions? Since native functions can't be stringified, there's not a lot of point.

Also, you run into problems with naming that @dzautner and @Eeems talked about.

Now, if we allow native function storage, it'll be by reference only. So they'll have different type hint. We could have the data be a string that is the native function's path.

But then this use-case can already be handled by the string conversion. It would be up to the user's app logic to determine that 'window.Array.apply' should reference the function. But this defeats the purpose of what argon is supposed to do.

Ideally, we should be able to pass a reference directly and be able to determine a stringified reference to it.

So far, I think @Eeems idea is the only way to get it to work. The run time is horrible, but it only has to be done on the set() method. get() can just traverse the string and return a reference to the global function much quicker.

I personally think storing references to functions is a bit weird without many use cases, but on the other hand is a use case that should be handled since that's what argon is for.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants