언어 변경 사항

언어 변경 사항 섹션은 각 버전에서 Dynamo의 언어에 대해 업데이트 및 수정된 사항에 대한 개요를 제공합니다. 이러한 변경 사항은 기능, 성능 및 사용에 영향을 미칠 수 있으며, 이 가이드는 사용자가 이러한 업데이트에 적응해야 하는 경우와 이유를 이해하는 데 도움이 될 것입니다.

Dynamo 2.0 언어 변경 사항

1. list@level 구문을 "@-1"에서 "@L1"로 변경

• list@level의 새 구문으로 list@-1 대신 list@L1 사용

• 동기: 코드 구문을 미리보기/UI에 맞춰 조정, 사용자 테스트 결과 이 새로운 구문이 더 이해하기 쉬운 것으로 나타남

1. Dynamo 유형에 맞추기 위해 TS에서 Int 및 Double 유형 구현

2. 인수의 개수만 다른 오버로드된 함수를 허용되지 않음

• 이전에 제거된 오버로드를 사용하는 이전 그래프가 더 앞선 순서의 오버로드로 기본 설정됨

• 동기: 특정 함수가 실행되는 것에 대한 모호성 제거

1. 복제 가이드 사용 시 배열 승격 비활성화

2. 명령형 블록 내 변수를 명령형 블록 범위 내에서만 유효하도록 로컬화

• 명령형 코드 블록 내에 정의된 변수 값은 해당 변수를 참조하는 명령형 블록 내부의 변경 사항에 의해 변경되지 않습니다.

1. 변수를 불변으로 만들어 코드 블록 노드에서 연관 업데이트 비활성화

2. 모든 UI 노드를 정적 메서드로 컴파일

3. 할당 없이 return 문 지원

• 함수 정의 또는 명령형 코드에서는 "="가 필요하지 않습니다.

1. CBN에서 이전 메서드 이름 마이그레이션

• 라이브러리 탐색기 사용자 인터페이스에서의 배치와 가독성을 높이기 위해 많은 노드의 이름이 변경되었습니다.

1. 리스트를 사전으로 정리

알려진 문제:

• 명령형 블록의 네임스페이스 충돌로 인해 예기치 않은 입력 포트가 나타날 수 있습니다. 자세한 내용은 Github 문제를 참고하십시오. 이 문제를 해결하려면 다음과 같이 함수를 명령형 블록 외부에 정의합니다.

pnt = Autodesk.Point.ByCoordinates;
lne = Autodesk.Line.ByStartPointEndPoint;

[Imperative]
{
    x = 1;
    start = pnt(0,0,0);
    end = pnt(x,x,x);
    line = lne(start,end);
    return = line;
};

Dynamo 2.0 언어 변경 사항 설명

Dynamo 2.0 릴리즈의 언어가 대폭 개선되었습니다. 이러한 변경의 주요 동기는 언어를 단순화하는 것이었습니다. 최종 사용자의 이해를 높인다는 목표를 가지고 더 강력하고 유연하게 만들기 위해 DesignScript를 더 이해하기 쉽고 사용하기 간편하게 하는 데 중점을 두었습니다.

다음은 2.0에 설명된 변경 사항의 리스트입니다.

• List@Level 구문이 단순화됨

• 순서만 다른 매개변수를 가진 오버로드된 메서드를 사용할 수 없음

• 모든 UI 노드를 정적 메서드로 컴파일

• 복제 가이드/레이싱 사용 시 리스트 승격이 비활성화됨

• 연관 블록에서 변수를 불변으로 만들어 연관 업데이트 방지

• 명령형 블록에서 변수가 명령형 범위 내에서만 유효하도록 로컬화됨

• 리스트와 사전 분리

1. list@level 구문이 단순화됨

2. 순서만 다른 매개변수를 가진 오버로드된 함수를 사용할 수 없음

오버로드된 함수는 다음과 같은 여러 가지 이유로 문제가 됩니다.

• 그래프에서 UI 노드로 표시된 오버로드된 함수는 런타임에 실행되는 동일한 오버로드 함수가 아닐 수 있습니다.

• 메서드 해결은 비용이 많이 들며 오버로드된 함수에는 잘 작동하지 않습니다.

• 오버로드된 함수의 복제 동작을 이해하기 어렵습니다.

BoundingBox.ByGeometry을(를) 예로 들어 보겠습니다. 이전 버전의 Dynamo에서는 두 개의 오버로드된 함수가 있었습니다. 하나는 단일 값 인수를 사용했고 다른 하나는 형상 리스트를 인수로 사용했습니다.

BoundingBox BoundingBox.ByGeometry(geometry: Geometry) {...}
BoundingBox BoundingBox.ByGeometry(geometry: Geometry[]) {...}

2.0에서는 이러한 이유로 매개변수의 개수만 다른 오버로드된 함수를 허용하지 않습니다. 즉, 동일한 수와 유형의 매개변수를 가지고 있지만 순위만 다른 하나 이상의 매개변수를 가진 오버로드된 함수는 첫 번째로 정의된 오버로드만 유효하고 나머지는 컴파일러에 의해 버려집니다. 이 단순화의 주요 이점은 함수 후보를 빠르게 선택할 수 있도록 메서드 해결 로직을 단순화하는 것입니다.

2.0의 형상 라이브러리에서는 BoundingBox.ByGeometry 예제의 첫 번째 오버로드가 더 이상 사용되지 않도록 되었고 두 번째 오버로드만 유지되었습니다. 따라서 노드가 복제되도록 의도된 경우, 즉 첫 번째 오버로드의 컨텍스트에서 사용되는 경우 가장 짧은(또는 가장 긴) 레이싱 옵션을 사용하거나 코드 블록에서 복제 가이드를 사용해야 합니다.

BoundingBox.ByGeometry(geometry<1>);

이 예제에서 볼 수 있듯이, 더 앞선 순선의 노드는 복제된 호출과 복제되지 않은 호출 모두에서 사용될 수 있으므로 항상 더 늦은 순서의 오버로드보다 우선적으로 사용됩니다. 따라서 일반적인 규칙으로, 노드 작성자는 항상 더 늦은 순서의 오버로드 대신 더 앞선 순서의 메서드를 사용하는 것이 좋습니다. 이렇게 하면 DesignScript 컴파일러는 항상 첫 번째로 찾은 유일한 메서드로 더 앞선 순위의 메서드를 호출하게 됩니다.

예제:

다음 예제에서는 함수 foo의 두 가지 오버로드가 정의되었습니다. 1.x에서는 어떤 오버로드가 런타임에서 실행될지 모호합니다. 사용자는 두 번째 오버로드인 foo(a:int, b:int)가 실행될 것이라고 예상할 수 있으며, 이 경우 메서드는 세 번 복제되어 값 10을 세 번 반환할 것으로 예상됩니다. 그러나 실제로는 리스트 매개변수를 사용하는 첫 번째 오버로드가 대신 호출되기 때문에 값 10이 한 번만 반환됩니다.

2.0에서는 두 번째 오버로드가 생략됨

2.0에서는 항상 첫 번째로 정의된 메서드가 나머지 메서드보다 우선적으로 선택됩니다. 즉, 선착순으로 선택됩니다.

다음 각 경우에서 첫 번째로 정의된 오버로드가 선택됩니다. 이는 순전히 함수 정의 순서에 기반한 것이며, 매개변수의 순서에 의존하지 않습니다. 다만, 사용자 정의 및 Zero Touch 노드의 경우, 더 앞선 순서의 매개변수를 가진 메서드를 우선적으로 선택하는 것이 권장됩니다.

1)
foo(a: int[], b: int); ✓
foo(a: int, b: int); ✕

2) 
foo(x: int, y: int); ✓
foo(x: int[], y: int[]); ✕

3. 모든 UI 노드를 정적 메서드로 컴파일

Dynamo 1.x에서는 UI 노드(비코드 블록)가 각각 인스턴스 메서드와 특성으로 컴파일되었습니다. 예를 들어, Point.X 노드는 pt.X로 컴파일되었고 Curve.PointAtParameter는 curve.PointAtParameter(param)로 컴파일되었습니다. 이 동작에는 다음과 같은 두 가지 문제가 있었습니다.

A. UI 노드가 나타내는 함수가 항상 런타임에서 실행되는 함수와 일치하지 않았습니다.

일반적인 예는 Translate 노드입니다. 동일한 수와 유형의 인수를 사용하는 여러 Translate 노드(예: Geometry.Translate, Mesh.Translate, FamilyInstance.Translate)가 있습니다. 노드가 인스턴스 메서드로 컴파일되었기 때문에 FamilyInstance를 Geometry.Translate 노드에 전달하면 런타임에서 호출이 FamilyInstance의 Translate 인스턴스 메서드로 디스패치되어 예상 외의 동작이 발생했습니다. 이는 노드가 실제로 수행하는 작업과 일치하지 않아 사용자에게 혼란을 주었습니다.

B. 두 번째 문제는 인스턴스 메서드가 이질적인 배열에서 작동하지 않았다는 것입니다.

런타임에서 실행 엔진은 어떤 함수가 디스패치되어야 하는지 결정해야 합니다. 입력이 리스트인 경우, 예를 들어 list.Translate()처럼 리스트의 각 요소를 순차적으로 확인하고 해당 유형의 메서드를 찾는 것이 비효율적이기 때문에 메서드 해결 논리는 단순히 첫 번째 요소의 유형을 기준으로 대상 유형을 추정하고, 해당 유형에 정의된 Translate() 메서드를 찾아보려고 시도합니다. 그 결과, 만약 첫 번째 요소의 유형이 메서드의 대상 유형과 일치하지 않거나 (또는 리스트가 비어 있거나 null인 경우), 리스트 전체가 실패하게 되며, 리스트 내에 일치하는 다른 유형이 있더라도 실패하게 됩니다.

예를 들어 [Arc, Line]의 리스트 입력이 Arc.CenterPoint에 전달되면 호는 중심점을 반환하고 선은 예상대로 null 값을 반환합니다. 그러나 순서가 반대로 바뀌면 첫 번째 요소가 메서드 해결 검사에서 실패했기 때문에 전체 결과가 null이 됩니다.

Dynamo 1.x: 메서드 해결 검사를 위해 입력 리스트의 첫 번째 요소만 테스트함

x = [arc, line];
y = x.CenterPoint; // y = [centerpoint, null] ✓

x = [line, arc];
y = x.CenterPoint; // y = null ✕

2.0에서는 이 두 가지 문제가 UI 노드를 정적 특성 및 정적 메서드로 컴파일함으로서 해결되었습니다.

정적 메서드를 사용하면 런타임 메서드 해결이 더 직관적이게 되고 입력 리스트의 모든 요소를 반복해서 확인할 수 있습니다. 예를 들면 다음과 같습니다.

foo.Bar()(인스턴스 메서드) 의미론은 foo 유형을 확인하고 해당 유형이 리스트인지 여부를 확인한 다음 후보 함수와 일치시켜야 합니다. 따라서 비용이 많이 듭니다. 반면에 Foo.Bar(foo)(정적 메서드) 의미론은 매개변수 유형이 foo인 하나의 함수만 확인하면 됩니다!

2.0에서는 다음과 같습니다.

• UI 특성 노드가 정적 게터로 컴파일됨: 엔진은 각 특성에 대해 정적 버전의 게터를 생성합니다. 예를 들어, Point.X 노드는 정적 게터인 Point.get_X(pt)로 컴파일됩니다. 정적 게터는 코드 블록 노드에서 별칭인 Point.X(pt)를 사용하여 호출될 수도 있습니다.

• UI 메서드 노드가 정적 버전으로 컴파일됨: 엔진은 노드에 해당하는 정적 메서드를 생성합니다. 예를 들어 Curve.PointAtParameter 노드는 curve.PointAtParameter(parameter) 대신 Curve.PointAtParameter(curve: Curve, parameter:double)로 컴파일됩니다.

참고: 이번 변경으로 인스턴스 메서드 지원은 제거되지 않았습니다. 따라서 위 예제에서처럼 CBN에서 사용되는 기존 인스턴스 메서드인 pt.X 및 curve.PointAtParameter(parameter)는 계속 작동합니다.

이전 버전인 1.x에서는 이 예제가 작동했을 것입니다. 그래프가 point.X;로 컴파일되었고, 그러면 점 객체에서 X 특성을 찾을 수 있었기 때문입니다. 그러나 2.0에서는 컴파일된 코드인 Vector.X(point)가 Vector 유형만을 예상하므로 이제 작동하지 않습니다.

장점:

**일관성/이해하기 쉬움 : ** 정적 메서드는 런타임에서 실행될 메서드에 대한 모호성을 없애줍니다. 메서드는 항상 그래프에서 사용자가 호출될 것으로 예상하는 UI 노드와 일치합니다.

호환성: 코드와 시각적 프로그램 간의 상관 관계가 더 좋아졌습니다.

교육적: 이제 이종 리스트 입력을 노드에 전달하면 노드에서 허용되는 유형에 대해서는 null이 아닌 값이 반환되고 노드를 구현하지 않는 유형에 대해서는 null 값이 반환됩니다. 결과가 더 예측 가능하며 노드에서 허용되는 유형을 더 잘 파악할 수 있습니다.

주의: 오버로드된 메서드에서 해결되지 않은 모호함

해결된 문제:

정적 메서드 의미론으로의 전환은 2.0 언어 변경 사항과 관련된 다음과 같은 부작용을 야기했습니다.

1. 다형성 동작의 손실:

ProtoGeometry의 TSpline 노드의 예로 들어보겠습니다(여기서 TSplineTopology는 기본 Topology 유형에서 상속됨). 이전에 인스턴스 메서드인 object.Edges로 컴파일되었던 Topology.Edges 노드는 이제 정적 메서드인 Topology.Edges(object)로 컴파일됩니다. 이전 호출은 객체의 런타임 유형에 따라 메서드를 디스패치하여 파생된 클래스 메서드인 TsplineTopology.Edges로 다향적으로 해결되었습니다.

반면 새로운 정적 동작은 기본 클래스 메서드인 Topology.Edges를 호출하도록 강제되었습니다. 그 결과, 이 노드는 파생 클래스인 TSplineEdge 객체 대신 기본 클래스인 Edge 객체를 반환하게 되었습니다.

이것은 다운스트림의 TSpline 노드가 TSplineEdges를 예상하고 있었기 때문에 오류가 발생한 회귀 문제였습니다.

이 문제는 메서드 디스패치 로직에 런타임 검사를 추가하여 인스턴스 유형이 메서드의 첫 번째 매개변수 유형 또는 하위 유형과 일치하는지 확인함으로써 해결되었습니다. 입력 리스트의 경우, 메서드 디스패치를 단순화하여 첫 번째 요소의 유형만 검사하도록 했습니다. 따라서 최종 해결책은 부분적으로 정적이고 부분적으로 동적인 메서드를 찾는 절충안이었습니다.

2.0의 새로운 다형성 동작:

이 경우 첫 번째 요소인 a가 TSpline이므로 런타임에서 파생 메서드인 TSplineTopology.Edges가 호출됩니다. 그 결과 기본 Topology 유형인 b에 대해서는 null이 반환됩니다.

반면, 두 번째 경우에서는 일반적인 Topology 유형인 b가 첫 번째 요소이므로 기본 메서드인 Topology.Edges가 호출됩니다. Topology.Edges는 파생된 TSplineTopology 유형인 a도 입력으로 수락할 수 있으므로 입력 a와 b 모두에 대해 Edges를 반환합니다.

2. 중복된 외부 리스트 생성으로 인한 회귀 문제

인스턴스 메서드와 정적 메서드는 복제 가이드 동작에서 주요한 차이점이 한 가지 있습니다. 인스턴스 메서드를 사용할 때는 단일 값 입력이 복제 가이드를 가져도 리스트로 승격되지 않지만, 정적 메서드를 사용할 때는 리스트로 승격됩니다.

예를 들어, Surface.PointAtParameter 노드에서 교차 레이싱을 사용하고 단일 표면 입력과 u 및 v 매개변수 값의 배열을 제공하는 경우를 고려해 보겠습니다. 인스턴스 메서드는 다음과 같이 컴파일됩니다.

surface<1>.PointAtParameter(u<1>, v<2>);

그 결과, 2D 배열의 점이 생성됩니다.

정적 메서드는 다음과 같이 컴파일됩니다.

Surface.PointAtParameter(surface<1>, u<2>, v<3>);

그 결과, 불필요하게 추가된 가장 바깥쪽의 리스트가 포함된 3D 리스트의 점이 생성됩니다.

UI 노드를 정적 메서드로 컴파일하는 이 부작용은 기존 사용 사례에서 회귀를 유발할 가능성이 있습니다. 이 문제는 복제 가이드/레이싱 사용 시 단일 값 입력을 리스트로 승격하는 것을 비활성화함으로써 해결되었습니다(다음 항목 참조).

4. 복제 가이드/레이싱 사용 시 리스트 승격이 비활성화됨

1.x에서는 다음과 같은 두 가지 경우에 단일 값이 리스트로 승격되었습니다.

• 더 늦은 순서의 입력이 더 앞선 순서의 입력을 예상하는 함수에 전달되는 경우

• 더 늦은 순서의 입력이 동일한 순서가 예상되는 함수에 전달되었지만, 해당 입력 인수가 복제 가이드로 지정되었거나 레이싱을 사용하는 경우

2.0에서는 이러한 시나리오에 대한 리스트 승격을 방지함으로써 후자의 경우를 더 이상 지원하지 않습니다.

다음은 1.x 그래프에서의 예제입니다. 여기서 y와 z 각각에 대해 한 단계의 복제 가이드가 적용되면서 y와 z가 자동으로 랭크 1의 배열로 승격되었습니다. 이로 인해 결과는 x, y, z 각각에 대해 랭크 3이 되었습니다 하지만, 사용자는 단일 값 입력에 복제 가이드가 존재한다고 해서 결과의 랭크가 추가되는 것이 명확하지 않기 때문에 오히려 결과가 랭크 1이 되는 것이 더 직관적일 것이라고 예상합니다.

x = 1..5;
y = 0;
z = 0;
p = Point.ByCoordinates(x<1>, y<2>, z<3>); // cross-lacing

Dynamo 1.x: 점의 3D 리스트

2.0에서는 y와 z의 단일 값 인수 대한 복제 가이드가 리스트 승격을 일으키지 않으며, 그 결과 x의 입력 1D 리스트와 동일한 차원의 리스트가 생성됩니다.

Dynamo 2.0: 점의 1D 리스트

위에서 언급한, 정적 메서드 컴파일로 인해 중복된 외부 리스트가 생성되는 문제는 이번 언어 변경으로 해결되었습니다.

위와 동일한 예제를 계속 사용하면 정적 메서드 호출로 인해

Surface.PointAtParameter(surface<1>, u<2>, v<3>); 

Dynamo 1.x에서는 3D 점 리스트가 생성됩니다. 이는 첫 번째 단일 값 인수 surface가 복제 가이드와 함께 사용될 때 리스트로 승격되었기 때문입니다.

Dynamo 1.x: 복제 가이드가 적용된 인수의 리스트 승격

2.0에서는 복제 가이드 또는 레이싱 사용 시 단일 값 인수가 리스트로 승격되는 것을 비활성화했습니다. 따라서 이제 호출

Surface.PointAtParameter(surface<1>, u<2>, v<3>);

는 단순히 surface가 승격되지 않으므로 2D 리스트를 반환합니다.

Dynamo 2.0: 복제 가이드가 적용된 단일 값 인수의 리스트 승격이 비활성화됨

이 변경은 이제 불필요한 리스트 수준 추가를 제거하고 정적 메서드 컴파일로의 전환으로 발생한 회귀 문제도 해결합니다.

장점:

가독성: 결과가 사용자 기대에 맞추어져 이해하기 쉬워집니다.

**호환성: ** UI 노드(레이싱 옵션 사용)와 복제 가이드를 사용하는 CBN이 호환되는 결과를 제공합니다.

일관성:

• 인스턴스 메서드와 정적 메서드가 일관되게 동작합니다(정적 메서드 의미와 관련된 문제 해결).

• 기본 인수를 사용하는 입력을 가진 노드가 일관되게 동작합니다(아래 참조).

5 코드 블록 노드에서 변수를 불변으로 만들어 연관 업데이트 방지

DesignScript는 두 가지 프로그래밍 패러다임인 연관 프로그래밍과 명령형 프로그래밍을 지원합니다. 연관 코드는 프로그램 문에서 종속성 그래프를 생성하며, 변수는 서로 종속성을 가집니다. 변수를 업데이트하면 이 변수에 종속되는 다른 모든 변수에 대한 업데이트가 트리거될 수 있습니다. 즉, 연관 블록 내의 문의 실행 순서는 문의 순서가 아니라 변수 간의 종속성 관계에 따라 결정됩니다.

다음 예제에서 코드 실행 순서는 1 -> 2 -> 3 -> 2행입니다. b는 a에 대한 종속성을 가지고 있으므로 3행에서 a가 업데이트되면 실행이 다시 2행으로 돌아가 b를 새로운 a 값으로 업데이트합니다.

1. a = 1; 
2. b = a * 2;
3. a = 2;

반면 동일한 코드가 명령형 컨텍스트에서 실행되면 문은 선형적이고 하향식 흐름으로 실행됩니다. 따라서 명령형 코드 블록은 반복문이나 if-else 조건과 같은 코드 구조의 순차적 실행에 적합합니다.

연관 업데이트의 모호성:

1. 변수 간 순환 종속성:

특정한 경우에는 변수 간의 순환 종속성이 다음과 같이 명확하지 않을 수 있습니다. 컴파일러가 정적으로 순환을 감지할 수 없는 경우, 이는 무한 런타임 순환을 초래할 수 있습니다.

a = 1;
b = a;
a = b;

2. 자기 자신에 종속된 변수:

변수가 자기 자신에 종속되어 있다면, 해당 값은 누적되어야 할까요? 아니면 업데이트마다 원래 값으로 재설정되어야 할까요?

a = 1;
b = 1;
b = b + a + 2; // b = 4
a = 4;         // b = 10 or b = 7?

이 형상 예제에서는 큐브 b가 자기 자신과 원통 a에 종속되어 있습니다. 슬라이더를 이동하면 구멍이 블록을 따라 이동하게 해야 할까요? 아니면 슬라이더 위치가 업데이트될 때마다 여러 개의 구멍이 경로를 따라 누적되는 효과를 만들어야 할까요?

3. 변수의 특성 업데이트:

1: def foo(x: A) { x.prop = ...; return x; }
2: a = A.A();
3: p = a.prop;
4: a1 = foo(a);  // will p update?

4. 함수 업데이트 :

1: def foo(v: double) { return v * 2; }// define “foo”
2: x = foo(5);                         // first definition of “foo” called
3: def foo(v: int) { return v * 3; }   // overload of “foo” defined, will x update?

경험상, 연관 업데이트는 노드 기반 데이터 흐름 그래프 컨텍스트에서 코드 블록 노드에 유용하지 않다는 것을 알게 되었습니다. 시각적 프로그래밍 환경이 제공되기 전에는 옵션을 탐색하는 유일한 방법은 프로그램에서 일부 변수의 값을 명시적으로 변경하는 것이었습니다. 텍스트 기반 프로그램에는 변수 업데이트에 대한 전체 기록이 있지만 시각적 프로그래밍 환경에서는 변수의 최신 값만 표시됩니다.

만약 일부 사용자가 연관 업데이트를 사용했다면, 그들은 아마도 이를 알지 못한 채 사용했을 가능성이 높으며, 그로 인해 오히려 더 큰 문제가 발생했을 것입니다. 따라서 2.0에서는 변수를 불면으로 만들어 코드 블록 노드를 사용할 때 연관성을 사용자에게 보이지 않도록 숨기기로 결정했습니다. 대신, 연관 업데이트는 DS 엔진의 기본 기능으로만 유지됩니다. 이는 사용자의 스크립팅 환경을 단순화한다는 아이디어에서 비롯된 또 다른 변경 사항입니다.

**리스트 인덱싱은 코드 블록에서 여전히 허용됨 **

리스트 인덱싱에 대해서는 예외가 적용되어 2.0에서도 인덱스 연산자 할당을 통해 여전히 허용됩니다.

다음 예제에서는 리스트 a가 초기화된 후 인덱스 연산자 할당을 통해 나중에 덮어써질 수 있으며, a에 종속된 변수가 연관되어 업데이트되는 것을 c 값에서 확인할 수 있습니다. 또한 노드 미리보기에는 하나 이상의 요소가 재정의된 후 a의 업데이트된 값이 표시됩니다.

6. 명령형 블록에서 변수가 명령형 블록 범위 내에서만 유효하도록 로컬화됨

우리는 2.0에서 복잡한 교차 언어 업데이트 시나리오를 비활성화하기 위해 명령형 범위 규칙을 변경했습니다.

Dynamo 1.x에서 다음 스크립트의 실행 순서는 1 -> 2 -> 4 -> 6 -> 4행이며, 여기서 변경 사항은 외부에서 내부 언어 범위로 전파됩니다. y가 외부 연관 블록에서 업데이트되고 x가 명령형 블록에서 y에 종속되어 있기 때문에 제어는 외부 연관 프로그램에서 4행의 명령형 언어로 전환됩니다.

1: x = 1;
2: y = 2;
3: [Imperative] {
4:     x = 2 * y;
5: }
6: y = 3;

다음 예제의 실행 순서는 1 -> 2 -> 4 -> 2행이며, 여기서 변경 사항은 내부에서 외부 언어 범위로 전파됩니다.

1: x = 1;
2: y = x * 2;
3: [Imperative] {
4:     x = 3;
5: }

위 시나리오는 교차 언어 업데이트에 해당하며, 이는 연관 업데이트와 마찬가지로 코드 블록 노드에서는 그다지 유용하지 않습니다. 복잡한 교차 언어 업데이트 시나리오를 비활성화하기 위해 명령형 범위에서 유효하도록 변수를 로컬화했습니다.

Dynamo 2.0의 다음 예제에서는

x = 1;
y = x * 2;
i = [Imperative] {
     x = 3;
     return x;
}

• 명령형 블록에 정의된 x가 이제 명령형 범위에서만 유효하도록 로컬화됨

• 외부 범위에서 x와 y의 값이 각각 1과 2로 유지됨

명령형 블록 내의 모든 로컬 변수는 외부 범위에서 그 값에 접근하려면 반환되어야 합니다.

다음과 같은 예를 가정해 봅시다.

1: x = 1;
2: y = 2;
3: [Imperative] {
4:     x = 2 * y;
5: }
6: y = 3; // x = 1, y = 3

• y는 명령형 범위 내에서 로컬로 복사됨

• 명령형 범위 내의 x 값이 4임

• 외부 범위에서 y 값을 업데이트하면 여전히 x가 교차 언어 업데이트로 인해 업데이트되는 현상이 발생하지만, 이는 2.0에서 변수 불변성 때문에 코드 블록에서 비활성화되었음

• 외부 연관 범위에서 x와 y의 값은 각각 1과 2로 유지됨

7. 리스트와 사전

Dynamo 1.x에서는 리스트와 사전이 단일 통합 컨테이너로 표현되었으며, 이는 정수 인덱스와 비정수 키 모두로 인덱싱할 수 있었습니다. 아래 표는 2.0에서 리스트와 사전의 분리를 요약한 것으로, 새로운 사전 데이터 유형의 규칙을 설명합니다.

새로운 [] 리스트 구문

리스트 초기화 구문이 2.0에서 중괄호 {}에서 대괄호 []로 변경되었습니다. 1.x에서 작성된 모든 스크립트는 2.0에서 열 때 자동으로 새로운 구문으로 마이그레이션됩니다.

Zero Touch 노드의 기본 인수 속성에 대한 참고 사항:

자동 마이그레이션은 기본 인수 속성에서 사용된 이전 구문과는 호환되지 않습니다. 따라서 노드 작성자는 필요한 경우 기본 인수 속성 DefaultArgumentAttribute에서 새로운 구문을 사용하도록 zero-touch 메서드 정의를 수동으로 업데이트해야 합니다.

인덱싱에 대한 참고 사항:

새로운 인덱싱 동작은 특정 경우에서 변경되었습니다. 이제 [] 연산자를 사용하여 임의의 인덱스/키 리스트로 리스트/사전에 인덱싱할 때 입력된 인덱스/키 리스트의 구조가 그대로 유지됩니다. 이전에는 항상 다음과 같이 값의 1D 리스트를 반환했습니다.

Given:
a = {“foo” : 1, “bar” : 2};

1.x:
b = a[{“foo”, {“bar”}}];
returns {1, 2}

2.0:
b = a[[“foo”, [“bar”]]];
returns [1, [2]];

사전 초기화 구문:

사전 초기화를 위한 {}(중괄호 구문)은 다음과 같이

dict = {<key> : <value>, …}; 

키-값 형식에서만 사용될 수 있으며, 이때 <key>에는 문자열만 허용되고 여러 개의 키-값 쌍은 쉼표로 구분됩니다.

Dictionary.ByKeysValues Zero-Touch 메서드는 키와 값의 리스트를 각각 전달하여 사전을 초기화하는 더 다재다능한 방법으로 사용할 수 있으며, Zero-Touch 메서드를 사용할 때의 모든 기능(복제 가이드 등)을 함께 사용할 수 있습니다.

사전 초기화 구문에 임의의 표현식을 사용하지 않은 이유는 무엇일까요?

우리는 사전 키-값 초기화 구문에서 키에 대해 임의의 표현식을 사용하는 아이디어를 실험해 본 결과, 특히 {keys : vals}와 같이 keys와 vals가 모두 리스트인 구문이 복제와 같은 DesignScript의 다른 언어 기능과 충돌하면서 Zero-Touch 초기화 노드와 다른 결과를 초래하여 혼동을 일으킬 수 있다는 것을 알게 되었습니다.

예를 들어, 다음 문과 같이 예상되는 동작을 정의하기 어려운 다른 경우들이 있을 수 있습니다.

dict = {["foo", "bar"] : "baz" };

복제 가이드 구문 등을 추가하는 것은 식별자뿐만 아니라 언어의 단순성을 해치는 일이 될 것입니다.

우리는 향후 사전 키가 임의의 표현식을 지원하도록 확장_할 수 있지만_, 그렇게 할 경우 다른 언어 기능과의 상호 작용이 일관되고 이해하기 쉽게 유지되어야 하며, 그 과정에서 복잡성을 가중될 것입니다. 이는 시스템을 조금 덜 강력하게 만들 수 있지만, 이해하기 쉬운 상태를 유지하는 방향으로 갈 수 있다는 뜻입니다. 또한 Dictionary.ByKeysValues(keyList, valueList) 메서드를 사용하여 이 문제를 해결할 수 있는 대체 방법이 항상 존재하다는 점을 고려하면 크게 문제가 되지 않을 것입니다.

Zero Touch 노드와의 상호 작용:

1. .NET 사전을 반환하는 Zero Touch 노드가 Dynamo 사전으로 반환됨

2. 다중 반환 노드는 사전으로 미리 볼 수 있음

3. Dynamo 사전은 .NET 사전을 허용하는 Zero-Touch 노드에 입력으로 전달할 수 있습니다.

다중 반환 노드의 사전 미리보기

사전은 순서가 없는 키-값 쌍입니다. 따라서 이 아이디어와 일관되게 사전을 반환하는 노드의 키-값 쌍 미리보기는 노드의 반환 값 순서대로 순서가 지정되지 않을 수 있습니다.

하지만 MultiReturnAttribute가 정의된 다중 반환 노드에 대해서는 예외를 두었습니다. 다음 예제에서 DateTime.Components 노드는 "다중 반환" 노드이고, 노드 미리 보기는 노드의 출력 포트와 동일한 순서로 키-값 쌍을 반영합니다. 이 순서는 노드 정의에서 MultiReturnAttribute에 따라 지정된 출력의 순서이기도 합니다.