GH - Can't define a top level class - Extension method not possible

Grasshopper
1

So, in GH C# ScriptEditor a top level class cannot be defined (only nested classes which resides in the “Custom Additional Code” section. This means that Extension methods cannot be written in the C# ScriptComponent.

Example-code:

  public static class RILStuff
  {
    private static BrepEdge ClosestEdge(this Brep toOtherBrep)
    {
      return null; // blah, blah, blah
    }   
  }

… gives the following error message:

Error (CS1109): Extension method must be defined in a top level static class; RILStuff is a nested class (line 121)

I hope Top Level Classes will be allowed in GH2.0?

// Rolf

2

But… only this script can see the code you write, so why would you need an extension method? Just omit the this keyword and call the method the usual way.

I can see there being a point in having a shared script pool in a document, but extension methods are the least of the benefits.

1 Like
3

It’s about prototyping.

I typically test ideas with C# ScriptComponents, then copy-paste into VS. I want my prototypes (including Extensions) to work in VS after being tested and then finally copied over to VS (once copied to VS I’d move any Extensions to my Extensions library, aso).

// Rolf

4

just remove the static keyword in front of your class and add it afterwards in VS. Wouldn‘t that solve it?

By the way, in the following gh file there is a GH c# compiler, which could be modified for your purpose to directly invoke your static library methods from any codefile without Restarting Rhino+Gh all the time:

5

Extension methods must be static. Trying to remove “static” gives this:

public /*static*/ BrepEdge ClosestEdge(this Brep b, Brep toOtherBrep)

image

Looks interesting, thanks!

// Rolf

6

I see. Well, I guess once there’s a shared script repository for types and methods, that’ll become possible.

If your prototyping doesn’t involve any RhinoCommon classes, I’ve found that the quickest way to write my code is to use unit tests. They can be debugged so you’re inside your code in the space of 2~3 seconds with the appropriate unit tests. Unfortunately doesn’t work if your code relies on functionality which is provided by the Rhino core dll. Pure RhinoCommon methods will work because it’s just .NET, but that list is pretty small.

And when you’re done writing your code, you’ve got unit tests to run for the future, ensuring you don’t break code without noticing. Just a quick tip, maybe not at all useful for you here.

1 Like