Eclipse ເປັນແພລະຕະຟອມເຕັກໂນໂລຢີສໍາລັບ 1C: ເຄື່ອງມືພັດທະນາວິສາຫະກິດ

ບາງທີ, ອຸປະລາຄາ ດົນນານແລ້ວ, ບໍ່ຈໍາເປັນຕ້ອງມີການແນະນໍາພິເສດ. ຫຼາຍຄົນຄຸ້ນເຄີຍກັບ Eclipse ຍ້ອນເຄື່ອງມືພັດທະນາ Eclipse Java (JDT). ມັນແມ່ນ Java IDE open-source ທີ່ນິຍົມທີ່ນັກພັດທະນາສ່ວນໃຫຍ່ເຊື່ອມໂຍງກັບ ຄຳ ວ່າ "Eclipse". ຢ່າງໃດກໍຕາມ, Eclipse ເປັນທັງສອງແພລະຕະຟອມທີ່ສາມາດຂະຫຍາຍໄດ້ສໍາລັບການລວມເອົາເຄື່ອງມືການພັດທະນາ (Eclipse Platform), ແລະຈໍານວນຂອງ IDE ທີ່ສ້າງຂຶ້ນບົນພື້ນຖານຂອງມັນ, ລວມທັງ JDT. Eclipse ແມ່ນທັງໂຄງການ Eclipse, ໂຄງການລະດັບສູງສຸດທີ່ປະສານງານການພັດທະນາ Eclipse Platform ແລະ JDT, ແລະ Eclipse SDK, ຜົນໄດ້ຮັບຂອງການພັດທະນານັ້ນ. ສຸດທ້າຍ, Eclipse ແມ່ນພື້ນຖານແຫຼ່ງເປີດທີ່ມີຊຸມຊົນຂະຫນາດໃຫຍ່ຂອງໂຄງການ, ບໍ່ແມ່ນທັງຫມົດທີ່ຖືກຂຽນໃນ Java ຫຼືກ່ຽວຂ້ອງກັບເຄື່ອງມືພັດທະນາ (ຕົວຢ່າງ, ໂຄງການ. Eclipse IoT и ວິທະຍາສາດ Eclipse). ໂລກຂອງ Eclipse ແມ່ນມີຄວາມຫຼາກຫຼາຍຫຼາຍ.

ໃນບົດຄວາມນີ້, ເຊິ່ງເປັນພາບລວມໃນທໍາມະຊາດ, ພວກເຮົາຈະພະຍາຍາມເບິ່ງບາງພື້ນຖານຂອງສະຖາປັດຕະຍະກໍາ Eclipse ເປັນເວທີສໍາລັບການກໍ່ສ້າງເຄື່ອງມືການພັດທະນາປະສົມປະສານແລະໃຫ້ຄວາມຄິດເບື້ອງຕົ້ນຂອງອົງປະກອບ Eclipse ທີ່ເປັນພື້ນຖານຂອງເຕັກໂນໂລຢີ. ເວທີສໍາລັບ "Configurator ໃຫມ່" 1C: Enterprise. 1C: ເຄື່ອງມືພັດທະນາວິສາຫະກິດ. ແນ່ນອນ, ການທົບທວນຄືນດັ່ງກ່າວຈະຫຼີກລ່ຽງບໍ່ໄດ້ເປັນສ່ວນໃຫຍ່ superficial ແລະຂ້ອນຂ້າງຈໍາກັດ, ລວມທັງຍ້ອນວ່າພວກເຮົາກໍາລັງສຸມໃສ່ບໍ່ພຽງແຕ່ກ່ຽວກັບນັກພັດທະນາ Eclipse ເປັນຜູ້ຊົມເປົ້າຫມາຍ. ຢ່າງໃດກໍຕາມ, ພວກເຮົາຫວັງວ່າເຖິງແມ່ນວ່ານັກພັດທະນາ Eclipse ມີປະສົບການຈະສາມາດຊອກຫາຂໍ້ມູນທີ່ຫນ້າສົນໃຈໃນບົດຄວາມ. ຕົວຢ່າງ, ພວກເຮົາຈະເວົ້າກ່ຽວກັບຫນຶ່ງໃນ "ຄວາມລັບຂອງ Eclipse", ໂຄງການທີ່ຂ້ອນຂ້າງໃຫມ່ແລະບໍ່ຄ່ອຍຮູ້ຈັກ. Eclipse Handly, ເຊິ່ງກໍ່ຕັ້ງແລະສະຫນັບສະຫນູນໂດຍ 1C.

ແນະນຳກ່ຽວກັບສະຖາປັດຕະຍະກຳ Eclipse

ທໍາອິດໃຫ້ເບິ່ງບາງລັກສະນະທົ່ວໄປຂອງສະຖາປັດຕະ Eclipse ໂດຍໃຊ້ຕົວຢ່າງ ເຄື່ອງມືພັດທະນາ Eclipse Java (JDT). ທາງເລືອກຂອງ JDT ເປັນຕົວຢ່າງບໍ່ແມ່ນອຸບັດຕິເຫດ. ນີ້ແມ່ນສະພາບແວດລ້ອມການພັດທະນາແບບປະສົມປະສານຄັ້ງທໍາອິດທີ່ຈະປາກົດຢູ່ໃນ Eclipse. ໂຄງການ *DT Eclipse ອື່ນໆ, ເຊັ່ນ Eclipse C/C++ Development Tooling (CDT), ໄດ້ຖືກສ້າງຂື້ນຕໍ່ມາແລະຢືມທັງສອງຫຼັກການພື້ນຖານສະຖາປັດຕະຍະກໍາແລະຊິ້ນສ່ວນລະຫັດແຫຼ່ງສ່ວນບຸກຄົນຈາກ JDT. ພື້ນຖານຂອງສະຖາປັດຕະຍະກໍາທີ່ວາງໄວ້ໃນ JDT ແມ່ນກ່ຽວຂ້ອງກັບທຸກມື້ນີ້ສໍາລັບເກືອບທຸກ IDE ທີ່ສ້າງຂຶ້ນຢູ່ເທິງສຸດຂອງ Eclipse Platform, ລວມທັງ 1C: ເຄື່ອງມືພັດທະນາວິສາຫະກິດ.

ກ່ອນອື່ນ ໝົດ, ມັນຄວນຈະສັງເກດວ່າ Eclipse ມີລັກສະນະເປັນຊັ້ນສະຖາປັດຕະຍະ ກຳ ທີ່ຈະແຈ້ງ, ດ້ວຍການແບ່ງສ່ວນການເຮັດວຽກທີ່ເປັນເອກະລາດຂອງພາສາຈາກການເຮັດວຽກທີ່ຖືກອອກແບບມາເພື່ອຮອງຮັບພາສາການຂຽນໂປຼແກຼມສະເພາະ, ແລະການແຍກສ່ວນປະກອບ "ຫຼັກ" ທີ່ບໍ່ຂຶ້ນກັບ UI ຈາກອົງປະກອບທີ່ກ່ຽວຂ້ອງ. ມີການໂຕ້ຕອບຜູ້ໃຊ້ສະຫນັບສະຫນູນ.

ດັ່ງນັ້ນ, ເວທີ Eclipse ກໍານົດພື້ນຖານໂຄງລ່າງທົ່ວໄປ, ພາສາທີ່ເປັນເອກະລາດ, ແລະເຄື່ອງມືພັດທະນາ Java ເພີ່ມ Java IDE ເຕັມຮູບແບບໃຫ້ກັບ Eclipse. ທັງ Eclipse Platform ແລະ JDT ປະກອບດ້ວຍຫຼາຍອົງປະກອບ, ແຕ່ລະອັນເປັນຂອງ "ຫຼັກ" ຫຼືຊັ້ນ UI ທີ່ບໍ່ຂຶ້ນກັບ UI (ຮູບ 1).

ເຂົ້າ. 1. ເວທີ Eclipse ແລະ JDT

ໃຫ້ບອກອົງປະກອບຕົ້ນຕໍຂອງ Eclipse Platform:

• ເວລາແລ່ນ — ກໍານົດໂຄງສ້າງພື້ນຖານຂອງ plugin. Eclipse ມີລັກສະນະເປັນສະຖາປັດຕະຍະກໍາ modular. ໂດຍພື້ນຖານແລ້ວ, Eclipse ແມ່ນການລວບລວມ "ຈຸດຂະຫຍາຍ" ແລະ "ສ່ວນຂະຫຍາຍ".
• ພື້ນທີ່ເຮັດວຽກ - ການ​ຄຸ້ມ​ຄອງ​ຫນຶ່ງ​ຫຼື​ຫຼາຍ​ໂຄງ​ການ​. ໂຄງ​ການ​ປະ​ກອບ​ດ້ວຍ​ແຟ້ມ​ແລະ​ໄຟລ​໌​ທີ່​ມີ​ແຜນ​ທີ່​ໂດຍ​ກົງ​ກັບ​ລະ​ບົບ​ໄຟລ​໌​.
• Standard Widget Toolkit (SWT) - ສະຫນອງອົງປະກອບການໂຕ້ຕອບຜູ້ໃຊ້ພື້ນຖານປະສົມປະສານກັບລະບົບປະຕິບັດການ.
• JFace — ສະຫນອງກອບ UI ຈໍານວນຫນຶ່ງທີ່ສ້າງຂຶ້ນຢູ່ເທິງສຸດຂອງ SWT.
• Workbench — ກໍານົດ Eclipse UI paradigm: ບັນນາທິການ, ທັດສະນະ, ທັດສະນະ.

ມັນຕ້ອງເວົ້າວ່າ Eclipse Platform ຍັງສະຫນອງອົງປະກອບທີ່ເປັນປະໂຫຍດອື່ນໆຫຼາຍສໍາລັບການກໍ່ສ້າງເຄື່ອງມືພັດທະນາປະສົມປະສານ, ລວມທັງ Debug, Compare, Search, ແລະທີມງານ. ການກ່າວເຖິງພິເສດຄວນຈະເປັນ JFace Text - ພື້ນຖານສໍາລັບການກໍ່ສ້າງ "ບັນນາທິການທີ່ສະຫລາດ" ຂອງລະຫັດແຫຼ່ງ. ແຕ່ຫນ້າເສຍດາຍ, ເຖິງແມ່ນວ່າການກວດສອບ cursory ຂອງອົງປະກອບເຫຼົ່ານີ້, ເຊັ່ນດຽວກັນກັບອົງປະກອບຂອງຊັ້ນ UI, ແມ່ນບໍ່ເປັນໄປໄດ້ໃນຂອບເຂດຂອງບົດຄວາມນີ້, ດັ່ງນັ້ນໃນສ່ວນທີ່ເຫຼືອຂອງພາກນີ້, ພວກເຮົາຈະຈໍາກັດຕົວເຮົາເອງກັບພາບລວມຂອງອົງປະກອບ "ຫຼັກ" ຕົ້ນຕໍຂອງ. ເວທີ Eclipse ແລະ JDT.

ເວລາແລ່ນຫຼັກ

ໂຄງລ່າງພື້ນຖານຂອງ plugin Eclipse ແມ່ນອີງໃສ່ OSGi ແລະສະຫນອງໃຫ້ໂດຍໂຄງການ Equinox Eclipse. ແຕ່ລະ plugin Eclipse ແມ່ນຊຸດ OSGi. ຂໍ້ກໍານົດ OSGi ກໍານົດ, ໂດຍສະເພາະ, ກົນໄກສໍາລັບການສະບັບແລະການແກ້ໄຂການຂຶ້ນກັບ. ນອກເຫນືອໄປຈາກກົນໄກມາດຕະຖານເຫຼົ່ານີ້, Equinox ແນະນໍາແນວຄວາມຄິດ ຈຸດຂະຫຍາຍ. ແຕ່ລະ plugin ສາມາດກໍານົດຈຸດຂະຫຍາຍຂອງຕົນເອງ, ແລະຍັງແນະນໍາການເຮັດວຽກເພີ່ມເຕີມ ("ສ່ວນຂະຫຍາຍ") ໃຫ້ກັບລະບົບໂດຍໃຊ້ຈຸດຂະຫຍາຍທີ່ກໍານົດໂດຍ plugins ດຽວກັນຫຼືອື່ນໆ. ລາຍລະອຽດໃດໆກ່ຽວກັບກົນໄກ OSGi ແລະ Equinox ແມ່ນເກີນຂອບເຂດຂອງບົດຄວາມນີ້. ໃຫ້ພວກເຮົາພຽງແຕ່ສັງເກດວ່າ modularization ໃນ Eclipse ແມ່ນທັງຫມົດ (ລະບົບຍ່ອຍໃດກໍ່ຕາມ, ລວມທັງ Runtime, ປະກອບດ້ວຍຫນຶ່ງຫຼືຫຼາຍກວ່າ plugins), ແລະເກືອບທຸກສິ່ງທຸກຢ່າງໃນ Eclipse ແມ່ນການຂະຫຍາຍ. ຍິ່ງໄປກວ່ານັ້ນ, ຫຼັກການເຫຼົ່ານີ້ໄດ້ຖືກຝັງຢູ່ໃນສະຖາປັດຕະ Eclipse ດົນນານກ່ອນທີ່ຈະນໍາສະເຫນີ OSGi (ໃນເວລານັ້ນພວກເຂົາໃຊ້ເຕັກໂນໂລຢີຂອງຕົນເອງ, ຄ້າຍຄືກັນກັບ OSGi).

ພື້ນທີ່ເຮັດວຽກຫຼັກ

ເກືອບທຸກສະພາບແວດລ້ອມການພັດທະນາແບບປະສົມປະສານທີ່ສ້າງຂຶ້ນຢູ່ເທິງສຸດຂອງເວທີ Eclipse ເຮັດວຽກກັບພື້ນທີ່ເຮັດວຽກ Eclipse. ມັນເປັນພື້ນທີ່ເຮັດວຽກທີ່ປົກກະຕິແລ້ວມີລະຫັດແຫຼ່ງຂອງແອັບພລິເຄຊັນທີ່ພັດທະນາຢູ່ໃນ IDE. ແຜນທີ່ບ່ອນເຮັດວຽກໂດຍກົງກັບລະບົບໄຟລ໌ແລະປະກອບດ້ວຍໂຄງການ, ເຊິ່ງປະກອບດ້ວຍໂຟນເດີແລະໄຟລ໌. ໂຄງການເຫຼົ່ານີ້, ໂຟນເດີ, ແລະໄຟລ໌ແມ່ນເອີ້ນວ່າ ຊັບ​ພະ​ຍາ​ກອນ ພື້ນທີ່ເຮັດວຽກ. ການປະຕິບັດພື້ນທີ່ເຮັດວຽກໃນ Eclipse ເຮັດຫນ້າທີ່ເປັນຖານຄວາມຈໍາທີ່ກ່ຽວຂ້ອງກັບລະບົບໄຟລ໌, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະເລັ່ງການຂ້າມຜ່ານຂອງຕົ້ນໄມ້ຊັບພະຍາກອນຢ່າງຫຼວງຫຼາຍ. ນອກຈາກນັ້ນ, ພື້ນທີ່ເຮັດວຽກສະຫນອງການບໍລິການເພີ່ມເຕີມຈໍານວນຫນຶ່ງ, ລວມທັງ ກົນໄກການແຈ້ງເຕືອນສໍາລັບການປ່ຽນແປງຊັບພະຍາກອນ и ໂຄງສ້າງພື້ນຖານຂອງຜູ້ສ້າງທີ່ເພີ່ມຂຶ້ນ.

ອົງປະກອບຂອງຊັບພະຍາກອນຫຼັກ (org.eclipse.core.resources plugin) ແມ່ນຮັບຜິດຊອບສໍາລັບການສະຫນັບສະຫນູນພື້ນທີ່ເຮັດວຽກແລະຊັບພະຍາກອນຂອງມັນ. ໂດຍສະເພາະ, ອົງປະກອບນີ້ສະຫນອງການເຂົ້າເຖິງໂຄງການກັບພື້ນທີ່ເຮັດວຽກໃນຮູບແບບ ຮູບແບບຊັບພະຍາກອນ. ເພື່ອເຮັດວຽກຢ່າງມີປະສິດທິພາບກັບຮູບແບບນີ້, ລູກຄ້າຕ້ອງການວິທີທີ່ງ່າຍດາຍທີ່ຈະນໍາສະເຫນີການເຊື່ອມຕໍ່ກັບຊັບພະຍາກອນ. ໃນກໍລະນີນີ້, ມັນຄວນຈະເປັນຄວາມປາຖະຫນາທີ່ຈະຊ່ອນວັດຖຸທີ່ເກັບຮັກສາສະຖານະການຂອງຊັບພະຍາກອນໂດຍກົງໃນຕົວແບບຈາກການເຂົ້າເຖິງຂອງລູກຄ້າ. ຖ້າບໍ່ດັ່ງນັ້ນ, ສໍາລັບຕົວຢ່າງ, ການລຶບໄຟລ໌, ລູກຄ້າສາມາດສືບຕໍ່ຖືວັດຖຸທີ່ບໍ່ມີຢູ່ໃນຕົວແບບ, ມີບັນຫາຕໍ່ໄປ. Eclipse ແກ້ໄຂບັນຫານີ້ໂດຍໃຊ້ບາງສິ່ງບາງຢ່າງທີ່ເອີ້ນວ່າ ຈັບໄດ້ ຊັບພະຍາກອນ. Handle ເຮັດຫນ້າທີ່ເປັນກຸນແຈ (ມັນພຽງແຕ່ຮູ້ເສັ້ນທາງໄປຫາຊັບພະຍາກອນໃນພື້ນທີ່ເຮັດວຽກ) ແລະຄວບຄຸມການເຂົ້າເຖິງວັດຖຸຕົວແບບພາຍໃນຢ່າງສົມບູນ, ເຊິ່ງເກັບຮັກສາຂໍ້ມູນກ່ຽວກັບສະຖານະຂອງຊັບພະຍາກອນໂດຍກົງ. ການອອກແບບນີ້ແມ່ນການປ່ຽນແປງຂອງຮູບແບບ ມືຈັບ / ຮ່າງກາຍ.

ເຂົ້າ. ຮູບທີ 2 ສະແດງຕົວຢ່າງຂອງ Handle/Body idiom ທີ່ນຳໃຊ້ກັບຮູບແບບຊັບພະຍາກອນ. ອິນເຕີເຟດ IResource ເປັນຕົວແທນຂອງການຈັດການຊັບພະຍາກອນແລະເປັນ API, ບໍ່ເຫມືອນກັບຊັ້ນຊັບພະຍາກອນ, ເຊິ່ງປະຕິບັດການໂຕ້ຕອບນີ້, ແລະຊັ້ນຊັບພະຍາກອນ, ເຊິ່ງເປັນຕົວແທນຂອງຮ່າງກາຍ, ເຊິ່ງບໍ່ແມ່ນ APIs. ພວກເຮົາເນັ້ນຫນັກວ່າ handle ພຽງແຕ່ຮູ້ເສັ້ນທາງໄປຫາຊັບພະຍາກອນທີ່ກ່ຽວຂ້ອງກັບຮາກບ່ອນເຮັດວຽກແລະບໍ່ມີການເຊື່ອມຕໍ່ກັບຂໍ້ມູນຊັບພະຍາກອນ. ວັດຖຸຂໍ້ມູນຊັບພະຍາກອນປະກອບເປັນອັນທີ່ເອີ້ນວ່າ "ຕົ້ນໄມ້ອົງປະກອບ". ໂຄງສ້າງຂໍ້ມູນນີ້ຖືກສ້າງຂື້ນຢ່າງສົມບູນໃນຫນ່ວຍຄວາມຈໍາ. ເພື່ອຊອກຫາຕົວຢ່າງຂໍ້ມູນຊັບພະຍາກອນທີ່ສອດຄ້ອງກັບຕົວຈັບ, ຕົ້ນໄມ້ອົງປະກອບແມ່ນຜ່ານໄປຕາມເສັ້ນທາງທີ່ເກັບໄວ້ໃນຕົວຈັບນັ້ນ.

ເຂົ້າ. 2. IResource ແລະ ResourceInfo

ດັ່ງທີ່ພວກເຮົາຈະເຫັນຕໍ່ມາ, ການອອກແບບພື້ນຖານຂອງແບບຈໍາລອງຊັບພະຍາກອນ (ພວກເຮົາອາດຈະເອີ້ນວ່າມັນ handle-based) ແມ່ນໃຊ້ໃນ Eclipse ສໍາລັບຮູບແບບອື່ນໆເຊັ່ນກັນ. ສໍາລັບໃນປັດຈຸບັນ, ໃຫ້ບອກບາງຄຸນສົມບັດທີ່ໂດດເດັ່ນຂອງການອອກແບບນີ້:

• Handle ແມ່ນວັດຖຸມູນຄ່າ. ວັດຖຸມູນຄ່າແມ່ນວັດຖຸທີ່ບໍ່ປ່ຽນແປງໄດ້ ທີ່ມີຄວາມສະເໝີພາບບໍ່ໄດ້ອີງໃສ່ຕົວຕົນ. ວັດຖຸດັ່ງກ່າວສາມາດຖືກນໍາໃຊ້ຢ່າງປອດໄພເປັນກະແຈໃນພາຊະນະ hashed. ຫຼາຍຕົວຢ່າງຂອງຕົວຈັດການສາມາດອ້າງອີງຊັບພະຍາກອນດຽວກັນ. ເພື່ອປຽບທຽບພວກມັນ, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ວິທີການເທົ່າກັບ (ວັດຖຸ).
• Handle ກໍານົດພຶດຕິກໍາຂອງຊັບພະຍາກອນ, ແຕ່ບໍ່ມີຂໍ້ມູນກ່ຽວກັບສະຖານະຂອງຊັບພະຍາກອນ (ຂໍ້ມູນດຽວທີ່ມັນເກັບຮັກສາແມ່ນ "ກຸນແຈ", ເສັ້ນທາງໄປຫາຊັບພະຍາກອນ).
• Handle ອາດຈະຫມາຍເຖິງຊັບພະຍາກອນທີ່ບໍ່ມີຢູ່ (ທັງຊັບພະຍາກອນທີ່ຍັງບໍ່ທັນໄດ້ຖືກສ້າງຂຶ້ນ, ຫຼືຊັບພະຍາກອນທີ່ຖືກລຶບຖິ້ມແລ້ວ). ການມີຢູ່ຂອງຊັບພະຍາກອນສາມາດກວດສອບໄດ້ໂດຍໃຊ້ວິທີ IResource.exists().
• ການປະຕິບັດງານບາງຢ່າງສາມາດປະຕິບັດໄດ້ໂດຍອີງໃສ່ຂໍ້ມູນທີ່ເກັບໄວ້ໃນຕົວຈັບເທົ່ານັ້ນ (ອັນທີ່ເອີ້ນວ່າການດໍາເນີນງານທີ່ຈັບພຽງແຕ່). ຕົວຢ່າງເຊັ່ນ IRResource.getParent(), getFullPath(), ແລະອື່ນໆ. ຊັບພະຍາກອນບໍ່ຈໍາເປັນຕ້ອງມີເພື່ອໃຫ້ການດໍາເນີນງານດັ່ງກ່າວປະສົບຜົນສໍາເລັດ. ການປະຕິບັດງານທີ່ຕ້ອງການຊັບພະຍາກອນທີ່ມີຢູ່ເພື່ອປະສົບຜົນສໍາເລັດຖິ້ມ CoreException ຖ້າຊັບພະຍາກອນບໍ່ມີ.

Eclipse ສະຫນອງກົນໄກທີ່ມີປະສິດທິພາບສໍາລັບການແຈ້ງການປ່ຽນແປງຊັບພະຍາກອນຂອງພື້ນທີ່ເຮັດວຽກ (ຮູບ 3). ຊັບພະຍາກອນສາມາດປ່ຽນແປງເປັນຜົນມາຈາກການດໍາເນີນການພາຍໃນ Eclipse IDE ຕົວຂອງມັນເອງຫຼືເປັນຜົນມາຈາກ synchronization ກັບລະບົບໄຟລ໌. ໃນທັງສອງກໍລະນີ, ລູກຄ້າທີ່ຈອງການແຈ້ງເຕືອນແມ່ນໃຫ້ຂໍ້ມູນລະອຽດກ່ຽວກັບການປ່ຽນແປງໃນຮູບແບບຂອງ "deltas ຊັບພະຍາກອນ". A delta ອະທິບາຍການປ່ຽນແປງລະຫວ່າງສອງສະຖານະຂອງຊັບພະຍາກອນພື້ນທີ່ເຮັດວຽກ (sub-) ແລະຕົວຂອງມັນເອງເປັນຕົ້ນໄມ້, ແຕ່ລະ node ຂອງທີ່ອະທິບາຍການປ່ຽນແປງຂອງຊັບພະຍາກອນແລະປະກອບດ້ວຍບັນຊີລາຍຊື່ຂອງ deltas ໃນລະດັບຕໍ່ໄປທີ່ອະທິບາຍການປ່ຽນແປງຂອງຊັບພະຍາກອນເດັກນ້ອຍ.

ເຂົ້າ. 3. IResourceChangeEvent ແລະ IResourceDelta

ກົນໄກການແຈ້ງເຕືອນໂດຍອີງໃສ່ deltas ຊັບພະຍາກອນມີລັກສະນະດັ່ງຕໍ່ໄປນີ້:

• ການປ່ຽນແປງດຽວແລະການປ່ຽນແປງຫຼາຍແມ່ນໄດ້ຖືກອະທິບາຍໂດຍໃຊ້ໂຄງສ້າງດຽວກັນ, ນັບຕັ້ງແຕ່ delta ຖືກສ້າງຂຶ້ນໂດຍໃຊ້ຫຼັກການຂອງອົງປະກອບ recursive. ລູກຄ້າຜູ້ຈອງສາມາດປະມວນຜົນການແຈ້ງເຕືອນການປ່ຽນແປງຊັບພະຍາກອນໂດຍໃຊ້ descent recursive ຜ່ານຕົ້ນໄມ້ຂອງ deltas.
• delta ມີຂໍ້ມູນຄົບຖ້ວນສົມບູນກ່ຽວກັບການປ່ຽນແປງຂອງຊັບພະຍາກອນ, ລວມທັງການເຄື່ອນໄຫວຂອງມັນແລະ / ຫຼືການປ່ຽນແປງໃນ "ເຄື່ອງຫມາຍ" ທີ່ກ່ຽວຂ້ອງກັບມັນ (ຕົວຢ່າງ, ຄວາມຜິດພາດການລວບລວມແມ່ນສະແດງເປັນເຄື່ອງຫມາຍ).
• ນັບຕັ້ງແຕ່ການອ້າງອິງຊັບພະຍາກອນແມ່ນເຮັດຜ່ານມືຈັບ, delta ສາມາດອ້າງອີງເຖິງຊັບພະຍາກອນຫ່າງໄກສອກຫຼີກຕາມທໍາມະຊາດ.

ດັ່ງທີ່ພວກເຮົາຈະເຫັນໃນໄວໆນີ້, ອົງປະກອບຕົ້ນຕໍຂອງການອອກແບບກົນໄກການແຈ້ງການການປ່ຽນແປງແບບຈໍາລອງຊັບພະຍາກອນແມ່ນມີຄວາມກ່ຽວຂ້ອງສໍາລັບຕົວແບບທີ່ອີງໃສ່ການຈັດການອື່ນໆ.

JDT Core

ຮູບແບບຊັບພະຍາກອນບ່ອນເຮັດວຽກ Eclipse ແມ່ນຮູບແບບພື້ນຖານຂອງພາສາທີ່ບໍ່ເຊື່ອຟັງ. ອົງປະກອບ JDT Core (plugin org.eclipse.jdt.core) ສະຫນອງ API ສໍາລັບການນໍາທາງແລະການວິເຄາະໂຄງສ້າງພື້ນທີ່ເຮັດວຽກຈາກມຸມເບິ່ງຂອງ Java, ອັນທີ່ເອີ້ນວ່າ "Java model" (ຮູບແບບ Java). API ນີ້ຖືກກໍານົດໃນເງື່ອນໄຂຂອງອົງປະກອບ Java, ກົງກັນຂ້າມກັບ API ຮູບແບບຊັບພະຍາກອນທີ່ຕິດພັນ, ເຊິ່ງຖືກກໍານົດໃນແງ່ຂອງໂຟນເດີແລະໄຟລ໌. ການໂຕ້ຕອບຕົ້ນຕໍຂອງອົງປະກອບ Java ແມ່ນສະແດງຢູ່ໃນຮູບ. 4.

ເຂົ້າ. 4. Java Model Elements

ຮູບແບບ Java ໃຊ້ຕົວຈັບ/ຕົວໜັງສືດຽວກັນກັບຕົວແບບຊັບພະຍາກອນ (ຮູບ 5). IJavaElement ແມ່ນຕົວຈັບ, ແລະ JavaElementInfo ມີບົດບາດຂອງຮ່າງກາຍ. ການໂຕ້ຕອບ IJavaElement ກໍານົດໂປໂຕຄອນທົ່ວໄປກັບອົງປະກອບ Java ທັງຫມົດ. ບາງວິທີຂອງມັນແມ່ນການຈັດການເທົ່ານັ້ນ: getElementName(), getParent(), ແລະອື່ນໆ. ວັດຖຸ JavaElementInfo ເກັບສະຖານະຂອງອົງປະກອບທີ່ສອດຄ້ອງກັນ: ໂຄງສ້າງແລະຄຸນລັກສະນະຂອງມັນ.

ເຂົ້າ. 5. IJavaElement ແລະ JavaElementInfo

ຮູບແບບ Java ມີຄວາມແຕກຕ່າງບາງຢ່າງໃນການປະຕິບັດການອອກແບບຕົວຈັບພື້ນຖານ / ຮ່າງກາຍທຽບກັບຮູບແບບຊັບພະຍາກອນ. ດັ່ງທີ່ໄດ້ກ່າວໄວ້ຂ້າງເທິງ, ໃນຮູບແບບຊັບພະຍາກອນ, ຕົ້ນໄມ້ອົງປະກອບ, ທີ່ມີ nodes ເປັນວັດຖຸຂໍ້ມູນຊັບພະຍາກອນ, ແມ່ນບັນຈຸຢູ່ໃນຫນ່ວຍຄວາມຈໍາທັງຫມົດ. ແຕ່ແບບຈໍາລອງ Java ສາມາດມີຈໍານວນຂະຫນາດໃຫຍ່ຂອງອົງປະກອບຫຼາຍກ່ວາຕົ້ນໄມ້ຊັບພະຍາກອນ, ເນື່ອງຈາກວ່າມັນຍັງເປັນຕົວແທນຂອງໂຄງສ້າງພາຍໃນຂອງໄຟລ໌ .java ແລະ .class: ປະເພດ, ທົ່ງນາ, ແລະວິທີການ.

ເພື່ອຫຼີກເວັ້ນການສ້າງຕົ້ນໄມ້ທັງຫມົດຂອງອົງປະກອບໃນຫນ່ວຍຄວາມຈໍາຢ່າງສົມບູນ, ການປະຕິບັດແບບຈໍາລອງ Java ໃຊ້ຂະຫນາດຈໍາກັດ LRU cache ຂອງຂໍ້ມູນອົງປະກອບ, ບ່ອນທີ່ສໍາຄັນແມ່ນຈັດການ IJavaElement. ຂໍ້ມູນອົງປະກອບວັດຖຸຖືກສ້າງຂື້ນຕາມຄວາມຕ້ອງການຍ້ອນວ່າຕົ້ນໄມ້ອົງປະກອບຖືກນໍາທາງ. ໃນກໍລະນີນີ້, ລາຍການທີ່ໃຊ້ຫນ້ອຍທີ່ສຸດຖືກຂັບໄລ່ອອກຈາກແຄດ, ແລະການບໍລິໂພກຫນ່ວຍຄວາມຈໍາຂອງຕົວແບບຍັງຄົງຈໍາກັດກັບຂະຫນາດແຄດທີ່ກໍານົດໄວ້. ນີ້ແມ່ນປະໂຫຍດອີກຢ່າງຫນຶ່ງຂອງການອອກແບບທີ່ອີງໃສ່ມື, ເຊິ່ງປິດບັງລາຍລະອຽດການປະຕິບັດດັ່ງກ່າວຢ່າງສົມບູນຈາກລະຫັດລູກຄ້າ.

ກົນໄກການແຈ້ງການປ່ຽນແປງຂອງອົງປະກອບ Java ໂດຍທົ່ວໄປແມ່ນຄ້າຍຄືກັນກັບກົນໄກການຕິດຕາມການປ່ຽນແປງຂອງຊັບພະຍາກອນບ່ອນເຮັດວຽກທີ່ໄດ້ສົນທະນາຂ້າງເທິງ. ລູກຄ້າທີ່ຕ້ອງການຕິດຕາມການປ່ຽນແປງໃນຮູບແບບ Java ສະໝັກຮັບການແຈ້ງເຕືອນ, ເຊິ່ງສະແດງເປັນວັດຖຸ ElementChangedEvent ທີ່ມີ IJavaElementDelta (ຮູບ 6).

ເຂົ້າ. 6. ElementChangedEvent ແລະ IJavaElementDelta

ຮູບແບບ Java ບໍ່ມີຂໍ້ມູນກ່ຽວກັບອົງປະກອບຂອງວິທີການຫຼືການແກ້ໄຂຊື່, ດັ່ງນັ້ນສໍາລັບການວິເຄາະລາຍລະອຽດຂອງລະຫັດທີ່ຂຽນໃນ Java, JDT Core ໃຫ້ຮູບແບບເພີ່ມເຕີມ (ທີ່ບໍ່ແມ່ນຕົວຈັບ): ຕົ້ນໄມ້ syntax abstract (ຕົ້ນໄມ້ syntax ທີ່ບໍ່ມີຕົວຕົນ, AST). AST ເປັນຕົວແທນຜົນຂອງການແຍກຂໍ້ຄວາມຕົ້ນສະບັບ. nodes AST ສອດຄ້ອງກັບອົງປະກອບຂອງໂຄງສ້າງຂອງໂມດູນແຫຼ່ງ (ການປະກາດ, ຕົວປະຕິບັດການ, ການສະແດງອອກ, ແລະອື່ນໆ) ແລະມີຂໍ້ມູນກ່ຽວກັບການປະສານງານຂອງອົງປະກອບທີ່ສອດຄ້ອງກັນໃນຂໍ້ຄວາມແຫຼ່ງ, ເຊັ່ນດຽວກັນກັບ (ເປັນທາງເລືອກ) ຂໍ້ມູນກ່ຽວກັບການແກ້ໄຂຊື່ໃນ ຮູບແບບຂອງການເຊື່ອມຕໍ່ກັບອັນທີ່ເອີ້ນວ່າ ການຜູກມັດ. Bindings ແມ່ນວັດຖຸທີ່ເປັນຕົວແທນຂອງຫນ່ວຍງານທີ່ມີຊື່, ເຊັ່ນ: ປະເພດ, ວິທີການ, ແລະຕົວແປ, ຮູ້ຈັກກັບ compiler. ບໍ່ເຫມືອນກັບ AST nodes, ເຊິ່ງປະກອບເປັນໄມ້ຢືນຕົ້ນ, ການຜູກມັດສະຫນັບສະຫນູນການອ້າງອີງຂ້າມແລະໂດຍທົ່ວໄປແລ້ວປະກອບເປັນກາຟ. ຊັ້ນ abstract ASTNode ແມ່ນຊັ້ນພື້ນຖານທົ່ວໄປສໍາລັບທຸກ AST nodes. ຊັ້ນຍ່ອຍ ASTNode ກົງກັບໂຄງສ້າງ syntactic ສະເພາະຂອງພາສາ Java.

ເນື່ອງຈາກວ່າຕົ້ນໄມ້ syntax ສາມາດບໍລິໂພກຈໍານວນຫນ່ວຍຄວາມຈໍາຢ່າງຫຼວງຫຼາຍ, JDT cache ພຽງແຕ່ຫນຶ່ງ AST ສໍາລັບບັນນາທິການທີ່ມີການເຄື່ອນໄຫວ. ບໍ່ເຫມືອນກັບແບບຈໍາລອງ Java, AST ໂດຍທົ່ວໄປແມ່ນເບິ່ງເປັນຕົວແບບ "ກາງ", "ຊົ່ວຄາວ" ທີ່ສະມາຊິກບໍ່ຄວນຖືກກ່າວເຖິງໂດຍລູກຄ້ານອກສະພາບການຂອງການດໍາເນີນງານທີ່ນໍາໄປສູ່ການສ້າງ AST.

ສາມຕົວແບບ (Java model, AST, bindings) ຮ່ວມກັນສ້າງເປັນ "ເຄື່ອງມືພັດທະນາອັດສະລິຍະ" ໃນ JDT, ລວມທັງຕົວແກ້ໄຂ Java ທີ່ມີປະສິດທິພາບທີ່ມີ "ຕົວຊ່ວຍ" ຕ່າງໆ, ການປະຕິບັດຕ່າງໆສໍາລັບການປຸງແຕ່ງລະຫັດແຫຼ່ງ (ລວມທັງການຈັດລາຍການນໍາເຂົ້າ. ຊື່​ແລະ​ການ​ຈັດ​ຮູບ​ແບບ​ຕາມ​ແບບ​ທີ່​ກໍາ​ນົດ​ໄວ້​)​, ຄົ້ນ​ຫາ​ແລະ​ເຄື່ອງ​ມື refactoring​. ໃນກໍລະນີນີ້, ຮູບແບບ Java ມີບົດບາດພິເສດ, ເນື່ອງຈາກວ່າມັນແມ່ນມັນຖືກນໍາໃຊ້ເປັນພື້ນຖານສໍາລັບການສະແດງພາບຂອງໂຄງສ້າງຂອງແອັບພລິເຄຊັນທີ່ກໍາລັງພັດທະນາ (ຕົວຢ່າງເຊັ່ນໃນ Package Explorer, Outline, Search, Call Hierarchy, ແລະ. ປະເພດ Hierarchy).

ອົງປະກອບຂອງ Eclipse ທີ່ໃຊ້ໃນ 1C:Enterprise Development Tools

ໃນຮູບ. ຮູບທີ 7 ສະແດງໃຫ້ເຫັນອົງປະກອບ Eclipse ທີ່ເປັນພື້ນຖານຂອງແພລະຕະຟອມເຕັກໂນໂລຢີສໍາລັບ 1C:Enterprise Development Tools.

ເຂົ້າ. 7. Eclipse ເປັນເວທີສໍາລັບ 1C:Enterprise Development Tools

ເວທີ Eclipse ສະໜອງພື້ນຖານໂຄງລ່າງ. ພວກເຮົາໄດ້ເບິ່ງບາງດ້ານຂອງໂຄງສ້າງພື້ນຖານນີ້ໃນພາກກ່ອນ.

Eclipse Modeling Framework (EMF) ສະຫນອງວິທີການທົ່ວໄປຂອງການສ້າງແບບຈໍາລອງຂໍ້ມູນໂຄງສ້າງ. EMF ແມ່ນປະສົມປະສານກັບ Eclipse Platform, ແຕ່ຍັງສາມາດຖືກນໍາໃຊ້ແຍກຕ່າງຫາກໃນຄໍາຮ້ອງສະຫມັກ Java ປົກກະຕິ. ເລື້ອຍໆ, ຜູ້ພັດທະນາ Eclipse ໃໝ່ແມ່ນຮູ້ຈັກດີກັບ EMF, ເຖິງແມ່ນວ່າພວກເຂົາຍັງບໍ່ທັນເຂົ້າໃຈຢ່າງເລິກເຊິ່ງກ່ຽວກັບຄວາມຊັບຊ້ອນຂອງເວທີ Eclipse. ຫນຶ່ງໃນເຫດຜົນສໍາລັບຄວາມນິຍົມທີ່ສົມຄວນສົມຄວນແມ່ນການອອກແບບທົ່ວໄປ, ເຊິ່ງລວມມີ, ໃນບັນດາສິ່ງອື່ນໆ, API ລະດັບ meta ທີ່ເປັນເອກະພາບ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດເຮັດວຽກກັບຮູບແບບ EMF ໂດຍທົ່ວໄປ. ການປະຕິບັດພື້ນຖານສໍາລັບວັດຖຸແບບຈໍາລອງທີ່ສະຫນອງໃຫ້ໂດຍ EMF ແລະລະບົບຍ່ອຍສໍາລັບການສ້າງລະຫັດແບບຈໍາລອງໂດຍອີງໃສ່ຮູບແບບ meta ເພີ່ມຄວາມໄວຂອງການພັດທະນາຢ່າງຫຼວງຫຼາຍແລະຫຼຸດຜ່ອນຈໍານວນຂໍ້ຜິດພາດ. EMF ຍັງມີກົນໄກສໍາລັບການຈັດລໍາດັບແບບຈໍາລອງ, ການຕິດຕາມການປ່ຽນແປງຂອງຕົວແບບ, ແລະອື່ນໆອີກ.

ເຊັ່ນດຽວກັນກັບເຄື່ອງມືທີ່ມີຈຸດປະສົງທົ່ວໄປຢ່າງແທ້ຈິງ, EMF ແມ່ນເຫມາະສົມສໍາລັບການແກ້ໄຂບັນຫາການສ້າງແບບຈໍາລອງທີ່ຫລາກຫລາຍ, ແຕ່ບາງຊັ້ນຂອງແບບຈໍາລອງ (ຕົວຢ່າງ, ຮູບແບບທີ່ອີງໃສ່ມືທີ່ໄດ້ກ່າວມາຂ້າງເທິງ) ອາດຈະຕ້ອງການເຄື່ອງມືສ້າງແບບຈໍາລອງທີ່ພິເສດກວ່າ. ການເວົ້າກ່ຽວກັບ EMF ແມ່ນວຽກງານທີ່ບໍ່ມີຄວາມຮູ້ບຸນຄຸນ, ໂດຍສະເພາະໃນຂອບເຂດຈໍາກັດຂອງບົດຄວາມຫນຶ່ງ, ເພາະວ່ານີ້ແມ່ນຫົວຂໍ້ຂອງຫນັງສືແຍກຕ່າງຫາກ, ແລະຫນາແຫນ້ນ. ພວກເຮົາພຽງແຕ່ສັງເກດວ່າລະບົບການທົ່ວໄປທີ່ມີຄຸນນະພາບສູງທີ່ຕິດພັນກັບ EMF ໄດ້ອະນຸຍາດໃຫ້ເກີດບັນດາໂຄງການທີ່ອຸທິດຕົນເພື່ອການສ້າງແບບຈໍາລອງ, ເຊິ່ງລວມຢູ່ໃນໂຄງການລະດັບສູງສຸດ. ການສ້າງແບບຈໍາລອງ Eclipse ພ້ອມກັບ EMF ເອງ. ໂຄງການຫນຶ່ງດັ່ງກ່າວແມ່ນ Eclipse Xtext.

Eclipse Xtext ສະຫນອງໂຄງສ້າງພື້ນຖານ "ສ້າງແບບຈໍາລອງຂໍ້ຄວາມ". ໃຊ້ Xtext ແອນລິໂອ ສໍາ​ລັບ​ການ​ແຍກ​ຂໍ້​ຄວາມ​ແຫຼ່ງ​ຂໍ້​ຄວາມ​ແລະ EMF ສໍາ​ລັບ​ການ​ເປັນ​ຕົວ​ແທນ​ຜົນ​ໄດ້​ຮັບ ASG (ກາ​ຟ semantic abstract, ເຊິ່ງ​ເປັນ​ການ​ປະ​ສົມ​ປະ​ສານ​ຂອງ AST ແລະ​ການ​ຜູກ​ພັນ​)​, ເອີ້ນ​ວ່າ "ຕົວ​ແບບ semantic​"​. ໄວຍະກອນຂອງພາສາທີ່ສ້າງແບບຈໍາລອງໂດຍ Xtext ຖືກອະທິບາຍໃນພາສາຂອງ Xtext. ນີ້ອະນຸຍາດໃຫ້ທ່ານບໍ່ພຽງແຕ່ສ້າງຄໍາອະທິບາຍໄວຍາກອນສໍາລັບ ANTLR, ແຕ່ຍັງໄດ້ຮັບກົນໄກ serialization AST (i.e. Xtext ສະຫນອງທັງຕົວວິເຄາະແລະ unparser), ຄໍາຊີ້ບອກສະພາບການ, ແລະຈໍານວນຂອງອົງປະກອບພາສາອື່ນໆ. ໃນທາງກົງກັນຂ້າມ, ພາສາໄວຍາກອນທີ່ໃຊ້ໃນ Xtext ແມ່ນມີຄວາມຍືດຫຍຸ່ນຫນ້ອຍກວ່າ, ເວົ້າ, ພາສາໄວຍາກອນທີ່ໃຊ້ໃນ ANTLR. ດັ່ງນັ້ນ, ບາງຄັ້ງມັນຈໍາເປັນຕ້ອງ "ງໍ" ພາສາທີ່ປະຕິບັດເປັນ Xtext, ເຊິ່ງປົກກະຕິແລ້ວບໍ່ແມ່ນບັນຫາຖ້າພວກເຮົາເວົ້າກ່ຽວກັບພາສາທີ່ຖືກພັດທະນາຕັ້ງແຕ່ເລີ່ມຕົ້ນ, ແຕ່ອາດຈະບໍ່ຍອມຮັບໄດ້ສໍາລັບພາສາທີ່ມີ syntax ທີ່ກໍານົດໄວ້ແລ້ວ. ເຖິງວ່າຈະມີນີ້, Xtext ປະຈຸບັນເປັນເຄື່ອງມືທີ່ແກ່ທີ່ສຸດ, ອຸດົມສົມບູນ, ແລະ versatile ໃນ Eclipse ສໍາລັບການກໍ່ສ້າງພາສາການຂຽນໂປລແກລມແລະເຄື່ອງມືພັດທະນາໃຫ້ເຂົາເຈົ້າ. ໂດຍສະເພາະ, ມັນເປັນເຄື່ອງມືທີ່ເຫມາະສົມສໍາລັບການສ້າງຕົວແບບຢ່າງໄວວາ ພາສາສະເພາະໂດເມນ (ພາສາສະເພາະໂດເມນ, DSL). ນອກເຫນືອໄປຈາກ "ຫຼັກພາສາ" ທີ່ໄດ້ກ່າວມາຂ້າງເທິງໂດຍອີງໃສ່ ANTLR ແລະ EMF, Xtext ສະຫນອງອົງປະກອບລະດັບສູງທີ່ເປັນປະໂຫຍດຫຼາຍ, ລວມທັງກົນໄກການດັດສະນີ, ການກໍ່ສ້າງທີ່ເພີ່ມຂຶ້ນ, "ບັນນາທິການທີ່ສະຫຼາດ", ແລະຫຼາຍ, ຫຼາຍ, ແຕ່ອອກຈາກການຈັດການ - ຮູບແບບພາສາທີ່ອີງໃສ່. ເຊັ່ນດຽວກັນກັບ EMF, Xtext ແມ່ນຫົວຂໍ້ທີ່ສົມຄວນເປັນຫນັງສືແຍກຕ່າງຫາກ, ແລະພວກເຮົາເວົ້າສັ້ນໆກ່ຽວກັບຄວາມສາມາດທັງຫມົດຂອງມັນໃນປັດຈຸບັນ.

1C: ເຄື່ອງມືພັດທະນາວິສາຫະກິດຢ່າງຈິງຈັງໃຊ້ທັງ EMF ຕົວມັນເອງແລະໂຄງການ Eclipse Modeling ອື່ນໆ. ໂດຍສະເພາະ, Xtext ແມ່ນຫນຶ່ງໃນພື້ນຖານຂອງເຄື່ອງມືພັດທະນາສໍາລັບ 1C: ພາສາວິສາຫະກິດເປັນພາສາການຂຽນໂປຼແກຼມແລະພາສາແບບສອບຖາມ. ພື້ນຖານອື່ນສໍາລັບເຄື່ອງມືພັດທະນາເຫຼົ່ານີ້ແມ່ນໂຄງການ Eclipse Handly, ເຊິ່ງພວກເຮົາຈະສົນທະນາໃນລາຍລະອຽດເພີ່ມເຕີມ (ຂອງອົງປະກອບ Eclipse ທີ່ລະບຸໄວ້, ມັນຍັງເປັນທີ່ຮູ້ຈັກຫນ້ອຍທີ່ສຸດ).

Eclipse Handlyເຊິ່ງເປັນໂຄງການຍ່ອຍຂອງໂຄງການລະດັບສູງສຸດຂອງ Eclipse Technology, ປະກົດຂຶ້ນເປັນຜົນມາຈາກການປະກອບສ່ວນລະຫັດເບື້ອງຕົ້ນໃຫ້ກັບມູນນິທິ Eclipse ທີ່ສ້າງຂຶ້ນໂດຍ 1C ໃນປີ 2014. ນັບຕັ້ງແຕ່ນັ້ນມາ, 1C ໄດ້ສືບຕໍ່ສະຫນັບສະຫນູນການພັດທະນາຂອງໂຄງການ: Handly committers ແມ່ນພະນັກງານຂອງບໍລິສັດ. ໂຄງ​ການ​ດັ່ງ​ກ່າວ​ແມ່ນ​ຂະ​ຫນາດ​ນ້ອຍ​, ແຕ່​ວ່າ​ມັນ​ຄອບ​ຄອງ niche ເປັນ​ເອ​ກະ​ລັກ​ຫຼາຍ​ໃນ Eclipse​: ເປົ້າ​ຫມາຍ​ຕົ້ນ​ຕໍ​ຂອງ​ຕົນ​ແມ່ນ​ເພື່ອ​ສະ​ຫນັບ​ສະ​ຫນູນ​ການ​ພັດ​ທະ​ນາ​ຂອງ​ຕົວ​ແບບ​ທີ່​ອີງ​ໃສ່​ການ​ຈັບ​ໄດ້​.

ຫຼັກການພື້ນຖານສະຖາປັດຕະຍະກໍາຂອງຕົວແບບທີ່ອີງໃສ່ຕົວຈັບ, ເຊັ່ນ: ມື / ຮ່າງກາຍ, ໄດ້ຖືກປຶກສາຫາລືຂ້າງເທິງໂດຍໃຊ້ຮູບແບບຊັບພະຍາກອນແລະຕົວແບບ Java ເປັນຕົວຢ່າງ. ມັນຍັງສັງເກດເຫັນວ່າທັງຮູບແບບຊັບພະຍາກອນແລະຮູບແບບ Java ແມ່ນພື້ນຖານທີ່ສໍາຄັນສໍາລັບເຄື່ອງມືພັດທະນາ Eclipse Java (JDT). ແລະເນື່ອງຈາກເກືອບທຸກໂຄງການ *DT Eclipse ມີສະຖາປັດຕະຍະກໍາທີ່ຄ້າຍຄືກັບ JDT, ມັນຈະບໍ່ເປັນການເວົ້າເກີນຈິງທີ່ຈະເວົ້າວ່າຕົວແບບທີ່ອີງໃສ່ຕົວຈັດການແມ່ນມີຫຼາຍ, ຖ້າບໍ່ແມ່ນ IDE ທັງຫມົດທີ່ສ້າງຂຶ້ນຢູ່ເທິງສຸດຂອງ Eclipse Platform. ຕົວຢ່າງ, ເຄື່ອງມືພັດທະນາ Eclipse C/C++ (CDT) ມີຕົວແບບ C/C++ ທີ່ໃຊ້ຕົວຈັດການທີ່ມີບົດບາດດຽວກັນກັບສະຖາປັດຕະຍະກຳ CDT ຄືກັບຕົວແບບ Java ໃນ JDT.

ກ່ອນ Handly, Eclipse ບໍ່ໄດ້ໃຫ້ຫ້ອງສະໝຸດສະເພາະສຳລັບການສ້າງຕົວແບບພາສາທີ່ໃຊ້ຕົວຈັດການ. ແບບຈໍາລອງທີ່ມີຢູ່ໃນປະຈຸບັນແມ່ນໄດ້ຖືກສ້າງຂື້ນໂດຍສ່ວນໃຫຍ່ໂດຍການດັດແປງລະຫັດຕົວແບບ Java ໂດຍກົງ (aka copy/paste), ໃນກໍລະນີທີ່ມັນອະນຸຍາດໃຫ້ ໃບອະນຸຍາດສາທາລະນະ Eclipse (EPL). (ແນ່ນອນ, ນີ້ມັກຈະບໍ່ແມ່ນບັນຫາທາງດ້ານກົດຫມາຍສໍາລັບໂຄງການ Eclipse ຕົວຂອງມັນເອງ, ແຕ່ບໍ່ແມ່ນສໍາລັບຜະລິດຕະພັນແຫຼ່ງປິດ.) ນອກເຫນືອຈາກຄວາມຫນ້າເຊື່ອຖືຂອງມັນ, ເຕັກນິກນີ້ແນະນໍາບັນຫາທີ່ຮູ້ຈັກກັນດີ: ການຊໍ້າຊ້ອນຂອງລະຫັດທີ່ນໍາສະເຫນີໂດຍໃນເວລາທີ່ປັບຕົວເຂົ້າກັບຄວາມຜິດພາດ, ແລະອື່ນໆ ສິ່ງທີ່ຮ້າຍແຮງກວ່າເກົ່າແມ່ນວ່າຕົວແບບທີ່ເປັນຜົນມາຈາກ "ສິ່ງທີ່ຢູ່ໃນຕົວຂອງມັນເອງ" ແລະບໍ່ໄດ້ໃຊ້ປະໂຫຍດຈາກທ່າແຮງສໍາລັບການລວມຕົວ. ແຕ່ການໂດດດ່ຽວແນວຄວາມຄິດ ແລະໂປໂຕຄອນສຳລັບຕົວແບບພາສາທີ່ອີງໃສ່ການຈັດການສາມາດນໍາໄປສູ່ການສ້າງອົງປະກອບທີ່ໃຊ້ຄືນໄດ້ສໍາລັບການເຮັດວຽກກັບພວກມັນ, ຄ້າຍຄືກັບສິ່ງທີ່ເກີດຂຶ້ນໃນກໍລະນີຂອງ EMF.

ມັນບໍ່ແມ່ນວ່າ Eclipse ບໍ່ເຂົ້າໃຈບັນຫາເຫຼົ່ານີ້. ກັບໄປໃນປີ 2005 Martin Aeschlimann, ສະຫຼຸບປະສົບການຂອງການພັດທະນາຕົ້ນແບບ CDT, ໂຕ້ຖຽງ ຄວາມຕ້ອງການທີ່ຈະສ້າງພື້ນຖານໂຄງລ່າງທົ່ວໄປສໍາລັບຕົວແບບພາສາ, ລວມທັງຕົວແບບທີ່ອີງໃສ່ການຈັດການ. ແຕ່, ຕາມທີ່ມັກຈະເກີດຂຶ້ນ, ເນື່ອງຈາກວຽກງານບູລິມະສິດທີ່ສູງກວ່າ, ການປະຕິບັດແນວຄວາມຄິດເຫຼົ່ານີ້ບໍ່ເຄີຍໄດ້ຮັບມັນ. ໃນ​ຂະ​ນະ​ດຽວ​ກັນ, factorization of *DT code is still one of the underdeveloped topics in Eclipse.

ໃນຄວາມຮູ້ສຶກທີ່ແນ່ນອນ, ໂຄງການ Handly ໄດ້ຖືກອອກແບບເພື່ອແກ້ໄຂບັນຫາເກືອບຄືກັນກັບ EMF, ແຕ່ສໍາລັບຕົວແບບທີ່ອີງໃສ່ການຈັດການ, ແລະພາສາຕົ້ນຕໍ (i.e., ເປັນຕົວແທນຂອງໂຄງສ້າງຂອງບາງພາສາການຂຽນໂປຼແກຼມ). ເປົ້າໝາຍຫຼັກທີ່ຕັ້ງໄວ້ໃນເວລາອອກແບບ Handly ແມ່ນລະບຸໄວ້ຂ້າງລຸ່ມນີ້:

• ການກໍານົດຕົວຫຍໍ້ຂອງຫົວຂໍ້ຕົ້ນຕໍ.
• ຫຼຸດຜ່ອນຄວາມພະຍາຍາມແລະການປັບປຸງຄຸນນະພາບຂອງການປະຕິບັດຕົວແບບພາສາທີ່ອີງໃສ່ການຈັດການໂດຍຜ່ານການນໍາໃຊ້ລະຫັດຄືນໃຫມ່.
• ການສະຫນອງ API ລະດັບ meta ປະສົມປະສານກັບແບບຈໍາລອງຜົນໄດ້ຮັບ, ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະສ້າງອົງປະກອບ IDE ທົ່ວໄປທີ່ເຮັດວຽກກັບຕົວແບບທີ່ອີງໃສ່ພາສາ.
• ຄວາມຍືດຫຍຸ່ນແລະການຂະຫຍາຍ.
• ການປະສົມປະສານກັບ Xtext (ໃນຊັ້ນແຍກຕ່າງຫາກ).

ເພື່ອເນັ້ນໃສ່ແນວຄວາມຄິດ ແລະໂປຣໂຕຄໍທົ່ວໄປ, ການປະຕິບັດທີ່ມີຢູ່ແລ້ວຂອງຮູບແບບການຈັດການພາສາໄດ້ຖືກວິເຄາະ. ການໂຕ້ຕອບຕົ້ນຕໍແລະການປະຕິບັດພື້ນຖານທີ່ສະຫນອງໂດຍ Handly ແມ່ນສະແດງຢູ່ໃນຮູບ. 8.

ເຂົ້າ. 8. ການໂຕ້ຕອບທົ່ວໄປແລະການປະຕິບັດພື້ນຖານຂອງອົງປະກອບ Handly

ອິນເຕີເຟດ IElement ເປັນຕົວແທນຂອງການຈັດການຂອງອົງປະກອບໃດຫນຶ່ງແລະເປັນເລື່ອງທໍາມະດາກັບອົງປະກອບຂອງທຸກຮູບແບບທີ່ອີງໃສ່ມື. ອົງປະກອບຂອງຫ້ອງຮຽນ abstract ປະຕິບັດກົນໄກການຈັດການ / ຮ່າງກາຍໂດຍທົ່ວໄປ (ຮູບ 9).

ເຂົ້າ. 9. IElement ແລະການຈັດການທົ່ວໄປ / ການປະຕິບັດຮ່າງກາຍ

ນອກຈາກນັ້ນ, Handly ສະຫນອງກົນໄກທົ່ວໄປສໍາລັບການແຈ້ງກ່ຽວກັບການປ່ຽນແປງໃນອົງປະກອບຂອງຕົວແບບ (ຮູບ 10). ດັ່ງທີ່ທ່ານສາມາດເບິ່ງເຫັນໄດ້, ມັນຄ້າຍຄືກັນກັບກົນໄກການແຈ້ງເຕືອນທີ່ປະຕິບັດຢູ່ໃນຮູບແບບຊັບພະຍາກອນແລະແບບຈໍາລອງ Java, ແລະໃຊ້ IElementDelta ເພື່ອສະຫນອງການເປັນຕົວແທນລວມຂອງຂໍ້ມູນການປ່ຽນແປງອົງປະກອບ.

ເຂົ້າ. 10. ການໂຕ້ຕອບທົ່ວໄປ ແລະການປະຕິບັດພື້ນຖານຂອງກົນໄກການແຈ້ງເຕືອນ Handly

ສ່ວນ Handly ທີ່ໄດ້ກ່າວມາຂ້າງເທິງ (ຮູບ 9 ແລະ 10) ສາມາດຖືກນໍາໃຊ້ເພື່ອເປັນຕົວແທນເກືອບທຸກຮູບແບບທີ່ອີງໃສ່ handle. ສໍາລັບການສ້າງ ພາສາສາດ ແບບຈໍາລອງ, ໂຄງການສະຫນອງການທໍາງານເພີ່ມເຕີມ - ໂດຍສະເພາະ, ການໂຕ້ຕອບທົ່ວໄປແລະການປະຕິບັດພື້ນຖານສໍາລັບອົງປະກອບຂອງໂຄງສ້າງຂໍ້ຄວາມແຫຼ່ງ, ອັນທີ່ເອີ້ນວ່າ. ອົງປະກອບແຫຼ່ງ (ຮູບ 8). ການໂຕ້ຕອບ ISourceFile ເປັນຕົວແທນຂອງໄຟລ໌ແຫຼ່ງ, ແລະ ISourceConstruct ເປັນຕົວແທນຂອງອົງປະກອບພາຍໃນໄຟລ໌ແຫຼ່ງ. ຊັ້ນຮຽນທີ່ບໍ່ມີຕົວຕົນ SourceFile ແລະ SourceConstruct ປະຕິບັດກົນໄກທົ່ວໄປເພື່ອສະຫນັບສະຫນູນການເຮັດວຽກກັບໄຟລ໌ຕົ້ນສະບັບແລະອົງປະກອບຂອງພວກມັນ, ສໍາລັບຕົວຢ່າງ, ເຮັດວຽກກັບຕົວເກັບຂໍ້ມູນຂໍ້ຄວາມ, ການຜູກມັດກັບຈຸດປະສານງານຂອງອົງປະກອບໃນຂໍ້ຄວາມຕົ້ນສະບັບ, ການຄືນໃຫມ່ຂອງຕົວແບບທີ່ມີເນື້ອຫາໃນປະຈຸບັນຂອງ buffer ສໍາເນົາທີ່ເຮັດວຽກ. , ແລະອື່ນໆ. ການຈັດຕັ້ງປະຕິບັດກົນໄກເຫຼົ່ານີ້ໂດຍປົກກະຕິແມ່ນຂ້ອນຂ້າງເປັນສິ່ງທ້າທາຍ, ແລະ Handly ສາມາດຫຼຸດຜ່ອນຄວາມພະຍາຍາມໃນການພັດທະນາຮູບແບບພາສາທີ່ອີງໃສ່ການຈັດການໂດຍການສະຫນອງການປະຕິບັດພື້ນຖານທີ່ມີຄຸນນະພາບສູງ.

ນອກເຫນືອຈາກກົນໄກຫຼັກທີ່ລະບຸໄວ້ຂ້າງເທິງ, Handly ສະຫນອງໂຄງສ້າງພື້ນຖານສໍາລັບຂໍ້ຄວາມ buffers ແລະ snapshots, ສະຫນັບສະຫນູນການເຊື່ອມໂຍງກັບຕົວແກ້ໄຂລະຫັດແຫຼ່ງ (ລວມທັງການລວມຕົວນອກກ່ອງກັບບັນນາທິການ Xtext), ເຊັ່ນດຽວກັນກັບບາງອົງປະກອບ UI ທົ່ວໄປທີ່. ເຮັດວຽກກັບຕົວແກ້ໄຂລະຫັດແຫຼ່ງ Handly ເຊັ່ນວ່າກອບໂຄງຮ່າງ. ເພື່ອສະແດງໃຫ້ເຫັນເຖິງຄວາມສາມາດຂອງມັນ, ໂຄງການດັ່ງກ່າວໄດ້ໃຫ້ຕົວຢ່າງຫຼາຍຢ່າງ, ລວມທັງການປະຕິບັດຕົວແບບ Java ໃນ Handly. (ເມື່ອປຽບທຽບກັບການປະຕິບັດແບບຈໍາລອງຂອງ Java ໃນ JDT ຢ່າງເຕັມທີ່, ຮູບແບບນີ້ແມ່ນມີຄວາມຕັ້ງໃຈທີ່ງ່າຍດາຍເພື່ອຄວາມຊັດເຈນກວ່າ.)

ດັ່ງທີ່ໄດ້ລະບຸໄວ້ກ່ອນຫນ້ານີ້, ຈຸດສຸມທີ່ສໍາຄັນໃນລະຫວ່າງການອອກແບບເບື້ອງຕົ້ນຂອງ Handly ແລະການພັດທະນາຕໍ່ມາແມ່ນແລະສືບຕໍ່ຢູ່ໃນການຂະຫຍາຍແລະຄວາມຍືດຫຍຸ່ນ.

ໃນຫຼັກການ, ຮູບແບບທີ່ອີງໃສ່ມືຈັບຂະຫນາດຂ້ອນຂ້າງດີ "ໂດຍການອອກແບບ". ສໍາລັບຕົວຢ່າງ, idiom handle / body ອະນຸຍາດໃຫ້ທ່ານຈໍາກັດຈໍານວນຫນ່ວຍຄວາມຈໍາທີ່ບໍລິໂພກໂດຍຕົວແບບ. ແຕ່ຍັງມີ nuances. ດັ່ງນັ້ນ, ໃນເວລາທີ່ການທົດສອບ Handly ສໍາລັບ scalability, ບັນຫາໄດ້ຖືກຄົ້ນພົບໃນການປະຕິບັດກົນໄກການແຈ້ງການ - ໃນເວລາທີ່ຈໍານວນຂະຫນາດໃຫຍ່ຂອງອົງປະກອບໄດ້ຖືກປ່ຽນແປງ, ການກໍ່ສ້າງ deltas ໄດ້ໃຊ້ເວລາຫຼາຍເກີນໄປ. ມັນໄດ້ຫັນອອກວ່າບັນຫາດຽວກັນແມ່ນມີຢູ່ໃນຮູບແບບ JDT Java, ເຊິ່ງລະຫັດທີ່ສອດຄ້ອງກັນໄດ້ຖືກດັດແປງຄັ້ງດຽວ. ພວກເຮົາໄດ້ແກ້ໄຂຂໍ້ບົກພ່ອງໃນ Handly ແລະກະກຽມການສ້ອມແປງທີ່ຄ້າຍຄືກັນສໍາລັບ JDT, ເຊິ່ງໄດ້ຮັບຄວາມກະຕັນຍູ. ນີ້ແມ່ນພຽງແຕ່ຕົວຢ່າງຫນຶ່ງທີ່ແນະນໍາ Handly ເຂົ້າໃນການປະຕິບັດຕົວແບບທີ່ມີຢູ່ອາດຈະເປັນປະໂຫຍດ, ເພາະວ່າໃນກໍລະນີນີ້ bug ດັ່ງກ່າວສາມາດຖືກແກ້ໄຂໄດ້ຢູ່ໃນສະຖານທີ່ດຽວ.

ເພື່ອເຮັດໃຫ້ການປະຕິບັດ Handly ເຂົ້າໄປໃນການປະຕິບັດຕົວແບບທີ່ມີຢູ່ແລ້ວທາງດ້ານວິຊາການ, ຫ້ອງສະຫມຸດຕ້ອງມີຄວາມຍືດຫຍຸ່ນທີ່ສໍາຄັນ. ບັນຫາຕົ້ນຕໍແມ່ນການຮັກສາຄວາມເຂົ້າກັນໄດ້ໃນດ້ານຫລັງໃນທົ່ວຮູບແບບ API. ບັນຫານີ້ໄດ້ຖືກແກ້ໄຂໃນ Handly 0.5 ໂດຍການແຍກ API ສະເພາະຕົວແບບຢ່າງຈະແຈ້ງ, ກຳນົດ ແລະຄວບຄຸມໂດຍຜູ້ພັດທະນາຢ່າງຄົບຖ້ວນ, ຈາກ API ລະດັບ meta-level ທີ່ສະໜອງໃຫ້ໂດຍຫ້ອງສະໝຸດ. ນີ້ບໍ່ພຽງແຕ່ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທາງດ້ານວິຊາການທີ່ຈະປະຕິບັດ Handly ເຂົ້າໄປໃນການປະຕິບັດທີ່ມີຢູ່ແລ້ວ, ແຕ່ຍັງເຮັດໃຫ້ຜູ້ພັດທະນາຮູບແບບໃຫມ່ມີອິດສະລະພາບທີ່ສໍາຄັນໃນເວລາທີ່ການອອກແບບ API.

ຄວາມຍືດຫຍຸ່ນຍັງມີດ້ານອື່ນໆເຊັ່ນກັນ. ຕົວຢ່າງ, Handly imposes ເກືອບບໍ່ມີຂໍ້ຈໍາກັດກ່ຽວກັບໂຄງສ້າງຂອງຕົວແບບແລະສາມາດຖືກນໍາໃຊ້ເພື່ອສ້າງແບບຈໍາລອງທັງພາສາທົ່ວໄປແລະພາສາສະເພາະ. ເມື່ອສ້າງໂຄງສ້າງຂອງໄຟລ໌ແຫຼ່ງ, Handly ບໍ່ໄດ້ກໍານົດຮູບແບບການເປັນຕົວແທນ AST ໂດຍສະເພາະແລະ, ໃນຫຼັກການ, ບໍ່ຈໍາເປັນຕ້ອງມີ AST ຕົວມັນເອງ, ດັ່ງນັ້ນການຮັບປະກັນຄວາມເຂົ້າກັນໄດ້ກັບເກືອບທຸກກົນໄກການແຍກ. ສຸດທ້າຍ, Handly ສະຫນັບສະຫນູນການເຊື່ອມໂຍງຢ່າງເຕັມທີ່ກັບພື້ນທີ່ເຮັດວຽກ Eclipse, ແຕ່ຍັງສາມາດເຮັດວຽກໂດຍກົງກັບລະບົບໄຟລ໌ຍ້ອນການເຊື່ອມໂຍງກັບມັນ. ລະບົບໄຟລ໌ Eclipse (EFS).

ສະບັບປະຈຸບັນ Handly 0.6 ອອກມາໃນເດືອນທັນວາ 2016. ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າໂຄງການປະຈຸບັນຢູ່ໃນສະພາບຂອງການເກີດແລະ API ຍັງບໍ່ທັນໄດ້ແກ້ໄຂໃນທີ່ສຸດ, Handly ໄດ້ຖືກນໍາໃຊ້ແລ້ວໃນສອງຜະລິດຕະພັນການຄ້າຂະຫນາດໃຫຍ່ທີ່ມີຄວາມສ່ຽງຕໍ່ການເປັນ "ຜູ້ຮັບຮອງເອົາຕົ້ນ", ແລະ, ຂ້າພະເຈົ້າຕ້ອງເວົ້າວ່າ, ບໍ່ເສຍໃຈມັນເທື່ອ.

ດັ່ງທີ່ໄດ້ກ່າວໄວ້ຂ້າງເທິງ, ຫນຶ່ງໃນຜະລິດຕະພັນເຫຼົ່ານີ້ແມ່ນ 1C: ເຄື່ອງມືພັດທະນາວິສາຫະກິດ, ບ່ອນທີ່ Handly ຖືກນໍາໃຊ້ຕັ້ງແຕ່ເລີ່ມຕົ້ນເພື່ອສ້າງຕົວແບບຂອງໂຄງສ້າງລະດັບສູງຂອງ 1C: ພາສາວິສາຫະກິດເປັນພາສາການຂຽນໂປລແກລມແລະພາສາສອບຖາມ. . ຜະລິດຕະພັນອື່ນແມ່ນເປັນທີ່ຮູ້ຈັກຫນ້ອຍຕໍ່ປະຊາຊົນທົ່ວໄປ. ນີ້ Codasip Studio, ສະພາບແວດລ້ອມການອອກແບບປະສົມປະສານສໍາລັບໂປເຊດເຊີຊຸດຄໍາແນະນໍາສະເພາະຄໍາຮ້ອງສະຫມັກ (ASIP), ຖືກນໍາໃຊ້ທັງພາຍໃນບໍລິສັດເຊັກໂກ Codasip ຕົວມັນເອງແລະໂດຍລູກຄ້າຂອງຕົນ, ລວມທັງ AMD, AVG, ມືຖື, ການອອກແບບ Sigma. Codasip ໄດ້ໃຊ້ Handly ໃນການຜະລິດຕັ້ງແຕ່ປີ 2015, ເລີ່ມຕົ້ນດ້ວຍສະບັບ Handly 0.2. ການປ່ອຍຫລ້າສຸດຂອງ Codasip Studio ໃຊ້ເວີຊັນ 0.5, ປ່ອຍອອກມາເມື່ອເດືອນມິຖຸນາ 2016. Ondřej Ilčík, ຜູ້ທີ່ນໍາພາການພັດທະນາ IDE ຢູ່ Codasip, ກໍາລັງຕິດຕໍ່ກັບໂຄງການ, ໃຫ້ຄໍາຄິດເຫັນທີ່ສໍາຄັນໃນນາມຂອງ "ຜູ້ຮັບຮອງເອົາພາກສ່ວນທີສາມ". ລາວຍັງສາມາດຊອກຫາເວລາຫວ່າງເພື່ອເຂົ້າຮ່ວມໂດຍກົງໃນການພັດທະນາໂຄງການ, ການປະຕິບັດຊັ້ນ UI (~ 4000 ເສັ້ນຂອງລະຫັດ) ສໍາລັບຫນຶ່ງໃນຕົວຢ່າງ Handly, ຮູບແບບ Java. ຂໍ້ມູນມືທໍາອິດລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບການນໍາໃຊ້ Handly by adopters ສາມາດພົບເຫັນຢູ່ໃນຫນ້າ ເລື່ອງຄວາມສໍາເລັດ ໂຄງການ.

ພວກເຮົາຫວັງວ່າຫຼັງຈາກການປ່ອຍເວີຊັນ 1.0 ດ້ວຍການຮັບປະກັນຄວາມຫມັ້ນຄົງຂອງ API ແລະໂຄງການອອກຈາກລັດ incubation, Handly ຈະມີຜູ້ຮັບຮອງເອົາໃຫມ່. ໃນເວລານີ້, ໂຄງການຍັງສືບຕໍ່ທົດສອບແລະປັບປຸງ API ຕື່ມອີກ, ປ່ອຍສອງ "ທີ່ສໍາຄັນ" ຕໍ່ປີ - ໃນເດືອນມິຖຸນາ (ວັນດຽວກັນກັບການປ່ອຍ Eclipse ພ້ອມໆກັນ) ແລະເດືອນທັນວາ, ສະຫນອງຕາຕະລາງການຄາດເດົາທີ່ຜູ້ຮັບຮອງເອົາສາມາດອີງໃສ່ໄດ້. ພວກເຮົາຍັງສາມາດເພີ່ມວ່າ "ອັດຕາ bug" ຂອງໂຄງການຍັງຢູ່ໃນລະດັບຕໍ່າຢ່າງຕໍ່ເນື່ອງແລະ Handly ໄດ້ເຮັດວຽກຢ່າງຫນ້າເຊື່ອຖືໃນຜະລິດຕະພັນຂອງຜູ້ຮັບຮອງເອົາຕົ້ນຕັ້ງແຕ່ຮຸ່ນທໍາອິດ. ເພື່ອຄົ້ນຫາ Eclipse Handly ຕື່ມອີກ, ທ່ານສາມາດນໍາໃຊ້ ການ​ເລີ່ມ​ຕົ້ນ Tutorial и ພາບລວມດ້ານສະຖາປັດຕະຍະ ກຳ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com