2009-03-18 2 views
27

perldoc on modules을 읽었으나 패키지 이름을 지정하는 권장 사항이 표시되지 않으므로 기본 또는 CPAN 모듈/패키지 이름과 충돌하지 않습니다. 과거 내장 또는 CPAN 패키지 이름과 충돌하지 않는 사용자 정의 Perl 모듈의 패키지 이름은 어떻게 선택합니까?

, 로컬 Session.pm 모듈을 개발, 나는 같은 내 회사의 이름을 사용하여 로컬 디렉토리를 만들었습니다

package Company::Session; 

... 그리고 Session.pm는 디렉토리에서 찾을 수 것 회사/.

하지만이 명명 규칙의 팬이 아닙니다. 차라리 패키지 계층 구조를 코드의 기능에 가깝게 지 으려고합니다. 그러나 그것이 CPAN에서 일반적으로 수행되는 방법입니다 ...

나는 근본적인 것이 빠져있는 것처럼 느낍니다. 또한 Damian의 Perl 모범 사례을 살펴 보았지만 올바른 장소를 조사하지 못했을 수도 있습니다 ...

패키지 네임 스페이스 충돌을 피하는 방법에 대한 권장 사항은 무엇입니까?

업데이트 w/관련 질문 : 패키지 이름 충돌이있는 경우, 어떻게 펄이 사용하는 하나를 선택 하는가? 모두에게 감사드립니다.

+0

: @INC 펄 컴파일시에 작성된 기본 값을 갖고 있지만,이 BEGIN 블록의 @INC 배열을 조작 직접적 PERL5LIB 환경 변수로 lib pragma 그것을 변경할 수있다 바로 자바 네임 스페이스가 도메인 네임으로 끝나는 이유이다 (java 나 javax로 시작하는 내장 클래스 제외). .NET은이 같은 문제를 가지고 있지만 ... – Powerlord

답변

38

네임 스페이스 Local::은이 용도로만 예약되었습니다. 이 접두사로 시작하는 모듈은 CPAN 또는 코어에 허용되지 않습니다. 또는 최상위 이름 (예 : My_Corp::Session 또는 단지 My_Session)의 밑줄을 사용할 수 있습니다. 밑줄이있는 모든 범주도 예약되었습니다. 이 내용은 perlmodlib의 "모듈 이름 선택"에 나와 있습니다.

두 예약은 모두 최상위 이름에만 적용됩니다. 예를 들어 Time::LocalText::CSV_XS이라는 CPAN 모듈이 있습니다.그러나 Local::TimeText_CSV::XS은 예약어로 CPAN에서는 허용되지 않습니다.

회사 이름 뒤에 모듈이 너무 많이 있습니다. (네가 정말로 일반적인 소리를내는 회사에서 일하지 않는다면). 반대 도메인 이름을 사용하는 것은 아마도 모듈을 다른 사람들에게 배포하지 않는다면 과잉 공격 일 것이다. (단,이 경우에, 당신은 아마 정상적인 모듈 이름을 등록해야합니다.) 펄이 충돌을 해결하는 방법

:

펄은 지정된 이름의 모듈 @INC에서 디렉토리를 검색합니다. 발견 된 첫 번째 모듈이 사용 된 모듈입니다. 그래서 @INC에있는 디렉토리의 순서는 (같은 이름을 가진 모듈이 다른 위치에 설치되어 있다면) 어떤 모듈이 사용될지를 결정합니다.

perl -V@INC의 내용을보고합니다 (우선 순위가 가장 높은 디렉토리가 먼저 나열됩니다). 그러나 실행시에 @INC을 조작하는 방법은 많이 있습니다.

BTW, Perl 6은 handle multiple modules with the same name by different authors이 될 수 있으며 하나의 프로그램에서 둘 이상을 사용할 수도 있습니다. 그러나 그것은 지금 당신의 문제를 해결하지 못합니다.

+0

이것은 내가 말할 수있는 것에서 결정적이다. – Marcus

2

좋아하는 패키지의 이름을 선택하고 "perl the-name-you-picked"으로 검색하면 무엇이 잘못 되었습니까?

+3

내 시스템 관리자가 내 미래와 충돌 할 CPAN 모듈을 설치하지 못하게하는 해결책을 찾고 있습니다 ... – Marcus

1

모듈 이름이 다른 사람과 충돌하지 않을 것이라는 확실한 확신이 필요한 경우 Java 책에서 페이지를 가져올 수 있습니다. 모듈 이름을 회사 도메인으로 지정합니다. 따라서 Example, Inc.에서 근무하고 있고 도메인 이름이 example.com 인 경우 HTML 파서 모듈의 이름을 Com :: Example :: HTML :: Parser 또는 Example :: Com :: HTML :: Parser로 지정합니다. 첫 번째의 장점은 여러 개의 서브 유닛이 있다면 그들은 모두 자신의 이름 공간을 가질 수 있지만 것입니다 여전히 일종의 함께 모듈 :

  • 닷컴 :: 예 :: 판매 :: FindCustomers
  • 컴 : : 예 :: IT :: ParseLogs
  • 닷컴 :: 예 :: QA ::

TESTSERVER하지만 처음에는 이상한 모양 않습니다.

+0

나는 그것을해라. 그것은 당신에게 최고의 보호를 주었다. Capital One에 있었을 때 우리는 CapOne :: *을 사용했습니다. 왜냐하면 우리는 충돌이 없을 것이라고 확신했기 때문에 다른 부서가 같은 시스템에 있고 똑같은 생각을하면 나쁜 일이 일어날 수있었습니다. –

8

회사 뒤에서 내부 모듈의 이름을 지정하는 데는 아무런 문제가 없습니다. 나는 항상 이것을한다. 내 코드의 90 %는 CPAN에서 끝나기 때문에 "정상적인"이름을 갖지만 내부 내용은 항상 ClientName::으로 시작합니다.

다른 사람들도이 작업을 수행 할 것으로 확신합니다.

+4

프로젝트의 이름 또는 그 이름. 마케팅이 이름을 바꾸기로 결정할 때의 PITA. ;) – Schwern

1

(I이 게시물은 오래 알고,하지만 난 지난 몇 달이을 제압 했어, 나는 내가의 무게라고 생각했다) 우리가 결정 직장에서

'지역 ::' 너무 지리적으로 느껴졌다. CompanyName :: 개발과 관련이없는 문제가 너무 많아서 건너 뜁니다. CompanyName은 수십 번 타이핑해야 할 때 길다.

그래서 우리는 '우리의 ::'에 정착했습니다. 물론 우리는 CPAN 모듈을 Our :: 접두사와 함께 사용하고자하는 날이있을 수 있으므로 'CPAN Safe'가 아닙니다. 하지만 기분이 좋아.

우리의 :: 데이터가 우리의 :: 앱이 설정 처리 및 것은, Getopt 물건

읽을 니스와 입력하기 좋은 않는 우리의 일반적인 응용 프로그램 프레임 워크 우리의 클래스 :: DBI 모듈 입니다.

+1

나는이 목적으로 'Our'가 예약 된 네임 스페이스에 추가되어야한다고 거의 생각한다. 세자를 두 드릴 수 없습니다. 내/우리의 변수 범위 지정과 비슷하게 느껴질 수도 있지만 ...어쩌면 은유가 충분하게 유지할 수 있습니다. – Marcus

2

@INC 변수는 모듈을 찾을 디렉토리 목록을 포함합니다. 첫 번째 항목부터 시작하여 요청 모듈을 찾지 못하면 next로 이동합니다. 이렇게 사이드 참고로

#!/usr/bin/perl 

BEGIN { 
    @INC =(); #no modules can be found 
} 

use strict; #error: Can't locate strict.pm in @INC (@INC contains:) 
+0

이것은 동료가 자신의 로컬 모듈 디렉토리를 첫 번째 @INC 항목으로 추가하여이를 해결한다고 말한 것입니다. – Marcus