Hello! First of all thank you for this amazing library and your great effort in maintaining it!
I am building a runtime on top of ClearScript that supports node-like requiring of scripts and dll's. I also implemented a REPL feature to explore my objects in console and print them like node does. I do so by enumerating Object.keys(obj).
The issue I am facing is confusing - ```Object.keys()``` is returning names of extension methods even if the object is not suitable for those methods (different type), but only if the assembly containing those methods is exposed in a specific way to script. The type containing the extension methods is not required to be exposed, only the assembly suffices.
How I managed to narrow down the reproduction:
bot.js:
```js
// The assembly I want to import
var telegram = require('./Telegram.Bot.dll');
// require loads the file dynamically and returns a wrapper for its System.Reflection.Assembly
// calling root() on that wrapper returns a new HostTypeCollection(assembly) in C#
var root = telegram.root();
// use the library as it's intended (note: the bug occurs even without this line)
var api = new root.Telegram.Bot.Api(......);
// The next line returns a regular CLR object module
var core = require('core');
var keys = Object.keys(core); // keys now contains ToUnixTime and some other irrelevant extensions!
// From the source code of the library: public static long ToUnixTime(this DateTime self) { ... }
// My object is not a DateTime, nor did I import root.Telegram.Bot.Helpers.Extensions
// class where it resides
// Calling sleep tells the runtime to start a REPL
//after the script file finishes running instead of terminating
core.sleep();
// Exporting object to global namespace
global.core = core;
```
After running this file with my executable, if I type ```core``` in my REPL, It still prints out those keys, and evaluating ```core.ToUnixTime``` as a command returns ```[HostMethod:ToUnixTime]```, trying to invoke ```core.ToUnixTime()``` throws ```... does not contain a definition for 'ToUnixTime'```. This issue pollutes my objects and defeats the purpose of having an inspector.
This bug does not occur (at first) under these conditions:
```js
global.telegram = require('./Telegram.Bot.dll');
// I am not exposing root() here
global.core = require('core');
global.core.sleep();
```
After this file finishes running, typing ```root = telegram.root()``` in REPL exposes the assembly but does not introduce those buggy extension methods. More so, calling ```ext = root.Telegram.Bot.Helpers.Extensions``` does not cause any trouble. However, objects exposed afterwards: ```console = require('console')``` get polluted.
Notes:
-I am using the latest version of ClearScript from NuGet (v5.4.4)
-Executing files runs them within a ```function (exports, require, module, __filename, __dirname) { code }``` wrapper.
-This means that the first case is entirely executed within a engine.Execute(...) call.
-The bug occurs in the first case even if core is exposed before the library.
-The REPL loop starts after executions are finished, so in the second case it is a different execution - an engine.Evaluate(...) more exactly.
-Runtime source code https://github.com/EdonGashi/ShipScript
-Library source code https://github.com/MrRoundRobin/telegram.bot
Thanks!
I am building a runtime on top of ClearScript that supports node-like requiring of scripts and dll's. I also implemented a REPL feature to explore my objects in console and print them like node does. I do so by enumerating Object.keys(obj).
The issue I am facing is confusing - ```Object.keys()``` is returning names of extension methods even if the object is not suitable for those methods (different type), but only if the assembly containing those methods is exposed in a specific way to script. The type containing the extension methods is not required to be exposed, only the assembly suffices.
How I managed to narrow down the reproduction:
bot.js:
```js
// The assembly I want to import
var telegram = require('./Telegram.Bot.dll');
// require loads the file dynamically and returns a wrapper for its System.Reflection.Assembly
// calling root() on that wrapper returns a new HostTypeCollection(assembly) in C#
var root = telegram.root();
// use the library as it's intended (note: the bug occurs even without this line)
var api = new root.Telegram.Bot.Api(......);
// The next line returns a regular CLR object module
var core = require('core');
var keys = Object.keys(core); // keys now contains ToUnixTime and some other irrelevant extensions!
// From the source code of the library: public static long ToUnixTime(this DateTime self) { ... }
// My object is not a DateTime, nor did I import root.Telegram.Bot.Helpers.Extensions
// class where it resides
// Calling sleep tells the runtime to start a REPL
//after the script file finishes running instead of terminating
core.sleep();
// Exporting object to global namespace
global.core = core;
```
After running this file with my executable, if I type ```core``` in my REPL, It still prints out those keys, and evaluating ```core.ToUnixTime``` as a command returns ```[HostMethod:ToUnixTime]```, trying to invoke ```core.ToUnixTime()``` throws ```... does not contain a definition for 'ToUnixTime'```. This issue pollutes my objects and defeats the purpose of having an inspector.
This bug does not occur (at first) under these conditions:
```js
global.telegram = require('./Telegram.Bot.dll');
// I am not exposing root() here
global.core = require('core');
global.core.sleep();
```
After this file finishes running, typing ```root = telegram.root()``` in REPL exposes the assembly but does not introduce those buggy extension methods. More so, calling ```ext = root.Telegram.Bot.Helpers.Extensions``` does not cause any trouble. However, objects exposed afterwards: ```console = require('console')``` get polluted.
Notes:
-I am using the latest version of ClearScript from NuGet (v5.4.4)
-Executing files runs them within a ```function (exports, require, module, __filename, __dirname) { code }``` wrapper.
-This means that the first case is entirely executed within a engine.Execute(...) call.
-The bug occurs in the first case even if core is exposed before the library.
-The REPL loop starts after executions are finished, so in the second case it is a different execution - an engine.Evaluate(...) more exactly.
-Runtime source code https://github.com/EdonGashi/ShipScript
-Library source code https://github.com/MrRoundRobin/telegram.bot
Thanks!