박지훈.임프 님이 쓰신 글 :
: 스크린샷에 있는 소스를 들여다보고 옮겨써봤습니다.
:
: 언뜻 보시면 기존의 델파이 문법이랑 별로 달라보이지 않는데요.
: 뜯어보면 실로 엄청난 변화가 있네요. 델파이가 아닌 다른 언어라고 해도 믿을 정도...
:
: program ConvertIt;
:
: uses
:   Borland.Strings, Borland.Numbers, Borland.C// 이하 안보임
:
: const
:   AppTitle = 'Celsius to...';
:
: type
:   TForm1 = class(TForm)
:   private
:     DoitButton: TButton;
:     CelsiusEdit: TNumUpDown;
:     ResultList: TListBox;
:     MainMenu: TMainMenu;
:     FileItem: TMenuItem;
:     ExitItem: TMenuItem;
:     HelpItem: TMenuItem;
:     AboutItem: TMenuItem;
:     procedure DoitButtonClick(Sender: TObject; Arg// 이하 안보임
:     procedure ExitItemClick(Sender: TObject; Args:// 이하 안보임
:     procedure AboutItemClick(Sender: TObject; Args// 이하 안보임
:   protected
:     procedure ReadState;
:   public
:     constructor Create;
:   end;
:
: var
:   Form1: TForm1;
:
: procedure TForm1.Convert;
: var
:   LCelsius: Double;
: begin
:   LCelsius := DecimalToFloat(CelsiusEdit.Value);
:   with ResultList do
:   begin
:     BeginUpdate;
: // 이하 안보임
:
: 가장 윗 라인에 보시면, 다음과 같이 되어있죠.
: program ConvertIt;
: program 문은 파스칼 코드의 메인 유닛에 들어가는 것으로, 윈도우용 델파이에서는 프로젝트 소스에
: 위치하고 있었습니다. (Application 초기화하는 소스 유닛 아시죠?)
: 그런데 이게 폼 유닛으로 옮겨왔다는 것은, 프로젝트 파일 없이 폼 유닛만으로 프로젝트를 구성할
: 수 있게 되었다는 것인지...? 어떤 의미인지 혼란스럽군요.
:
: 또... interface 와 implementation 선언이 사라졌습니다.
: C++로 치면 헤더와 바디 소스를 함께 구성하는 파스칼의 특성상 이들 구문으로 선언부와 구현부를
: 나누는데.. 이게 없어지다니.. 좀 황당하네요.
:
: 그다음으로, uses 부분을 보시면, Borland.Strings, Borland.Numbers, 이런 식으로 앞에 Borland가
: 붙어있는 게 보입니다. 아마도 닷넷의 패키지들을 그대로 uses에서 사용할 수 있어서 구분하기 위해
: 델파이의 패키지들은 Borland를 추가한 거 같네요.
:
: 그리고, 사소하지만, Form 클래스 내에 보시면 정적으로 생성되는 컴퍼넌트들의 부분, 즉 폼 클래스
: 선언 내의 가장 앞부분에(버튼 등의 컴퍼넌트 선언 바로 앞) private로 적혀있네요. 기존의 델파이에선
: 이것이 없었죠. 또, TNumUpDown이라는 새로운 컴퍼넌트가 보이구요. 이름에 Edit가 붙이있는 걸 봐선
: 기존의 샘플 팔레트의 스핀에디트와 비슷한 것 같습니다.
:
: 그다음으로.. 버튼의 핸들러를 보시죠.
: OnClick 핸들러의 인자로 Sender외에 Args라는 인자가 추가된 모양입니다. 이게 무슨 타입인지는
: 짤려서 안보이는데... 어쨌든 이게 어디에 쓰일지 궁금하네요.
:
: 기존 델파이에서 OnClick 핸들러는 TNotifyEvent 타입이었는데, 이게 만약 닷넷 버전에서도 유효하다면
: 델파이 닷넷의 TNotifyEvent 타입에 Args라는 인자가 기본으로 추가되었을 수 있겠습니다.
: TNotifyEvent는 모든 이벤트의 가장 기본이 되는 이벤트 타입인데, 그렇다면 모든 이벤트에 Args가
: 추가되었을 가능성도 있겠군요.
:
: 그리고.. (이전의) 임플멘테이션 부분을 보면, 시작부분의 {$R *.dfm} 부분, 즉 폼 리소스를 참조하라는
: 지시자가 사라졌습니다. 또, 폼의 생성자에 인자가 없는 것도 이상해보이는군요.
: 함수내에 있는 DecimalToFloat()라는 메소드도 없던 거네요. 닷넷 런타임인가...
:
: 보시다시피.. 기존의 델파이나 카일릭스와는 너무 변했네요.
: interface 와 implementation 선언이 없어진 것을 보면 아예 기존의 파스칼 언어 자체의 변화도
: 클 것 같습니다.
:
: 사소하다고 하실 분도 있겠지만.. 제게는 상당히 생소해보이네요.
: 비주얼베이직이 닷넷 버전에서 변한 것 만큼은 아니길 바랍니다..
:
: 그럼...

다음은 델마당의 양병규님의 글입니다.

----------------------------------------------------------------------------------------

제가 보기엔 기존의 델파이와 다른게 하나도 없습니다.

말씀하신 내용중에서 유닛명에 Borland. 가 붙은것(이거는 확실히 달라진것같슴다) 말고는 일반적인 델파이와 다를게 없는 내용입니다. 다만...

아직 알파버전이기때문에 그렇게하는것일겁니다..
볼랜드에서는 알파버전정도의 데모를 보여줄때 항상 그렇게 합니다.

별도의 유닛이 없이 그냥 프로젝트 소스에 직접 작성을 합니다.

작년이었던가요? 카일릭스 킥스타트를 미 볼랜드에서 와서 직접 진행할때 국내 50개 업체가 초정이 되서 미리 구경을한적이 있었는데 저도 그때 참가했었습니다. 그때도 데모를 작성하는데 그냥 유닛이 없이 메인유닛에다가 직접 코딩을하는것을 봤습니다.

프로젝트소스에 작성하다보니 interface 와 implementation은 당연히 없고여....

{$R *.dfm}이 없는것도 당연합니다.

왜냐면.... *.dfm 이란건 이 유닛과 같은 이름의 dfm확장자를 가진 파일을 리소스에 포함하라는것인데... 아직 알파버전이라 dfm파일을 만들어줄 폼디자이너가 없기때문에 dfm파일 자체가 생성되지 않으니 {$R *.dfm}를 추가하면 에러만 나겠지요...

그래서 이런경우 ....
폼에 사용된 콤포넌트들을 몽땅 동적으로 생성해 줍니다.

Args타입이 추가된다는건 뭐 그리 놀라운일이 아니고여.... 그 환경에서 필요한 타입이니 만드는거겠죠....

생성자에서 접근지정자를두고 각 컨트롤들을 선언하는것은 원래 오브젝트파스칼이나 C++이나 자바나 다 그게 그거지요....

델파이닷넷은 CLX를 사용한다고 하는데 그것은 영업적인 이유로 이름만 차용하는것이고 실제로는 VCL과 CLX를 합친 형태 즉, 윈도우API와 QT API를 모두 사용한다고 하는것으로 봐서 Strings.pas라는 똑같은 구조의 유닛을 윈도우 API적으로 구현한것과 QT로 구현한것과 볼랜드에서 직접구현한것등으로 나누어서 uses에 Borland.Strings 와 같은 형식으로 붙이는것이 아닐까 추측됩니다. 현재 델파이6와 카일릭스는 한 유닛안에 컴파일러 지시자를 이용해서 플렛폼을 구분하게 되어있어서 유닛이 매우 지저분합니다. 그래서 아마도 똑같은 유닛을 플렛폼별로 나누어서 만들어서 uses에서 '플렛폼.유닛' 과같은 형식으로 사용할수있게하는것이 아닐까라고 추측이 됩니다. 물론 순전히 양병규 혼자의 생각입니다. 아마도 제 생각이 맞다면 Borland.SysUtils Windows.SysUtils QT.SysUtils등과 같이 붙겠군요(아닌가부다 --; )

암튼....

제가 보기엔 델파이파스칼에는 큰변화가 없는것같습니다.

아시다시피 볼랜드는 언어를 수정하는것은 최대한 절재하고 있습니다.
아무리 플렛폼이 달라져도 기존의 델파이와 똑같은 환경을 만들고자 노력할겁니다.
카일릭스도 그랬구요....(델파이랑 진짜루 똑같지여 ^^)
현재의 델파이 파스칼은 볼랜드의 자존심입니다.(쩝~ 그게 단점일수도 있지여 --; )

좌우지간...

델/파/이/만/세