이것이 Raku 디자인의 의도입니까?

Raku 가이 분야에서 완전히 분류되지 않은 것은 아닙니다. 귀하의 질문은 Raku 디자인의 두 가지 주제에 대해 다루며, 둘 다 약간의 토론 가치가 있습니다.

라쿠는 일류 l- 값을 가지고 있습니다

라쿠는 일류가되는 l- 값을 충분히 활용합니다. 우리가 쓸 때 :

has $.x is rw;

생성되는 방법은 다음과 같습니다.

method x() is rw { $!x }

is rw여기에는 메소드가 반환을 나타냅니다 리터 값 이다,에 할당 할 수있는 뭔가를 -. 따라서 우리가 쓸 때 :

$obj.x = 42;

이것은 구문 설탕이 아닙니다. 실제로 메소드 호출이며 할당 연산자가 그 결과에 적용됩니다. 메서드 호출은 Scalar속성 의 컨테이너를 반환하고 할당 할 수 있기 때문에 문제가되지 않습니다 . 바인딩을 사용하여 이것을 두 단계로 나누면 사소한 구문 변환이 아닌 것을 알 수 있습니다. 예를 들면 다음과 같습니다.

my $target := $obj.x;
$target = 42;

객체 속성에 할당됩니다. 이 같은 메커니즘은 목록 할당을 포함하여 수많은 다른 기능 뒤에 있습니다. 예를 들면 다음과 같습니다.

($x, $y) = "foo", "bar";

List컨테이너를 포함하는 컨테이너 를 구성하여 작동 $x하며 $y,이 경우 대입 연산자는 각면을 쌍으로 반복하여 대입을 수행합니다. 이것은 우리가 rw그곳에서 객체 접근자를 사용할 수 있다는 것을 의미 합니다 :

($obj.x, $obj.y) = "foo", "bar";

그리고 그것은 모두 자연스럽게 작동합니다. 이것은 또한 배열과 해시 조각에 할당하는 메커니즘입니다.

또한 Proxy읽기 및 쓰기 동작이 사용자의 통제하에있는 l- 값 컨테이너를 만들기 위해 사용할 수 있습니다 . 따라서 부작용을에 넣을 수 STORE있습니다. 하나…

Raku는 “세터”보다 의미 론적 방법을 권장합니다

OO를 설명 할 때 “캡슐화”및 “데이터 숨기기”와 같은 용어가 종종 나타납니다. 여기서 핵심 아이디어는 객체 내부의 상태 모델, 즉 동작 (메서드)을 구현하기 위해 필요한 데이터를 표시하도록 선택하는 방식과 같이 새로운 요구 사항을 처리하기 위해 자유롭게 진화 할 수 있다는 것입니다. 물체가 복잡할수록 더욱 자유 로워집니다.

그러나 게터와 세터는 상태와 암시 적으로 연결된 메서드입니다. 상태에 직접 액세스하지 않고 메소드를 호출하기 때문에 데이터 숨기기를 달성한다고 주장 할 수 있지만 내 경험은 외부 코드가 일련의 setter 호출을 수행하여 작업을 수행하는 위치에서 빠르게 끝나는 것입니다. 기능 부러워 안티 패턴의 형태. 그리고 우리가 그렇게 한다면 , getter와 setter 연산을 혼합하여 연산을 수행하는 객체 외부의 논리로 끝날 것입니다. 실제로 이러한 작업은 수행중인 작업을 설명하는 이름을 가진 방법으로 노출되어야합니다. 우리가 동시 설정에 있다면 더욱 중요합니다. 잘 설계된 객체는 종종 메소드 경계에서 보호하기가 상당히 쉽습니다.

즉, 많은 용도 class는 실제로 레코드 / 제품 유형입니다. 단순히 여러 데이터 항목을 그룹화하기 위해 존재합니다. .시길이 접근자를 생성 할뿐만 아니라 다음과 같은 경우도 우연 이 아닙니다.

• 속성을 기본 객체 초기화 로직 (즉, class Point { has $.x; has $.y; }로 인스턴스화 할 수 있음 Point.new(x => 1, y => 2))에 의해 설정되도록 선택하고 .raku덤프 메소드 에서 속성을 렌더링합니다 .
• 속성을 기본 .Capture객체로 선택합니다. 즉,이를 파괴 (예 :)에서 사용할 수 있습니다 sub translated(Point (:$x, :$y)) { ... }.

보다 절차 적이거나 기능적인 스타일로 작성 class하고 레코드 유형을 정의하는 수단으로 사용하려는 경우 원하는 것 입니다.

Raku 디자인은 세터에서 영리한 작업을 수행하는 데 최적화되어 있지 않습니다. 최적화하기 어려운 것으로 간주되기 때문입니다. 레코드 유형에 필요한 것 이상입니다. 일부 언어에서는 할당 된 내용에 대한 유효성 검사를 원한다고 주장 할 수 있지만 Raku subset에서는 해당 유형으로 전환 할 수 있습니다 . 동시에 우리가 실제로 OO 디자인을하고 있다면, getter / setter와 관련하여 생각하지 않고 상태 모델을 숨기는 의미있는 행동의 API가 필요합니다. 어쨌든 OO를 수행하는 데있어 중요한 부분 인 데이터와 행동.

답변

class C {
  has $!v;
  multi method v                is rw {                  $!v }
  multi method v ( :$trace! )   is rw { say 'trace';     $!v }
  multi method v ( $new-value )       { say 'new-value'; $!v = $new-value }
}
my $c = C.new;
$c.v = 41;
say $c.v;            # 41
$c.v(:trace) = 42;   # trace
say $c.v;            # 42
$c.v(43);            # new-value
say $c.v;            # 43

has $!foo;
method foo () is rw { $!foo }