logoalt Hacker News

am-gm • today at 1:59 PM • 1 reply • view on HN

So I need to implement again the assembly manager in the IDE. which will allow you to add your own C# libraries (DLLs) and then the answer would be yes, but from within the engine's language, like this:

  C#:
  public void DoSomething(Exp.Instance? callingInst, Exp.IValue?[] args)
  {
     ...
  }

  Exp:
  doSomething("hello")
There is already a relection-based way to call C# functions from my language, i call it "extern classes":

  extern class File = "System.IO.File"
  println(File.readAllText(filePath))
it can also be used with non-static classes, and you can use new(...) expressions on them, and "is" tests and access properties and so on... it SHOULD feel like a normal Exp class. The only exception is that it does not fit to performance-critical contexts, because it uses the slow reflection APIs of C#. but it's already working, unlike the assembly manager feature that is not implemented yet but will allow fast invocations.

Replies

gwbas1c • today at 3:40 PM

(Lesson from experience here)

Years ago I built a "bells and whistles included" webserver with a development environment. https://github.com/GWBasic/objectcloud. (I moved it over to Github after I abandoned it, which is why the repo doesn't follow Readme.md semantics.)

Anyway, a mistake that I made with Objectcloud was basically following my fancy everyday and making many parts custom. In the end, the function of the project was educational for me; but Objectcloud itself never was a useful tool for other people. In part, Objectcloud turned into me solving every problem at once, instead of carefully choosing the problems I needed to solve to have a useful product.

To make a long story short: In dotnet, it's very easy to build programmable extensibility by publishing an interface. By putting "scripting" first, and tightly coupling scripting into the tool, you introduced a lot of complexity into the tool and the learning curve. (I have to learn a new tool and a new language.)

In contrast, if you started with a more traditional dotnet-style "just build classes that implement these interfaces" extensibility, you end up reducing your problem scope. (IE, are you trying to build a game engine or a scripting environment? You only have so many hours in the day, and both are complicated projects to support.)

Furthermore, you can always add a scripting plugin built to the interface once the gaming engine is mature.