1C: এন্টারপ্রাইজ ডেভেলপমেন্ট টুলস-এর প্রযুক্তি প্ল্যাটফর্ম হিসাবে Eclipse

সম্ভবত অন্ধকার দীর্ঘকাল থেকে কোন বিশেষ পরিচয়ের প্রয়োজন নেই। Eclipse জাভা ডেভেলপমেন্ট টুলস এর জন্য অনেক মানুষ Eclipse এর সাথে পরিচিতজেডিটি) এটি এই জনপ্রিয় ওপেন সোর্স জাভা IDE যা বেশিরভাগ বিকাশকারীরা "Eclipse" শব্দের সাথে যুক্ত করে। যাইহোক, Eclipse হল ডেভেলপমেন্ট টুলস (Eclipse Platform) একীভূত করার জন্য একটি এক্সটেনসিবল প্ল্যাটফর্ম এবং JDT সহ এর ভিত্তিতে তৈরি করা বেশ কিছু IDE। Eclipse হল Eclipse প্রজেক্ট, উচ্চ-স্তরের প্রকল্প যা Eclipse Platform এবং JDT-এর উন্নয়নের সমন্বয় সাধন করে এবং Eclipse SDK, সেই বিকাশের ফলাফল। অবশেষে, Eclipse হল একটি ওপেন সোর্স ফাউন্ডেশন যার একটি বিশাল সম্প্রদায়ের প্রকল্প, যার সবকটিই জাভাতে লেখা নয় বা ডেভেলপমেন্ট টুলের সাথে সম্পর্কিত নয় (উদাহরণস্বরূপ, প্রকল্প Eclipse IoT и গ্রহন বিজ্ঞান) Eclipse এর জগত খুবই বৈচিত্র্যময়।

এই নিবন্ধে, যা প্রকৃতির সংক্ষিপ্ত বিবরণ, আমরা সমন্বিত উন্নয়ন সরঞ্জাম তৈরির জন্য একটি প্ল্যাটফর্ম হিসাবে Eclipse আর্কিটেকচারের কিছু মৌলিক বিষয়গুলি দেখার চেষ্টা করব এবং প্রযুক্তির ভিত্তি তৈরিকারী Eclipse উপাদানগুলির প্রাথমিক ধারণা দেব। "নতুন কনফিগারার" 1C এর জন্য প্ল্যাটফর্ম: এন্টারপ্রাইজ। 1C: এন্টারপ্রাইজ ডেভেলপমেন্ট টুলস. অবশ্যই, এই ধরনের পর্যালোচনা অবশ্যম্ভাবীভাবে বহুলাংশে উপরিভাগের এবং বরং সীমিত হবে, কারণ আমরা লক্ষ্য শ্রোতা হিসাবে শুধুমাত্র Eclipse বিকাশকারীদের উপর ফোকাস করছি না। যাইহোক, আমরা আশা করি যে এমনকি অভিজ্ঞ Eclipse বিকাশকারীরাও নিবন্ধে আকর্ষণীয় তথ্য খুঁজে পেতে সক্ষম হবেন। উদাহরণস্বরূপ, আমরা "গ্রহণের গোপনীয়তা" এর একটি সম্পর্কে কথা বলব, একটি অপেক্ষাকৃত নতুন এবং স্বল্প পরিচিত প্রকল্প। হাতে গ্রহন, যা 1C দ্বারা প্রতিষ্ঠিত এবং সমর্থিত হয়েছিল।

Eclipse আর্কিটেকচারের ভূমিকা

আসুন প্রথমে উদাহরণটি ব্যবহার করে Eclipse আর্কিটেকচারের কিছু সাধারণ দিক দেখি Eclipse Java ডেভেলপমেন্ট টুলস (জেডিটি)। উদাহরণ হিসেবে JDT-এর পছন্দ আকস্মিক নয়। এটি Eclipse-এ প্রদর্শিত প্রথম সমন্বিত উন্নয়ন পরিবেশ। অন্যান্য *DT Eclipse প্রকল্পগুলি, যেমন Eclipse C/C++ ডেভেলপমেন্ট টুলিং (CDT), পরে তৈরি করা হয়েছিল এবং JDT থেকে মৌলিক স্থাপত্য নীতি এবং পৃথক সোর্স কোডের খণ্ড উভয়ই ধার করে। 1C:Enterprise ডেভেলপমেন্ট টুলস সহ Eclipse Platform-এর উপরে নির্মিত প্রায় যেকোনো IDE-এর জন্য JDT-তে দেওয়া স্থাপত্যের মৌলিক বিষয়গুলি আজও প্রাসঙ্গিক।

প্রথমত, এটি লক্ষ করা উচিত যে Eclipse একটি মোটামুটি স্পষ্ট আর্কিটেকচারাল লেয়ারিং দ্বারা চিহ্নিত করা হয়েছে, নির্দিষ্ট প্রোগ্রামিং ভাষাগুলিকে সমর্থন করার জন্য ডিজাইন করা কার্যকারিতা থেকে ভাষা-স্বাধীন কার্যকারিতা আলাদা করা এবং সংশ্লিষ্ট উপাদানগুলি থেকে UI-স্বাধীন "কোর" উপাদানগুলিকে পৃথক করা। সমর্থনকারী ইউজার ইন্টারফেস সহ।

এইভাবে, Eclipse Platform একটি সাধারণ, ভাষা-স্বাধীন পরিকাঠামোকে সংজ্ঞায়িত করে এবং জাভা ডেভেলপমেন্ট টুলগুলি Eclipse-এ একটি পূর্ণ বৈশিষ্ট্যযুক্ত Java IDE যুক্ত করে। Eclipse Platform এবং JDT উভয়ই বেশ কয়েকটি উপাদান নিয়ে গঠিত, যার প্রত্যেকটি হয় একটি UI-স্বাধীন "কোর" বা একটি UI স্তর (চিত্র 1) এর অন্তর্গত।

ভাত। 1. Eclipse Platform এবং JDT

আসুন Eclipse Platform এর প্রধান উপাদানগুলির তালিকা করি:

• রানটাইম — প্লাগইন পরিকাঠামো সংজ্ঞায়িত করে। Eclipse একটি মডুলার আর্কিটেকচার দ্বারা চিহ্নিত করা হয়। মূলত, Eclipse হল "এক্সটেনশন পয়েন্ট" এবং "এক্সটেনশন" এর একটি সংগ্রহ।
• কর্মক্ষেত্র - এক বা একাধিক প্রকল্প পরিচালনা করে। একটি প্রকল্পে ফোল্ডার এবং ফাইল থাকে যা সরাসরি ফাইল সিস্টেমে ম্যাপ করা হয়।
• স্ট্যান্ডার্ড উইজেট টুলকিট (SWT) - অপারেটিং সিস্টেমের সাথে একত্রিত মৌলিক ব্যবহারকারী ইন্টারফেস উপাদান প্রদান করে।
• জেফেস — SWT এর উপরে নির্মিত বেশ কয়েকটি UI ফ্রেমওয়ার্ক প্রদান করে।
• workbench — Eclipse UI দৃষ্টান্ত সংজ্ঞায়িত করে: সম্পাদক, দৃষ্টিভঙ্গি, দৃষ্টিভঙ্গি।

এটা অবশ্যই বলা উচিত যে Eclipse প্ল্যাটফর্ম ডিবাগ, তুলনা, অনুসন্ধান এবং দল সহ সমন্বিত উন্নয়ন সরঞ্জামগুলি তৈরির জন্য আরও অনেক দরকারী উপাদান সরবরাহ করে। বিশেষ উল্লেখ করা উচিত JFace টেক্সট - সোর্স কোডের "স্মার্ট এডিটর" তৈরির ভিত্তি। দুর্ভাগ্যবশত, এমনকি এই উপাদানগুলির একটি সারসরি পরীক্ষা, সেইসাথে UI স্তর উপাদানগুলি, এই নিবন্ধের সুযোগের মধ্যে সম্ভব নয়, তাই এই বিভাগের বাকি অংশে আমরা নিজেদেরকে প্রধান "মূল" উপাদানগুলির একটি ওভারভিউতে সীমাবদ্ধ রাখব Eclipse Platform এবং JDT.

মূল রানটাইম

Eclipse প্লাগইন পরিকাঠামো উপর ভিত্তি করে ওএসজিআই এবং প্রকল্প দ্বারা প্রদান করা হয় Eclipse Equinox. প্রতিটি Eclipse প্লাগইন একটি OSGi বান্ডেল। OSGi স্পেসিফিকেশন সংজ্ঞায়িত করে, বিশেষ করে, সংস্করণ এবং নির্ভরতা রেজোলিউশনের প্রক্রিয়া। এই স্ট্যান্ডার্ড মেকানিজমগুলি ছাড়াও, ইকুইনক্স ধারণাটি প্রবর্তন করে সম্প্রসারণ পয়েন্ট. প্রতিটি প্লাগইন তার নিজস্ব এক্সটেনশন পয়েন্ট সংজ্ঞায়িত করতে পারে এবং একই বা অন্য প্লাগইন দ্বারা সংজ্ঞায়িত এক্সটেনশন পয়েন্ট ব্যবহার করে সিস্টেমে অতিরিক্ত কার্যকারিতা ("এক্সটেনশন") প্রবর্তন করতে পারে। OSGi এবং Equinox প্রক্রিয়ার কোন বিস্তারিত বর্ণনা এই নিবন্ধের সুযোগের বাইরে। আসুন আমরা শুধু লক্ষ্য করি যে Eclipse-এ মডুলারাইজেশন মোট (Runtime সহ যেকোনো সাবসিস্টেম, এক বা একাধিক প্লাগইন নিয়ে গঠিত), এবং Eclipse-এর প্রায় সবকিছুই একটি এক্সটেনশন। অধিকন্তু, এই নীতিগুলি OSGi প্রবর্তনের অনেক আগে Eclipse আর্কিটেকচারে এম্বেড করা হয়েছিল (সে সময়ে তারা তাদের নিজস্ব প্রযুক্তি ব্যবহার করেছিল, অনেকটা OSGi-এর মতো)।

মূল কর্মক্ষেত্র

Eclipse প্ল্যাটফর্মের উপরে নির্মিত প্রায় কোনো সমন্বিত উন্নয়ন পরিবেশ Eclipse ওয়ার্কস্পেসের সাথে কাজ করে। এটি এমন একটি কর্মক্ষেত্র যা সাধারণত IDE-তে বিকাশিত অ্যাপ্লিকেশনটির উত্স কোড ধারণ করে। ওয়ার্কস্পেস সরাসরি ফাইল সিস্টেমে ম্যাপ করে এবং ফোল্ডার এবং ফাইল ধারণ করে এমন প্রোজেক্ট নিয়ে গঠিত। এই প্রকল্প, ফোল্ডার, এবং ফাইল বলা হয় সম্পদ কর্মক্ষেত্র Eclipse-এ ওয়ার্কস্পেস বাস্তবায়ন ফাইল সিস্টেমের সাথে সম্পর্কিত একটি ক্যাশে হিসাবে কাজ করে, যা রিসোর্স ট্রির ট্রাভার্সালকে উল্লেখযোগ্যভাবে দ্রুত করা সম্ভব করে তোলে। এছাড়াও, কর্মক্ষেত্র সহ বেশ কয়েকটি অতিরিক্ত পরিষেবা সরবরাহ করে সম্পদ পরিবর্তনের জন্য বিজ্ঞপ্তি প্রক্রিয়া и ক্রমবর্ধমান নির্মাতা অবকাঠামো.

কোর রিসোর্স কম্পোনেন্ট (org.eclipse.core.resources প্লাগইন) ওয়ার্কস্পেস এবং এর রিসোর্সকে সমর্থন করার জন্য দায়ী। বিশেষ করে, এই উপাদানটি ফর্মে কর্মক্ষেত্রে প্রোগ্রাম্যাটিক অ্যাক্সেস প্রদান করে সম্পদ মডেল. এই মডেলের সাথে কার্যকরীভাবে কাজ করার জন্য, ক্লায়েন্টদের একটি সম্পদের লিঙ্ক উপস্থাপন করার একটি সহজ উপায় প্রয়োজন। এই ক্ষেত্রে, ক্লায়েন্ট অ্যাক্সেস থেকে সরাসরি মডেলে সম্পদের অবস্থা সঞ্চয় করে এমন বস্তুটি লুকিয়ে রাখা বাঞ্ছনীয়। অন্যথায়, উদাহরণস্বরূপ, একটি ফাইল মুছে ফেলার ক্ষেত্রে, ক্লায়েন্ট পরবর্তী সমস্যাগুলির সাথে মডেলটিতে আর নেই এমন একটি বস্তু ধরে রাখতে পারে। Eclipse নামক কিছু ব্যবহার করে এই সমস্যার সমাধান করে হাতল সম্পদ হ্যান্ডেল একটি কী হিসাবে কাজ করে (এটি কেবলমাত্র কর্মক্ষেত্রে সংস্থানের পথ জানে) এবং অভ্যন্তরীণ মডেল অবজেক্টে অ্যাক্সেস সম্পূর্ণভাবে নিয়ন্ত্রণ করে, যা সরাসরি সম্পদের অবস্থা সম্পর্কে তথ্য সঞ্চয় করে। এই নকশা প্যাটার্ন একটি ভিন্নতা হ্যান্ডেল/শরীর.

ভাত। চিত্র 2 হ্যান্ডেল/বডি ইডিয়মকে রিসোর্স মডেলে প্রয়োগ করা হয়েছে। আইরিসোর্স ইন্টারফেস একটি রিসোর্সের হ্যান্ডেলকে প্রতিনিধিত্ব করে এবং এটি একটি API, রিসোর্স ক্লাসের বিপরীতে, যা এই ইন্টারফেসটি প্রয়োগ করে এবং রিসোর্স ইনফো ক্লাস, যা বডিকে প্রতিনিধিত্ব করে, যা এপিআই নয়। আমরা জোর দিই যে হ্যান্ডেল শুধুমাত্র ওয়ার্কস্পেস রুটের সাপেক্ষে রিসোর্সের পথ জানে এবং রিসোর্স তথ্যের লিঙ্ক ধারণ করে না। সম্পদ তথ্য বস্তু একটি তথাকথিত "উপাদান গাছ" গঠন করে। এই ডাটা স্ট্রাকচার মেমরিতে সম্পূর্ণরূপে বাস্তবায়িত হয়। একটি হ্যান্ডেলের সাথে সম্পর্কিত রিসোর্স ইনফো ইনস্ট্যান্স খুঁজে পেতে, উপাদান গাছটি সেই হ্যান্ডেলে সংরক্ষিত পাথ অনুযায়ী অতিক্রম করা হয়।

ভাত। 2. আইরিসোর্স এবং রিসোর্স ইনফো

আমরা পরে দেখব, রিসোর্স মডেলের মৌলিক নকশা (আমরা এটিকে হ্যান্ডেল-ভিত্তিক বলতে পারি) অন্যান্য মডেলের জন্যও Eclipse-এ ব্যবহৃত হয়। আপাতত, এই ডিজাইনের কিছু স্বতন্ত্র বৈশিষ্ট্যের তালিকা করা যাক:

• হ্যান্ডেল একটি মান বস্তু। মান বস্তু অপরিবর্তনীয় বস্তু যার সমতা পরিচয়ের উপর ভিত্তি করে নয়। এই ধরনের বস্তু নিরাপদে হ্যাশড পাত্রে একটি কী হিসাবে ব্যবহার করা যেতে পারে। হ্যান্ডেলের একাধিক উদাহরণ একই সংস্থানকে উল্লেখ করতে পারে। তাদের তুলনা করতে, আপনাকে সমান (অবজেক্ট) পদ্ধতি ব্যবহার করতে হবে।
• হ্যান্ডেল একটি সম্পদের আচরণকে সংজ্ঞায়িত করে, কিন্তু সম্পদের অবস্থা সম্পর্কে তথ্য ধারণ করে না (এটি সঞ্চয় করে একমাত্র ডেটা "কী", সম্পদের পথ)।
• হ্যান্ডেল এমন একটি সংস্থানকে উল্লেখ করতে পারে যা বিদ্যমান নেই (হয় এমন একটি সংস্থান যা এখনও তৈরি করা হয়নি, বা একটি সংস্থান যা ইতিমধ্যে মুছে ফেলা হয়েছে)। IResource.exists() পদ্ধতি ব্যবহার করে একটি সম্পদের অস্তিত্ব পরীক্ষা করা যেতে পারে।
• কিছু ক্রিয়াকলাপ সম্পূর্ণরূপে হ্যান্ডেলে সঞ্চিত তথ্যের উপর ভিত্তি করে প্রয়োগ করা যেতে পারে (তথাকথিত হ্যান্ডেল-শুধুমাত্র অপারেশন)। উদাহরণ হল IResource.getParent(), getFullPath(), ইত্যাদি। এই ধরনের অপারেশন সফল হওয়ার জন্য সম্পদের অস্তিত্বের প্রয়োজন নেই। যে ক্রিয়াকলাপগুলির সফলতার জন্য একটি সংস্থান বিদ্যমান থাকা প্রয়োজন সেগুলি যদি সংস্থান বিদ্যমান না থাকে তবে একটি CoreException ফেলে।

Eclipse ওয়ার্কস্পেস রিসোর্স পরিবর্তনগুলিকে সূচিত করার জন্য একটি দক্ষ প্রক্রিয়া প্রদান করে (চিত্র 3)। Eclipse IDE-এর মধ্যে সম্পাদিত ক্রিয়াকলাপের ফলে বা ফাইল সিস্টেমের সাথে সিঙ্ক্রোনাইজেশনের ফলে সম্পদগুলি পরিবর্তন হতে পারে। উভয় ক্ষেত্রেই, ক্লায়েন্ট যারা বিজ্ঞপ্তিতে সাবস্ক্রাইব করেন তাদের "রিসোর্স ডেল্টা" আকারে পরিবর্তন সম্পর্কে বিস্তারিত তথ্য প্রদান করা হয়। একটি ব-দ্বীপ একটি ওয়ার্কস্পেস রিসোর্স (সাব-) গাছের দুটি অবস্থার মধ্যে পরিবর্তনগুলি বর্ণনা করে এবং এটি নিজেই একটি গাছ, যার প্রতিটি নোড একটি সম্পদের পরিবর্তন বর্ণনা করে এবং পরবর্তী স্তরে ডেল্টাগুলির একটি তালিকা ধারণ করে যা চাইল্ড রিসোর্সে পরিবর্তনগুলি বর্ণনা করে৷

ভাত। 3. IResourceChangeEvent এবং IResourceDelta

রিসোর্স ডেল্টার উপর ভিত্তি করে বিজ্ঞপ্তি পদ্ধতির নিম্নলিখিত বৈশিষ্ট্য রয়েছে:

• একটি একক পরিবর্তন এবং অনেক পরিবর্তন একই কাঠামো ব্যবহার করে বর্ণনা করা হয়েছে, যেহেতু ব-দ্বীপ পুনরাবৃত্ত রচনার নীতি ব্যবহার করে নির্মিত হয়েছে। সাবস্ক্রাইবার ক্লায়েন্টরা ডেল্টাস গাছের মাধ্যমে রিকারসিভ ডিসেন্ট ব্যবহার করে রিসোর্স পরিবর্তনের বিজ্ঞপ্তি প্রক্রিয়া করতে পারে।
• ব-দ্বীপে সম্পদের পরিবর্তন সম্পর্কে সম্পূর্ণ তথ্য রয়েছে, এর গতিবিধি এবং/অথবা এটির সাথে সম্পর্কিত "মার্কার" এর পরিবর্তনগুলি সহ (উদাহরণস্বরূপ, সংকলন ত্রুটিগুলি চিহ্নিতকারী হিসাবে উপস্থাপন করা হয়)।
• যেহেতু রিসোর্স রেফারেন্সগুলি হ্যান্ডেলের মাধ্যমে তৈরি করা হয়, তাই ডেল্টা স্বাভাবিকভাবেই একটি দূরবর্তী সংস্থানকে উল্লেখ করতে পারে।

আমরা শীঘ্রই দেখতে পাব, রিসোর্স মডেল পরিবর্তনের নোটিফিকেশন মেকানিজমের ডিজাইনের প্রধান উপাদানগুলি অন্যান্য হ্যান্ডেল-ভিত্তিক মডেলগুলির জন্যও প্রাসঙ্গিক।

জেডিটি কোর

Eclipse ওয়ার্কস্পেস রিসোর্স মডেল একটি মৌলিক ভাষা-অজ্ঞেয়বাদী মডেল। JDT কোর কম্পোনেন্ট (plugin org.eclipse.jdt.core) জাভা দৃষ্টিকোণ থেকে ওয়ার্কস্পেস গঠন নেভিগেট এবং বিশ্লেষণ করার জন্য একটি API প্রদান করে, তথাকথিত "জাভা মডেল" (জাভা মডেল) এই APIটি জাভা উপাদানগুলির পরিপ্রেক্ষিতে সংজ্ঞায়িত করা হয়েছে, অন্তর্নিহিত সংস্থান মডেল API এর বিপরীতে, যা ফোল্ডার এবং ফাইলগুলির পরিপ্রেক্ষিতে সংজ্ঞায়িত করা হয়েছে। জাভা উপাদান গাছের প্রধান ইন্টারফেসগুলি চিত্রে দেখানো হয়েছে। 4.

ভাত। 4. জাভা মডেল উপাদান

জাভা মডেল রিসোর্স মডেল হিসাবে একই হ্যান্ডেল/বডি ইডিয়ম ব্যবহার করে (চিত্র 5)। IJavaElement হ্যান্ডেল, এবং JavaElementInfo শরীরের ভূমিকা পালন করে। IJavaElement ইন্টারফেস সমস্ত জাভা উপাদানের জন্য সাধারণ একটি প্রোটোকল সংজ্ঞায়িত করে। এর কিছু পদ্ধতি হ্যান্ডেল-অনলি: getElementName(), getParent(), ইত্যাদি। JavaElementInfo অবজেক্ট সংশ্লিষ্ট উপাদানের অবস্থা সংরক্ষণ করে: এর গঠন এবং গুণাবলী।

ভাত। 5. IJavaElement এবং JavaElementInfo

রিসোর্স মডেলের তুলনায় জাভা মডেলের মৌলিক হ্যান্ডেল/বডি ডিজাইন বাস্তবায়নে কিছু পার্থক্য রয়েছে। উপরে উল্লিখিত হিসাবে, রিসোর্স মডেলে, উপাদান ট্রি, যার নোডগুলি রিসোর্স ইনফো অবজেক্ট, সম্পূর্ণরূপে মেমরিতে থাকে। কিন্তু জাভা মডেলে রিসোর্স ট্রি থেকে উল্লেখযোগ্যভাবে বেশি সংখ্যক উপাদান থাকতে পারে, কারণ এটি .java এবং .class ফাইলের অভ্যন্তরীণ কাঠামোকেও উপস্থাপন করে: প্রকার, ক্ষেত্র এবং পদ্ধতি।

মেমরিতে উপাদানের সম্পূর্ণ ট্রিকে সম্পূর্ণরূপে বাস্তবায়িত করা এড়াতে, জাভা মডেল বাস্তবায়ন উপাদান তথ্যের একটি সীমিত আকারের LRU ক্যাশে ব্যবহার করে, যেখানে কীটি হল IJavaElement হ্যান্ডেল। উপাদান গাছ নেভিগেট করা হয় হিসাবে উপাদান তথ্য বস্তু চাহিদা তৈরি করা হয়. এই ক্ষেত্রে, সর্বনিম্ন ঘন ঘন ব্যবহৃত আইটেমগুলি ক্যাশে থেকে উচ্ছেদ করা হয়, এবং মডেলের মেমরি খরচ নির্দিষ্ট ক্যাশে আকারের মধ্যে সীমাবদ্ধ থাকে। এটি হ্যান্ডেল-ভিত্তিক ডিজাইনের আরেকটি সুবিধা, যা ক্লায়েন্ট কোড থেকে এই ধরনের বাস্তবায়নের বিবরণ সম্পূর্ণরূপে লুকিয়ে রাখে।

জাভা উপাদানগুলির পরিবর্তনগুলিকে জানানোর পদ্ধতিটি উপরে আলোচিত ওয়ার্কস্পেস রিসোর্সে পরিবর্তনগুলি ট্র্যাক করার পদ্ধতির মতোই। জাভা মডেলের পরিবর্তনগুলি নিরীক্ষণ করতে ইচ্ছুক একজন ক্লায়েন্ট বিজ্ঞপ্তিগুলিতে সাবস্ক্রাইব করে, যা একটি ElementChangedEvent অবজেক্ট হিসাবে উপস্থাপন করা হয় যাতে একটি IJavaElementDelta (চিত্র 6) রয়েছে।

ভাত। 6. ElementChangedEvent এবং IJavaElementDelta

জাভা মডেলে মেথড বডি বা নামের রেজোলিউশন সম্পর্কে তথ্য নেই, তাই জাভাতে লেখা কোডের বিস্তারিত বিশ্লেষণের জন্য, JDT কোর একটি অতিরিক্ত (নন-হ্যান্ডেল-ভিত্তিক) মডেল প্রদান করে: বিমূর্ত সিনট্যাক্স গাছ (বিমূর্ত সিনট্যাক্স ট্রি, AST)। AST উৎস টেক্সট পার্স করার ফলাফল উপস্থাপন করে। AST নোডগুলি সোর্স মডিউলের কাঠামোর উপাদানগুলির সাথে মিলে যায় (ঘোষণা, অপারেটর, এক্সপ্রেশন, ইত্যাদি) এবং এতে উত্স পাঠ্যের সংশ্লিষ্ট উপাদানের স্থানাঙ্ক সম্পর্কে তথ্য রয়েছে, সেইসাথে (একটি বিকল্প হিসাবে) নামের রেজোলিউশন সম্পর্কে তথ্য রয়েছে তথাকথিত লিঙ্কের ফর্ম বাইন্ডিং. বাইন্ডিং হল এমন অবজেক্ট যা নামযুক্ত সত্তাকে উপস্থাপন করে, যেমন ধরন, পদ্ধতি এবং ভেরিয়েবল, যা কম্পাইলারের কাছে পরিচিত। AST নোডের বিপরীতে, যা একটি গাছ গঠন করে, বাইন্ডিংগুলি ক্রস-রেফারেন্সিং সমর্থন করে এবং সাধারণত একটি গ্রাফ তৈরি করে। বিমূর্ত ক্লাস ASTNode হল সকল AST নোডের জন্য সাধারণ বেস ক্লাস। ASTNode সাবক্লাসগুলি জাভা ভাষার নির্দিষ্ট সিনট্যাকটিক গঠনের সাথে মিলে যায়।

যেহেতু সিনট্যাক্স ট্রিগুলি উল্লেখযোগ্য পরিমাণে মেমরি ব্যবহার করতে পারে, জেডিটি সক্রিয় সম্পাদকের জন্য শুধুমাত্র একটি AST ক্যাশে করে। জাভা মডেলের বিপরীতে, এএসটি সাধারণত একটি "মধ্যবর্তী," "অস্থায়ী" মডেল হিসাবে দেখা হয় যার সদস্যদের ক্লায়েন্টদের দ্বারা এএসটি তৈরির দিকে পরিচালিত অপারেশনের প্রেক্ষাপটের বাইরে উল্লেখ করা উচিত নয়।

তালিকাভুক্ত তিনটি মডেল (জাভা মডেল, এএসটি, বাইন্ডিং) একসাথে JDT-তে "বুদ্ধিমান উন্নয়ন সরঞ্জাম" তৈরির ভিত্তি তৈরি করে, যার মধ্যে বিভিন্ন "সহায়ক" সহ একটি শক্তিশালী জাভা সম্পাদক, সোর্স কোড প্রক্রিয়াকরণের জন্য বিভিন্ন ক্রিয়া (আমদানি তালিকা সংগঠিত করা সহ) কাস্টমাইজড শৈলী অনুযায়ী নাম এবং বিন্যাস, অনুসন্ধান এবং রিফ্যাক্টরিং টুল। এই ক্ষেত্রে, জাভা মডেলটি একটি বিশেষ ভূমিকা পালন করে, যেহেতু এটিই এটি ব্যবহার করা হয় যা অ্যাপ্লিকেশনটির কাঠামোর একটি চাক্ষুষ উপস্থাপনার জন্য ভিত্তি হিসাবে ব্যবহৃত হয় (উদাহরণস্বরূপ, প্যাকেজ এক্সপ্লোরার, আউটলাইন, অনুসন্ধান, কল হায়ারার্কি এবং টাইপ হায়ারার্কি)।

1C: এন্টারপ্রাইজ ডেভেলপমেন্ট টুলস-এ ব্যবহৃত Eclipse উপাদান

চিত্রে। চিত্র 7 এ Eclipse উপাদানগুলি দেখায় যা 1C: এন্টারপ্রাইজ ডেভেলপমেন্ট টুলস-এর প্রযুক্তি প্ল্যাটফর্মের ভিত্তি তৈরি করে।

ভাত। 7. 1C এর জন্য একটি প্ল্যাটফর্ম হিসাবে Eclipse: এন্টারপ্রাইজ ডেভেলপমেন্ট টুলস

Eclipse প্ল্যাটফর্ম মৌলিক অবকাঠামো প্রদান করে। আমরা পূর্ববর্তী বিভাগে এই অবকাঠামোর কিছু দিক দেখেছি।

Eclipse মডেলিং ফ্রেমওয়ার্ক (EMF) কাঠামোগত ডেটা মডেলিংয়ের একটি সাধারণ উপায় প্রদান করে। EMF Eclipse প্ল্যাটফর্মের সাথে একীভূত, তবে নিয়মিত জাভা অ্যাপ্লিকেশনগুলিতে আলাদাভাবে ব্যবহার করা যেতে পারে। প্রায়শই, নতুন Eclipse বিকাশকারীরা ইতিমধ্যে EMF এর সাথে ভালভাবে পরিচিত, যদিও তারা এখনও Eclipse প্ল্যাটফর্মের জটিলতাগুলি সম্পূর্ণরূপে বুঝতে পারে না। এই ধরনের সু-যোগ্য জনপ্রিয়তার একটি কারণ হল সার্বজনীন নকশা, যার মধ্যে রয়েছে অন্যান্য জিনিসের মধ্যে, একটি ইউনিফাইড মেটা-লেভেল এপিআই, যা আপনাকে যেকোনো EMF মডেলের সাথে সাধারণভাবে কাজ করতে দেয়। EMF দ্বারা প্রদত্ত মডেল অবজেক্টের মৌলিক বাস্তবায়ন এবং মেটা-মডেলের উপর ভিত্তি করে মডেল কোড তৈরি করার জন্য সাবসিস্টেম উল্লেখযোগ্যভাবে উন্নয়নের গতি বাড়ায় এবং ত্রুটির সংখ্যা কমায়। EMF-এ মডেলগুলিকে সিরিয়ালাইজ করা, মডেলের পরিবর্তনগুলি ট্র্যাক করা এবং আরও অনেক কিছু করার প্রক্রিয়া রয়েছে৷

যে কোনো সত্যিকারের সাধারণ-উদ্দেশ্যের সরঞ্জামের মতো, EMF মডেলিং সমস্যাগুলির একটি বিস্তৃত পরিসরের সমাধানের জন্য উপযুক্ত, তবে কিছু শ্রেণীর মডেলের (উদাহরণস্বরূপ, উপরে আলোচিত হ্যান্ডেল-ভিত্তিক মডেলগুলি) আরও বিশেষ মডেলিং সরঞ্জামের প্রয়োজন হতে পারে। EMF সম্পর্কে কথা বলা একটি অকৃতজ্ঞ কাজ, বিশেষ করে একটি নিবন্ধের সীমিত সীমার মধ্যে, যেহেতু এটি একটি পৃথক বইয়ের বিষয়, এবং একটি বরং মোটা। আসুন আমরা কেবল লক্ষ্য করি যে EMF-এর অন্তর্নিহিত সাধারণীকরণের উচ্চ-মানের সিস্টেম মডেলিংয়ের জন্য উত্সর্গীকৃত প্রকল্পগুলির একটি সম্পূর্ণ পরিসরের জন্মের অনুমতি দেয়, যা শীর্ষ-স্তরের প্রকল্পের অন্তর্ভুক্ত। Eclipse মডেলিং EMF নিজেই বরাবর. এরকম একটি প্রকল্প হল Eclipse Xtext।

Eclipse Xtext একটি "টেক্সট মডেলিং" পরিকাঠামো প্রদান করে। Xtext ব্যবহার করে এএনটিএলআর উৎস টেক্সট পার্স করার জন্য এবং ফলস্বরূপ ASG প্রতিনিধিত্ব করার জন্য EMF (বিমূর্ত শব্দার্থিক গ্রাফ, যা মূলত AST এবং বাইন্ডিংয়ের সংমিশ্রণ), যাকে "অর্থবোধক মডেল"ও বলা হয়। Xtext দ্বারা মডেল করা ভাষার ব্যাকরণ Xtext এর নিজস্ব ভাষায় বর্ণিত হয়েছে। এটি আপনাকে শুধুমাত্র ANTLR-এর জন্য একটি ব্যাকরণের বিবরণ তৈরি করতে দেয় না, তবে একটি AST সিরিয়ালাইজেশন মেকানিজম (অর্থাৎ Xtext একটি পার্সার এবং একটি আনপার্সার উভয়ই প্রদান করে), একটি প্রসঙ্গ ইঙ্গিত এবং অন্যান্য ভাষার উপাদানগুলির একটি সংখ্যাও পেতে দেয়। অন্যদিকে, Xtext-এ ব্যবহৃত ব্যাকরণের ভাষা ANTLR-এ ব্যবহৃত ব্যাকরণ ভাষার তুলনায় কম নমনীয়। অতএব, কখনও কখনও বাস্তবায়িত ভাষাটিকে Xtext-এ "বাঁকানো" প্রয়োজন হয়, যা সাধারণত কোনও সমস্যা হয় না যদি আমরা স্ক্র্যাচ থেকে বিকশিত কোনও ভাষা সম্পর্কে কথা বলি তবে এটি ইতিমধ্যে প্রতিষ্ঠিত সিনট্যাক্স সহ ভাষার জন্য অগ্রহণযোগ্য হতে পারে। তা সত্ত্বেও, Xtext বর্তমানে Eclipse-এর সবচেয়ে পরিপক্ক, বৈশিষ্ট্য সমৃদ্ধ এবং বহুমুখী টুল যা তাদের জন্য প্রোগ্রামিং ভাষা এবং ডেভেলপমেন্ট টুল তৈরি করতে পারে। বিশেষ করে, এটি দ্রুত প্রোটোটাইপিংয়ের জন্য একটি আদর্শ হাতিয়ার ডোমেইন-নির্দিষ্ট ভাষা (ডোমেন-নির্দিষ্ট ভাষা, DSL)। ANTLR এবং EMF-এর উপর ভিত্তি করে উপরে উল্লিখিত "ভাষা কোর" ছাড়াও, Xtext অনেকগুলি দরকারী উচ্চ-স্তরের উপাদান প্রদান করে, যার মধ্যে রয়েছে ইন্ডেক্সিং মেকানিজম, ইনক্রিমেন্টাল কনস্ট্রাকশন, একটি "স্মার্ট এডিটর" এবং আরও অনেক কিছু, কিন্তু হ্যান্ডেল ছেড়ে দেয়- ভিত্তিক ভাষা মডেল। ইএমএফের মতো, এক্সটেক্সট একটি পৃথক বইয়ের যোগ্য একটি বিষয়, এবং আমরা এখনই এর সমস্ত ক্ষমতা সম্পর্কে খুব কমই কথা বলতে পারি।

1C: এন্টারপ্রাইজ ডেভেলপমেন্ট টুল সক্রিয়ভাবে EMF নিজেই এবং অন্যান্য Eclipse মডেলিং প্রকল্প উভয়ই ব্যবহার করে। বিশেষ করে, এক্সটেক্সট হল এই ধরনের 1C: এন্টারপ্রাইজ ল্যাঙ্গুয়েজ যেমন বিল্ট-ইন প্রোগ্রামিং ল্যাঙ্গুয়েজ এবং ক্যোয়ারী ল্যাঙ্গুয়েজ এর জন্য ডেভেলপমেন্ট টুলের ভিত্তি। এই ডেভেলপমেন্ট টুলগুলির আরেকটি ভিত্তি হল Eclipse Handly প্রকল্প, যা আমরা আরও বিশদে আলোচনা করব (তালিকাভুক্ত Eclipse উপাদানগুলির মধ্যে, এটি এখনও কম পরিচিত)।

হাতে গ্রহন, Eclipse প্রযুক্তি শীর্ষ-স্তরের প্রকল্পের একটি সাবপ্রজেক্ট, 1 সালে 2014C দ্বারা Eclipse ফাউন্ডেশনে একটি প্রাথমিক কোড অবদানের ফলে আবির্ভূত হয়। তারপর থেকে, 1C প্রকল্পের উন্নয়নে সমর্থন অব্যাহত রেখেছে: হ্যান্ডলি কমিটররা কোম্পানির কর্মচারী। প্রকল্পটি ছোট, তবে এটি Eclipse-এ একটি অনন্য কুলুঙ্গি দখল করে: এর প্রধান লক্ষ্য হ্যান্ডেল-ভিত্তিক মডেলগুলির বিকাশকে সমর্থন করা।

হ্যান্ডেল-ভিত্তিক মডেলগুলির মৌলিক স্থাপত্য নীতিগুলি, যেমন হ্যান্ডেল/বডি ইডিয়ম, উদাহরণ হিসাবে রিসোর্স মডেল এবং জাভা মডেল ব্যবহার করে উপরে আলোচনা করা হয়েছে। এটি আরও উল্লেখ করেছে যে রিসোর্স মডেল এবং জাভা মডেল উভয়ই ইক্লিপস জাভা ডেভেলপমেন্ট টুলস (জেডিটি) এর জন্য গুরুত্বপূর্ণ ভিত্তি। এবং যেহেতু প্রায় সমস্ত *DT Eclipse প্রজেক্টের একটি আর্কিটেকচার JDT-এর মতোই আছে, তাই এটা বলা খুব বেশি অত্যুক্তি হবে না যে হ্যান্ডেল-ভিত্তিক মডেলগুলি অনেকগুলিকে অন্তর্নিহিত করে, যদি সমস্ত IDE Eclipse প্ল্যাটফর্মের উপরে তৈরি না হয়। উদাহরণস্বরূপ, Eclipse C/C++ ডেভেলপমেন্ট টুলিং (CDT) এর একটি হ্যান্ডেল-ভিত্তিক C/C++ মডেল রয়েছে যা CDT আর্কিটেকচারে একই ভূমিকা পালন করে যেমনটি জাভা মডেল JDT-তে করে।

হ্যান্ডলির আগে, Eclipse হ্যান্ডেল-ভিত্তিক ভাষার মডেল তৈরির জন্য বিশেষ লাইব্রেরি অফার করেনি। বর্তমানে বিদ্যমান মডেলগুলি মূলত জাভা মডেল কোড (ওরফে কপি/পেস্ট) সরাসরি অভিযোজিত করে তৈরি করা হয়েছিল, ক্ষেত্রে যেখানে এটি অনুমতি দেয় Eclipse পাবলিক লাইসেন্স (EPL)। (অবশ্যই, এটি সাধারণত Eclipse প্রকল্পগুলির জন্য একটি আইনি সমস্যা নয়, তবে বন্ধ উত্স পণ্যগুলির জন্য নয়।) এর অন্তর্নিহিত অগোছালোতা ছাড়াও, এই কৌশলটি সুপরিচিত সমস্যাগুলিকে প্রবর্তন করে: ত্রুটিগুলির সাথে খাপ খাইয়ে নেওয়ার মাধ্যমে প্রবর্তিত কোড ডুপ্লিকেশন, ইত্যাদি সবচেয়ে খারাপ বিষয় হল যে ফলস্বরূপ মডেলগুলি "নিজেদের মধ্যে জিনিস" থেকে যায় এবং একীকরণের সম্ভাবনার সদ্ব্যবহার করে না। কিন্তু হ্যান্ডেল-ভিত্তিক ভাষার মডেলগুলির জন্য সাধারণ ধারণা এবং প্রোটোকলগুলিকে বিচ্ছিন্ন করার ফলে তাদের সাথে কাজ করার জন্য পুনরায় ব্যবহারযোগ্য উপাদান তৈরি হতে পারে, যা ইএমএফের ক্ষেত্রে ঘটেছিল।

এটা নয় যে Eclipse এই বিষয়গুলো বুঝতে পারেনি। 2005 সালে ফিরে মার্টিন এশলিম্যান, CDT প্রোটোটাইপ বিকাশের অভিজ্ঞতার সারসংক্ষেপ, তর্ক করেছে হ্যান্ডেল-ভিত্তিক মডেল সহ ভাষার মডেলগুলির জন্য একটি সাধারণ অবকাঠামো তৈরি করার প্রয়োজন। কিন্তু, প্রায়শই ঘটে, উচ্চ অগ্রাধিকারমূলক কাজের কারণে, এই ধারণাগুলির বাস্তবায়ন কখনই এটির কাছাকাছি আসেনি। এদিকে, *DT কোডের ফ্যাক্টরাইজেশন এখনও Eclipse-এর অনুন্নত বিষয়গুলির মধ্যে একটি।

একটি নির্দিষ্ট অর্থে, হ্যান্ডলি প্রকল্পটি EMF-এর মতো প্রায় একই সমস্যাগুলি সমাধান করার জন্য ডিজাইন করা হয়েছে, তবে হ্যান্ডেল-ভিত্তিক মডেলগুলির জন্য এবং প্রাথমিকভাবে ভাষাগুলির জন্য (অর্থাৎ, কিছু প্রোগ্রামিং ভাষার কাঠামোর উপাদানগুলির প্রতিনিধিত্ব করে)। হ্যান্ডলি ডিজাইন করার সময় প্রধান লক্ষ্যগুলি নীচে তালিকাভুক্ত করা হয়েছে:

• বিষয় এলাকার প্রধান বিমূর্ততা সনাক্তকরণ.
• প্রচেষ্টা হ্রাস করা এবং কোড পুনঃব্যবহারের মাধ্যমে হ্যান্ডেল-ভিত্তিক ভাষা মডেল বাস্তবায়নের গুণমান উন্নত করা।
• ফলস্বরূপ মডেলগুলিতে একটি ইউনিফাইড মেটা-লেভেল API প্রদান করা, সাধারণ IDE উপাদানগুলি তৈরি করা সম্ভব করে যা ভাষা হ্যান্ডেল-ভিত্তিক মডেলগুলির সাথে কাজ করে।
• নমনীয়তা এবং মাপযোগ্যতা।
• Xtext এর সাথে একীকরণ (একটি পৃথক স্তরে)।

সাধারণ ধারণা এবং প্রোটোকল হাইলাইট করার জন্য, ভাষা হ্যান্ডেল-ভিত্তিক মডেলগুলির বিদ্যমান বাস্তবায়ন বিশ্লেষণ করা হয়েছিল। হ্যান্ডলি দ্বারা প্রদত্ত প্রধান ইন্টারফেস এবং মৌলিক বাস্তবায়ন চিত্রে দেখানো হয়েছে। 8.

ভাত। 8. সাধারণ ইন্টারফেস এবং হ্যান্ডলি উপাদানগুলির মৌলিক বাস্তবায়ন

IElement ইন্টারফেস একটি উপাদানের হ্যান্ডেল প্রতিনিধিত্ব করে এবং সমস্ত হ্যান্ডলি-ভিত্তিক মডেলের উপাদানগুলির জন্য সাধারণ। বিমূর্ত শ্রেণীর উপাদান সাধারণীকৃত হ্যান্ডেল/বডি মেকানিজম প্রয়োগ করে (চিত্র 9)।

ভাত। 9. IElement এবং জেনেরিক হ্যান্ডেল/বডি বাস্তবায়ন

উপরন্তু, হ্যান্ডলি মডেল উপাদানের পরিবর্তন সম্পর্কে অবহিত করার জন্য একটি সাধারণ প্রক্রিয়া প্রদান করে (চিত্র 10)। আপনি দেখতে পাচ্ছেন, এটি রিসোর্স মডেল এবং জাভা মডেলে প্রয়োগ করা বিজ্ঞপ্তি পদ্ধতির মতোই, এবং উপাদান পরিবর্তনের তথ্যের একীভূত উপস্থাপনা প্রদান করতে IElementDelta ব্যবহার করে।

ভাত। 10. সাধারণ ইন্টারফেস এবং হ্যান্ডলি নোটিফিকেশন মেকানিজমের মৌলিক বাস্তবায়ন

উপরে আলোচিত হ্যান্ডলি অংশটি (চিত্র 9 এবং 10) প্রায় যেকোনো হ্যান্ডেল-ভিত্তিক মডেলের প্রতিনিধিত্ব করতে ব্যবহার করা যেতে পারে। তৈরির জন্য ভাষাগত মডেলগুলিতে, প্রকল্পটি অতিরিক্ত কার্যকারিতা সরবরাহ করে - বিশেষত, সাধারণ ইন্টারফেস এবং উত্স পাঠ্য কাঠামোর উপাদানগুলির জন্য মৌলিক বাস্তবায়ন, তথাকথিত উৎস উপাদান (চিত্র 8)। ISourceFile ইন্টারফেস একটি উৎস ফাইলের প্রতিনিধিত্ব করে, এবং ISourceConstruct উৎস ফাইলের মধ্যে একটি উপাদান উপস্থাপন করে। বিমূর্ত ক্লাস সোর্সফাইল এবং সোর্স কনস্ট্রাক্ট সোর্স ফাইল এবং তাদের উপাদানগুলির সাথে কাজ করতে সহায়তা করার জন্য সাধারণ পদ্ধতি প্রয়োগ করে, উদাহরণস্বরূপ, টেক্সট বাফারগুলির সাথে কাজ করা, সোর্স টেক্সটের একটি উপাদানের স্থানাঙ্কের সাথে আবদ্ধ করা, একটি কার্যকরী কপি বাফারের বর্তমান বিষয়বস্তুর সাথে মডেলগুলির সমন্বয় করা। , ইত্যাদি এই প্রক্রিয়াগুলি বাস্তবায়ন করা সাধারণত একটি চ্যালেঞ্জ, এবং হ্যান্ডলি উচ্চ-মানের মৌলিক বাস্তবায়ন প্রদান করে হ্যান্ডেল-ভিত্তিক ভাষা মডেলগুলি বিকাশের প্রচেষ্টাকে উল্লেখযোগ্যভাবে হ্রাস করতে পারে।

উপরে তালিকাভুক্ত মূল প্রক্রিয়াগুলি ছাড়াও, হ্যান্ডলি টেক্সট বাফার এবং স্ন্যাপশটগুলির জন্য একটি পরিকাঠামো প্রদান করে, সোর্স কোড এডিটরগুলির সাথে একীকরণের জন্য সমর্থন (এক্সটেক্সট এডিটরের সাথে আউট-অফ-দ্য-বক্স ইন্টিগ্রেশন সহ), পাশাপাশি কিছু সাধারণ UI উপাদান যা সোর্স কোড এডিটরদের সাথে কাজ করুন। হ্যান্ডলি মডেল যেমন আউটলাইন ফ্রেমওয়ার্ক। এর ক্ষমতাগুলি ব্যাখ্যা করার জন্য, প্রকল্পটি হ্যান্ডলিতে জাভা মডেলের বাস্তবায়ন সহ বেশ কয়েকটি উদাহরণ প্রদান করে। (JDT-তে জাভা মডেলের সম্পূর্ণ বাস্তবায়নের তুলনায়, এই মডেলটি আরও স্পষ্টতার জন্য ইচ্ছাকৃতভাবে কিছুটা সরলীকৃত হয়েছে।)

যেমনটি আগে উল্লেখ করা হয়েছে, হ্যান্ডলির প্রাথমিক নকশা এবং পরবর্তী বিকাশের সময় একটি প্রধান ফোকাস ছিল মাপযোগ্যতা এবং নমনীয়তার উপর।

নীতিগতভাবে, হ্যান্ডেল-ভিত্তিক মডেলগুলি "নকশা অনুসারে" বেশ ভালভাবে স্কেল করে। উদাহরণস্বরূপ, হ্যান্ডেল/বডি ইডিয়ম আপনাকে একটি মডেলের দ্বারা ব্যবহৃত মেমরির পরিমাণ সীমিত করতে দেয়। কিন্তু সূক্ষ্মতা আছে. এইভাবে, পরিমাপযোগ্যতার জন্য হ্যান্ডলি পরীক্ষা করার সময়, নোটিফিকেশন মেকানিজম বাস্তবায়নে একটি সমস্যা আবিষ্কৃত হয়েছিল - যখন প্রচুর পরিমাণে উপাদান পরিবর্তন করা হয়েছিল, ডেল্টা তৈরি করতে অনেক বেশি সময় লেগেছিল। দেখা গেল যে একই সমস্যা জেডিটি জাভা মডেলে উপস্থিত ছিল, যেখান থেকে সংশ্লিষ্ট কোডটি একবার অভিযোজিত হয়েছিল। আমরা হ্যান্ডলিতে বাগটি ঠিক করেছি এবং JDT-এর জন্য একটি অনুরূপ প্যাচ প্রস্তুত করেছি, যা কৃতজ্ঞতার সাথে গৃহীত হয়েছিল। এটি শুধুমাত্র একটি উদাহরণ যেখানে বিদ্যমান মডেল বাস্তবায়নে হ্যান্ডলি প্রবর্তন সম্ভাব্যভাবে কার্যকর হতে পারে, কারণ এই ক্ষেত্রে এই ধরনের একটি বাগ শুধুমাত্র একটি জায়গায় ঠিক করা যেতে পারে।

বিদ্যমান মডেল বাস্তবায়নে হ্যান্ডলি বাস্তবায়নকে প্রযুক্তিগতভাবে সম্ভবপর করতে, লাইব্রেরিতে অবশ্যই উল্লেখযোগ্য নমনীয়তা থাকতে হবে। প্রধান সমস্যা হল API মডেল জুড়ে পশ্চাদপদ সামঞ্জস্য বজায় রাখা। এই সমস্যাটি সমাধান করা হয়েছিল হ্যান্ডলি 0.5 লাইব্রেরি দ্বারা প্রদত্ত ইউনিফাইড মেটা-লেভেল API থেকে ডেভেলপার দ্বারা সংজ্ঞায়িত এবং সম্পূর্ণরূপে নিয়ন্ত্রিত মডেল-নির্দিষ্ট API-কে স্পষ্টভাবে আলাদা করে। এটি কেবলমাত্র বিদ্যমান বাস্তবায়নে হ্যান্ডলি প্রয়োগ করা প্রযুক্তিগতভাবে সম্ভব করে না, তবে API ডিজাইন করার সময় নতুন মডেল বিকাশকারীকে উল্লেখযোগ্য স্বাধীনতা দেয়।

নমনীয়তার অন্যান্য দিকও রয়েছে। উদাহরণস্বরূপ, হ্যান্ডলি মডেলের কাঠামোর উপর প্রায় কোনও বিধিনিষেধ আরোপ করে না এবং সাধারণ-উদ্দেশ্য এবং ডোমেন-নির্দিষ্ট ভাষা উভয় মডেলের জন্য ব্যবহার করা যেতে পারে। সোর্স ফাইলের কাঠামো তৈরি করার সময়, Handly AST প্রতিনিধিত্বের কোনো নির্দিষ্ট রূপ নির্ধারণ করে না এবং নীতিগতভাবে, এমনকি AST-এর উপস্থিতিরও প্রয়োজন হয় না, এইভাবে প্রায় কোনো পার্সিং প্রক্রিয়ার সাথে সামঞ্জস্যতা নিশ্চিত করে। অবশেষে, হ্যান্ডলি ইক্লিপস ওয়ার্কস্পেসের সাথে সম্পূর্ণ ইন্টিগ্রেশন সমর্থন করে, তবে ফাইল সিস্টেমের সাথে এটির একীকরণের জন্য ধন্যবাদ সরাসরি কাজ করতে পারে। Eclipse ফাইল সিস্টেম (ইএফএস)।

বর্তমান সংস্করণ হ্যান্ডলি 0.6 ডিসেম্বর 2016 এ প্রকাশিত হয়েছিল। যদিও প্রকল্পটি বর্তমানে ইনকিউবেশন অবস্থায় রয়েছে এবং API এখনও চূড়ান্তভাবে ঠিক করা হয়নি, হ্যান্ডলি ইতিমধ্যে দুটি বড় বাণিজ্যিক পণ্যে ব্যবহৃত হয়েছে যেগুলি "প্রাথমিক গ্রহণকারী" হিসাবে কাজ করার ঝুঁকি নিয়েছিল, এবং, আমি অবশ্যই বলব, এখনও এটা অনুশোচনা করবেন না.

উপরে উল্লিখিত হিসাবে, এই পণ্যগুলির মধ্যে একটি হল 1C: এন্টারপ্রাইজ ডেভেলপমেন্ট টুলস, যেখানে হ্যান্ডলি প্রথম থেকেই ব্যবহার করা হয় এই ধরনের 1C: এন্টারপ্রাইজ ভাষাগুলি অন্তর্নির্মিত প্রোগ্রামিং ভাষা এবং কোয়েরি ভাষা হিসাবে উচ্চ-স্তরের কাঠামোর উপাদানগুলির মডেল করতে। . আরেকটি পণ্য সাধারণ মানুষের কাছে কম পরিচিত। এই কোডসিপ স্টুডিও, অ্যাপ্লিকেশন-নির্দিষ্ট নির্দেশ-সেট প্রসেসর (ASIP) এর জন্য একটি সমন্বিত নকশা পরিবেশ, চেক কোম্পানি কোডাসিপ এবং এর ক্লায়েন্টদের দ্বারা উভয়ই ব্যবহৃত হয়, যার মধ্যে রয়েছে এএমডি, গড়, মোবাইলয়ে, সিগমা ডিজাইনস. Codasip হ্যান্ডলি 2015 সংস্করণ দিয়ে শুরু করে 0.2 সাল থেকে উৎপাদনে হ্যান্ডলি ব্যবহার করছে। কোডাসিপ স্টুডিওর সর্বশেষ রিলিজটি 0.5 সংস্করণ ব্যবহার করে, জুন 2016 এ প্রকাশিত হয়েছে। Ondřej Ilčík, যিনি Codasip-এ IDE ডেভেলপমেন্টের নেতৃত্ব দেন, প্রকল্পের সাথে যোগাযোগ করছেন, "তৃতীয় পক্ষ গ্রহণকারী" এর পক্ষে গুরুত্বপূর্ণ প্রতিক্রিয়া প্রদান করছেন। এমনকি তিনি জাভা মডেলের হ্যান্ডলি উদাহরণগুলির একটির জন্য একটি UI স্তর (~4000 লাইন অফ কোড) প্রয়োগ করে প্রকল্পের উন্নয়নে সরাসরি অংশ নেওয়ার জন্য কিছু অবসর সময় খুঁজে পেতে সক্ষম হন। গ্রহণকারীদের দ্বারা হ্যান্ডলি ব্যবহার সম্পর্কে আরও বিস্তারিত প্রথম-হ্যান্ড তথ্য পৃষ্ঠায় পাওয়া যাবে সাফল্যের গল্প প্রকল্প

আমরা আশা করি যে API স্থিতিশীলতার গ্যারান্টি সহ সংস্করণ 1.0 প্রকাশের পরে এবং প্রকল্পটি ইনকিউবেশন অবস্থা থেকে বেরিয়ে যাওয়ার পরে, Handly-এর নতুন গ্রহণকারী থাকবে। ইতিমধ্যে, প্রকল্পটি API-কে পরীক্ষা এবং আরও উন্নত করে চলেছে, প্রতি বছর দুটি "প্রধান" রিলিজ প্রকাশ করছে - জুনে (একযোগে Eclipse প্রকাশের একই তারিখ) এবং ডিসেম্বরে, একটি অনুমানযোগ্য সময়সূচী প্রদান করে যা গ্রহণকারীরা নির্ভর করতে পারে। আমরা এটিও যোগ করতে পারি যে প্রকল্পের "বাগ রেট" ধারাবাহিকভাবে নিম্ন স্তরে রয়েছে এবং হ্যান্ডলি প্রথম সংস্করণ থেকেই প্রাথমিক গ্রহণকারীদের পণ্যগুলিতে নির্ভরযোগ্যভাবে কাজ করছে। আরও এক্সপ্লোর করতে Eclipse Handly, আপনি ব্যবহার করতে পারেন শুরু করা টিউটোরিয়াল и স্থাপত্য ওভারভিউ.

উত্স: www.habr.com