Why are there two PerformUnroll methods in the api?
What does that mean?
using one or the other based on the arguments passed or that it accepts them all. But then again, why are they not brought together in the API as PerformUnroll(List<Brep>,List<Curve>,List<Point3d>,List<TextDot>)?
But what is the difference between the notations List<Brep> and Curve[] aren’t they both lists?
Hi Ivelin. This is called method overloading, which allows defining the same method in a class using different parameters to avoid redundant code. You can call upon any of the overloaded methods depending on the parameters you use. It doesn’t make much sense to bring them together because you would want to call upon that method with the least amount of parameters. You’ll find this situation in many cases within the API.
List<Brep> is and generic list of breps whearas Curve[] is an array of curves. Both are different types of lists with different properties.
@ivelin.peychev this is confusing if you are thinking in Python, since you can’t have multiple methods with the same name, and python is weakly typed. I think the pythonic way would be to use Default arguments
That is correct .
Also, for me List and Array is one and the same. Unless array means a tuple. I’ll read more about this.
I thought method overloading was to add more methods to an existing class but didn’t know you can use the same name of the class and just changing the arguments.
# created by Lando Schumpich Mar 2019
#
import Rhino
import scriptcontext as sc
def subSurfaceSelectUnroll():
# set up getter
brep_to_unroll = Rhino.Input.Custom.GetObject()
brep_to_unroll.SetCommandPrompt("Sub select a brep face")
brep_to_unroll.GeometryFilter = Rhino.DocObjects.ObjectType.Surface
# get
brep_to_unroll.Get()
# test if success
if brep_to_unroll.CommandResult() != Rhino.Commands.Result.Success:
return brep_to_unroll.CommandResult()
# get geometry (is brepface)
brep_face = brep_to_unroll.Object(0).Geometry()
# get parent
brep_parent = brep_face.Brep
# extract face from brep_parent faces list (preserves trims)
brep_trimmed = brep_parent.Faces.ExtractFace(brep_face.FaceIndex)
# create instance of unroller class, with trimmed face as input
unroller = Rhino.Geometry.Unroller(brep_trimmed)
# unroll
arrBrepUnrolled, arrCurveUnrolled, arrPointUnrolled, arrTextDotUnrolled = unroller.PerformUnroll()
# add to doc
for brep in arrBrepUnrolled:
sc.doc.Objects.AddBrep(brep)
if __name__ == "__main__":
subSurfaceSelectUnroll()
arrBrepUnrolled, arrCurveUnrolled, arrPointUnrolled, arrTextDotUnrolled = unroller.PerformUnroll() he’s unpacking all of these objects together not separately as it is in the api. This is very confusing.
Nah, I’d say that strictly typed languages was what most “real” languages was already many decades ago, but Generics became widespread much later (Java got it as late as 2004 and .NET in 2005) and it made life a lot easier. Before generics you would have to make variants of pretty much everything for each type you wanted to use in striclty typed languages.
You may not like strict typing, but strict typing means that the code doesn’t have to figure out in runtime what and how much memory space to allocate to variables and data structures since it knows that up front (the compiler figure that out from start). So the code runs faster.
But there’s more to it than that. There are optimization strategies you simply can’t do manually without strict typing, like cases when you plan for memory usage/allocations far ahead of using that memory. Without the strict types you couldn’t plan for certain efficient uses of memory, just like you couldn’t plan for making a parking lot unless knowing the size and number of cars to be using it. You just can’t do that unless you apply a “strictly known size” of the parking squares in your plans.