Pine Script-ის ბიბლიოთეკები: ფუნქციების იმპორტი, ექსპორტი და ვერსიები

როდის არის ბიბლიოთეკა გამართლებული და როდის საკმარისია კოდის კოპირება?

ზღვარი მარტივი და ნათელია. სანამ გამოთვლა მხოლოდ ერთ სკრიპტს სჭირდება, ის ამავე სკრიპტში უნდა დარჩეს. როგორც კი შეამჩნევთ, რომ ძველ ინდიკატორს იქიდან ფუნქციის დასაკოპირებლად ხსნით, შემდეგ კი ამას კიდევ და კიდევ იმეორებთ, კოდის კოპირება ერთჯერად გამოქვეყნებაზე დახარჯულ ძალისხმევაზე ძვირი ხდება.

ბიბლიოთეკას თავისი ფასი აქვს და ამის წინასწარ ცოდნა სჯობს. მას უბრალოდ რედაქტორში ვერ შეინახავთ და ვერ დააკავშირებთ: ის აუცილებლად უნდა გამოქვეყნდეს, თუნდაც პირადად. ბიბლიოთეკა ყოველთვის ღია საწყისი კოდით ქვეყნდება — TradingView სხვა ვარიანტს არ იძლევა. გამოქვეყნების შემდეგ კი მის უკანა რიცხვით შეცვლას ისე თავისუფლად ვეღარ შეძლებთ, როგორც რედაქტორში შენახული მონახაზისას.

სანაცვლოდ ჭეშმარიტების ერთ წყაროს იღებთ. ბიბლიოთეკაში ფორმულას ასწორებთ, ახალ ვერსიას უშვებთ და შემდეგ თავად წყვეტთ, რომელი სკრიპტები გადაიყვანოთ მასზე. შეუმჩნევლად არცერთი სკრიპტი არ გადავა და ეს ნაკლი კი არა, პლატფორმის გააზრებული გადაწყვეტილებაა.

თუ ენას ჯერ მხოლოდ ეცნობით და არ გადაგიწყვეტიათ, ღირს თუ არა საკუთარი კოდის დაწერა, ზოგადი სურათით დაიწყეთ: რა არის Pine Script და როგორ არის ის მოწყობილი. ბიბლიოთეკები უკვე მეორე საფეხურია და ყველას არ სჭირდება.

რით განსხვავდება library() indicator()-ისა და strategy()-ისგან?

Pine Script-ის ბიბლიოთეკები ინდიკატორისა და სტრატეგიის თანასწორი, სკრიპტის მესამე ტიპია. თითოეული სკრიპტი ზუსტად ერთი დეკლარაციით იწყება და ის გლობალურ არეში იწერება. შესაბამისად, არჩევანი მარტივია: ან indicator(), ან strategy(), ან library(). სხვა ვარიანტი და მათი გაერთიანების შესაძლებლობა არ არსებობს.

ბიბლიოთეკასა და ინდიკატორს შორის რამდენიმე განსხვავებაა და თითქმის ყველა მათგანი ლოგიკურია.

სიტყვა export მხოლოდ ბიბლიოთეკებისთვისაა ხელმისაწვდომი. ინდიკატორი, სურვილის მიუხედავად, საკუთარ ფუნქციას სხვა სკრიპტს ვერ გადასცემს. ეს აკრძალვა აკრძალვისთვის კი არა, როლების გამიჯვნაა.

ბიბლიოთეკის სათაური სახელთა სივრცის სახელად გამოიყენება, ამიტომ მის მიმართ წესები უფრო მკაცრია. დასაშვებია მხოლოდ ლათინური ასოები, ციფრები და ქვედა ტირე; სახელის ციფრით დაწყება არ შეიძლება. სტრიქონი "Library for 14-day averages" მხოლოდ გამოტოვებებისა და დეფისის გამო გამოიწვევს კომპილაციის შეცდომას, ხოლო "Library_for_14_day_averages" წარმატებით გაივლის.

ბიბლიოთეკა გრაფიკზე დასამატებლად არ არის განკუთვნილი. TradingView-ის ცნობარი ამას პირდაპირ ამბობს: ბიბლიოთეკებს გრაფიკზე დასადებად არ იყენებენ; მათი იმპორტი სხვა სკრიპტის წერისას ხდება. ტექნიკურად კოდი გრაფიკზე მაინც ჩვეულებრივი ინდიკატორივით სრულდება და ამას გამოქვეყნებამდე სუფთა გრაფიკის მოსამზადებლად იყენებენ.

კიდევ ერთი წვრილმანი, რომელიც მოგვიანებით იჩენს თავს: თავად ბიბლიოთეკა ალერტებს არ ქმნის. მას შეუძლია ექსპორტირებული ფუნქციის შიგნით alert() გამოიძახოს, ალერტს კი უკვე ის სკრიპტი შექმნის, რომელმაც ეს ფუნქცია გამოიძახა.

როგორ შევქმნათ ბიბლიოთეკა: ფუნქციიდან export-ამდე

ენის მეექვსე ვერსიაში ბიბლიოთეკის ჩონჩხი ასე გამოიყურება:

//@version=6
// @description მოკლე აღწერა, თუ რა ინახება აქ
library("My_Tools", overlay = true)

export myEma(int x) =>
    ta.ema(close, length = x)

library() დეკლარაციას ზუსტად სამი პარამეტრი აქვს: title, overlay და dynamic_requests. პირველი სავალდებულოა და იმპორტისას იდენტიფიკატორადაც გამოიყენება. მეორე განსაზღვრავს, მოხვდება თუ არა გამოსახულება გრაფიკის ძირითად პანელზე; ნაგულისხმევად — არა. მესამე დინამიკურ მოთხოვნებს რთავს და მეექვსე ვერსიაში ნაგულისხმევად ჩართულია, მაშინ როდესაც მეხუთეში გამორთული იყო.

მხოლოდ ფუნქციების ექსპორტი არ არის შესაძლებელი. სიაში ასევე შედის მეთოდები, მომხმარებლის ტიპები, enum და მუდმივი ცვლადები. მუდმივები ენას სხვებზე გვიან, 2025 წლის ივნისში დაემატა და მათ საკუთარი პირობა აქვთ: ტიპი შეიძლება იყოს მხოლოდ int, float, bool, color ან string, ხოლო დეკლარაციაში სიტყვა const სავალდებულოა.

ტიპებსა და enum-ს ერთი არაცხადი წესი აქვს. თუ ექსპორტირებული ფუნქცია თქვენი ტიპის ობიექტს იღებს ან აბრუნებს, თავად ტიპიც აუცილებლად ექსპორტირებული უნდა იყოს. იგივე ვრცელდება შემთხვევაზე, როდესაც ერთი ექსპორტირებული ტიპის ველი მეორე ტიპს იყენებს. მაგრამ თუ ტიპი მხოლოდ ბიბლიოთეკის შიდა მუშაობისთვისაა საჭირო, მისი გარეთ გატანა საჭირო არ არის.

ცარიელი ბიბლიოთეკა არ დაკომპილირდება. კომპილაციის გასავლელად გარეთ ერთი სახელი მაინც უნდა გადიოდეს: ფუნქცია, მეთოდი, ტიპი ან enum.

რედაქტორის გახსნა, მონახაზის შენახვა და სკრიპტის გრაფიკზე დამატება ცალკე მექანიკაა, რომელიც დეტალურადაა განხილული სტატიაში Pine Script-ის რედაქტორის შესახებ.

რატომ არის ექსპორტირებული ფუნქციის პარამეტრების ტიპები სავალდებულო?

დოკუმენტაციის ფორმულირება არჩევანს არ ტოვებს: პარამეტრის ტიპის მითითება სავალდებულოა, განსხვავებით ინდიკატორებისა და სტრატეგიების მომხმარებლის ფუნქციებისგან, სადაც ტიპებს არ წერენ. მიზეზი პრაქტიკულია. ფუნქციას სხვა ადამიანები იყენებენ და კომპილატორმა მისი კონტრაქტი წინასწარ უნდა იცოდეს.

ტიპის გარდა პარამეტრს კვალიფიკატორიც შეიძლება ჰქონდეს და აქ არჩევანი მხოლოდ ორ სიტყვას შორისაა: simple და series. სიტყვა const ექსპორტირებულ ფუნქციაში დაუშვებელია; ის მხოლოდ ჩვეულებრივი, არაექსპორტირებული ფუნქციებისთვისაა ხელმისაწვდომი.

არგუმენტები ნაგულისხმევად series სახით მოდის, თუ simple აშკარად არ მიუთითეთ. ამასთან, კომპილატორი აკვირდება, როგორ გამოიყენება პარამეტრი ფუნქციის შიგნით და კვალიფიკატორს თავად არჩევს. აქედან ჩნდება ყველაზე გავრცელებული ხაფანგი, რომელსაც დოკუმენტაცია ძალიან მარტივი მაგალითით აჩვენებს. ავიღოთ ფუნქცია:

export myEma(int x) =>
    ta.ema(close, length = x)

პარამეტრი x სიგრძის არგუმენტში გადადის, ხოლო მოძრავი საშუალოს სიგრძე მარტივი მნიშვნელობა უნდა იყოს. შესაბამისად, x ავტომატურად იღებს კვალიფიკატორს simple. გამოძახება myEma(x = 20) უპრობლემოდ დაკომპილირდება, ხოლო myEma(x = bar_index) კომპილაციის შეცდომას გამოიწვევს: bar_index თითოეულ ბარზე იცვლება, ანუ სერიაა. აქ არაფერია მისტიკური — ფუნქციის კონტრაქტი უბრალოდ იმაზე მკაცრი აღმოჩნდა, ვიდრე კოდში ჩანდა.

საპირისპირო შემთხვევაც არსებობს. თუ გსურთ, რომ ფუნქციამ სერიის ნაცვლად მარტივი მნიშვნელობა დააბრუნოს, უნდა აკონტროლოთ, რომ მის შიგნით არცერთი სერიული მნიშვნელობა არ აღმოჩნდეს. ერთიც საკმარისია, რომ შედეგი სერიად იქცეს.

რისი გაკეთება არ შეიძლება ექსპორტირებული ფუნქციის შიგნით?

დოკუმენტაცია შეზღუდვების ამომწურავ სიას გვაძლევს და ღირს, ერთხელ მთლიანად წაიკითხოთ, რათა შემდეგ გამოცნობა არ დაგჭირდეთ.

პირველი. ბიბლიოთეკის გლობალური არის ცვლადების გამოყენება არ შეიძლება, გარდა მუდმივებად გამოცხადებული ცვლადებისა. პარამეტრებიდან მიღებული მნიშვნელობა ან გლობალურად შექმნილი მასივი ექსპორტირებული ფუნქციის შიგნით მიუწვდომელია.

მეორე. input ოჯახის ფუნქციების გამოძახება არ შეიძლება. პარამეტრები მომხმარებელ სკრიპტში უნდა იყოს და არა ბიბლიოთეკაში. ეს სწორიცაა: სხვაგვარად ერთი ბიბლიოთეკა ინტერფეისს უკარნახებდა ყველა სკრიპტს, რომელიც მას დააკავშირებდა.

მესამე. ლოკალურ არეში request.*() მოთხოვნები დაშვებულია, სანამ პარამეტრი dynamic_requests ხელით გამორთული არ არის. თუმცა მათ საკუთარი პირობა აქვთ: არგუმენტი expression თქვენი ფუნქციის პარამეტრებზე დამოკიდებული ვერ იქნება. ტიკერი და ტაიმფრეიმი შეიძლება იყოს დამოკიდებული, თავად გამოსახულება კი — არა.

მეოთხე. ფუნქციის შიგნით alert() დაშვებულია, მაგრამ ალერტს მხოლოდ ის შექმნის, ვინც ეს ფუნქცია გამოიძახა. უშუალოდ გრაფიკზე დამატებული ბიბლიოთეკიდან ალერტის შექმნა შეუძლებელია.

მეხუთე. ბიბლიოთეკის ფუნქცია ყოველთვის simple-ს ან series-ს აბრუნებს; უფრო სუსტი კვალიფიკატორი არ არსებობს. ამიტომ მისი შედეგის იქ ჩასმა შეუძლებელია, სადაც მუდმივს ელიან. კლასიკური მაგალითი: show_last პარამეტრი plot()-ში მოითხოვს input int ან const int ტიპის მნიშვნელობას და ბიბლიოთეკიდან მისი დაბრუნება ვერ მოხერხდება.

ამას ენის ორი საერთო წესიც ემატება, რომლებიც ხშირად ავიწყდებათ. plot()-ის გამოძახება მხოლოდ გლობალურ არეში შეიძლება, ანუ ის საერთოდ ვერ იქნება რომელიმე ფუნქციის შიგნით. მომხმარებლის ფუნქციებში რეკურსიაც აკრძალულია — ფუნქცია საკუთარ თავს ვერ გამოიძახებს.

როგორ გამოვაქვეყნოთ ბიბლიოთეკა და ვინ დაინახავს მას?

სანამ ბიბლიოთეკა გამოქვეყნებული არ არის, მისი იმპორტი შეუძლებელია. აქ „რედაქტორში შევინახე და დავაკავშირე“ ვარიანტი არ არსებობს.

პირად და საჯარო პუბლიკაციას შორის არჩევანი იმაზეა დამოკიდებული, ვის იწვევთ. პირადი პუბლიკაცია საზოგადოების ლენტაში არ ხვდება და ძიებით არ იძებნება, ხოლო ვიჯეტი მხოლოდ თქვენს პროფილში ჩანს. მაგრამ არსებობს მნიშვნელოვანი დეტალი, რომელსაც ხშირად არასწორად აღწერენ: პირადი პუბლიკაციის გვერდი პირდაპირი ბმულით ყველასთვის იხსნება, ვისაც ეს ბმული აქვს. ეს სეიფი კი არა, ძიებისგან დამალული ვიტრინაა.

თავსებადობის წესები ერთხელ უნდა დაიმახსოვროთ. საჯარო სკრიპტს მხოლოდ საჯარო ბიბლიოთეკების გამოყენება შეუძლია და თავადაც ღია უნდა იყოს. პირად სკრიპტებსა და რედაქტორში შენახულ მონახაზებს როგორც საჯარო, ისე პირადი ბიბლიოთეკების გამოყენება შეუძლიათ. ამასთან, საჯარო დახურულ სკრიპტში — protected ან invite-only — პირადი ბიბლიოთეკის გამოყენება დასაშვებია.

ამ ორ ვარიანტში ჩასწორების უფლება განსხვავებულია. პირადი პუბლიკაციის შეცვლა და წაშლა ავტორს ყოველთვის შეუძლია. საჯარო პუბლიკაციისთვის მხოლოდ თხუთმეტი წუთია გამოყოფილი, რის შემდეგაც ის საბოლოოდ ფიქსირდება. ამიტომ საჯარო ბიბლიოთეკის აღწერაში არ წერენ ისეთ რამეს, რაც მალე მოძველდება.

სხვის კოდთან დაკავშირებით პლატფორმის წესები მკაფიოა: ბიბლიოთეკები საზოგადოებრივ საკუთრებადაა მიჩნეული. მათი ფუნქციების გამოძახება და კოდის ღია სკრიპტში ხელახლა გამოყენება ავტორის ნებართვის გარეშე შეიძლება. თუმცა მათი კოდის დახურულ პუბლიკაციაში გადატანა პირდაპირი თანხმობის გარეშე დაუშვებელია. ორივე შემთხვევაში ავტორი აღწერაში უნდა მიუთითოთ. თუ ავტორს საწყის კოდში სხვა რამ არ დაუწერია, ღია კოდი ნაგულისხმევად Mozilla Public License 2.0 ლიცენზიით ვრცელდება.

ტარიფებზეც ვთქვათ, რადგან საკითხი ფულს ეხება. Basic ტარიფზე საჯარო პუბლიკაციები საერთოდ არ არის ხელმისაწვდომი, პირადი კი ხელმისაწვდომია. საჯარო პუბლიკაციებისთვის სიხშირის ლიმიტები მოქმედებს: მოძრავი დღე-ღამის განმავლობაში მაქსიმუმ ხუთი და ოცდაათი დღის განმავლობაში მაქსიმუმ თხუთმეტი. ეს ლიმიტები პირად პუბლიკაციებსა და უკვე გამოქვეყნებული სკრიპტების განახლებებზე არ ვრცელდება.

როგორ შემოვიტანოთ ბიბლიოთეკა და რისთვის გვჭირდება alias?

სინტაქსი ასეთია:

//@version=6
indicator("Using AllTimeHighLow library", "", true)
import PineCoders/AllTimeHighLow/1 as allTime

plot(allTime.hi())
plot(allTime.lo())

სამნაწილიანი მისამართი ზუსტად განსაზღვრავს, რა დააკავშირეთ. აქ არის ერთი ხაფანგი, რომელსაც ხშირად აწყდებიან: იმპორტში იწერება ბიბლიოთეკის დეკლარაციიდან აღებული title და არა ავტორის მიერ პუბლიკაციისთვის მოფიქრებული სათაური. ხშირად ეს სხვადასხვა სტრიქონია.

as-ის შემდეგ მითითებული ფსევდონიმი სახელთა სივრცეს განსაზღვრავს. as allTime-ის შემთხვევაში ფუნქციებს ასე იძახებენ: allTime.hi(). თუ ფსევდონიმს არ მიუთითებთ, სახელთა სივრცედ თავად ბიბლიოთეკის სახელი იქცევა. იგივე წერტილოვანი ჩანაწერით ბიბლიოთეკის ტიპები და enum-იც ხელმისაწვდომია.

იმპორტთან დაკავშირებული რამდენიმე წესი, რომლებიც უმჯობესია თავიდანვე დაიმახსოვროთ:

• მისამართში ვერსიის ნომერი ყოველთვის პირდაპირ იწერება; ამ სტრიქონში მნიშვნელობა „უახლესი“ არ არსებობს.
• საჯარო სკრიპტს მხოლოდ საჯარო ბიბლიოთეკების დაკავშირება შეუძლია და თავადაც ღია უნდა იყოს.
• პირადი ბიბლიოთეკა გამოდგება პირადი სკრიპტისთვის, რედაქტორში შენახული მონახაზისა და დახურული კოდის მქონე საჯარო სკრიპტისთვის.

დაკავშირებული ბიბლიოთეკების რაოდენობა პირდაპირ შეზღუდული არ არის; შეზღუდულია კოდის საერთო მოცულობა. ამის შესახებ ქვემოთ, რისკების განყოფილებაში ვისაუბრებთ.

რატომ არ გადადის იმპორტი ახალ ვერსიაზე ავტომატურად?

დოკუმენტაციის ფორმულირება პირდაპირია: ბიბლიოთეკების მომხმარებელი სკრიპტების საიმედოდ მუშაობისთვის უახლესი ვერსიის ავტომატურად მიღება შეუძლებელია. ყოველ ჯერზე, როდესაც ავტორი განახლებას აქვეყნებს, ბიბლიოთეკის ვერსიის ნომერი იზრდება. თუ ახალი ვერსია გსურთ, import სტრიქონში რიცხვი ხელით შეცვალეთ.

ეს შეიძლება მოუხერხებლად ჟღერდეს, მაგრამ სინამდვილეში დაზღვევაა. წარმოიდგინეთ საპირისპირო: სხვისი ბიბლიოთეკის ავტორმა საკუთარ კოდში ფორმულა შეცვალა და დილით თქვენი ინდიკატორი უკვე სხვა სიგნალებს ხატავს, მიუხედავად იმისა, რომ მას არ შეხებიხართ. პლატფორმა სწორედ ამას არ უშვებს.

პრაქტიკული დასკვნა: ვერსიის ნომრის შეცვლა თქვენი სკრიპტის ქცევის ცვლილებაა და არა კოსმეტიკური შესწორება. ამის შემდეგ სიგნალები თავიდან უნდა გადაამოწმოთ: იმავე ინსტრუმენტზე გაუშვათ ბექტესტი და ინდიკატორი შეამოწმოთ ისტორიული მნიშვნელობების შემდგომ ცვლილებაზე — repainting-ზე, ზუსტად ისე, როგორც ლოგიკის ნებისმიერი ცვლილებისას აკეთებთ. ძველი და ახალი შედეგების დამთხვევას არავინ გაძლევთ გარანტიად.

სად ვიპოვოთ აქტუალური ნომერი. გამოქვეყნებული ბიბლიოთეკის გვერდზე მზა იმპორტის სტრიქონის ბუფერში კოპირების ღილაკია — ეს ყველაზე სწრაფი გზაა. მეორე ვარიანტი მათთვისაა, ვინც ხელით წერს: რედაქტორში ავტორის სახელის მიხედვით ავტომატური შევსება მუშაობს და ხელმისაწვდომ ბიბლიოთეკებს გაჩვენებთ.

როგორ გამოვუშვათ ვერსიები ისე, რომ სხვისი სკრიპტები არ გავაფუჭოთ?

Pine Script-ის ბიბლიოთეკები მექანიკურად ინომრება: პლატფორმა ნომრის მნიშვნელობაზე არაფერს ამბობს და განახლების ყოველი გამოქვეყნებისას მას უბრალოდ ზრდის. შესაბამისად, დისციპლინა თავად უნდა დაიცვათ და აქ ყველაზე მარტივია მეზობელი ეკოსისტემების მზა მიდგომის გამოყენება.

Semantic Versioning-ის სპეციფიკაცია იმ წესს აყალიბებს, რომლის გამოც მისი გაცნობა ღირს: გამოშვებული ვერსია არ იცვლება, ნებისმიერი ცვლილება ახალი გამოშვებით ქვეყნდება. TradingView-ზე ეს პირდაპირი მნიშვნელობით მუშაობს, რადგან პუბლიკაცია საწყისი კოდის დამოუკიდებელ ასლს ქმნის და ის ვერსიების ისტორიის ნაწილი ხდება.

რომელი ცვლილება არღვევს თავსებადობას, მოსახერხებელია Cargo-ს დოკუმენტაციის მიხედვით განვსაზღვროთ: საჯარო ელემენტის წაშლა თავსებადობას არღვევს, ფუნქციისთვის ახალი სავალდებულო პარამეტრის დამატებაც, ხოლო ახალი საჯარო ელემენტის დამატება თავსებადია. Pine Script-ზე ეს პირდაპირ გადადის. თუ ბიბლიოთეკაში ახალი ექსპორტირებული ფუნქცია დაამატეთ, ძველი მომხმარებლები ვერაფერს შეამჩნევენ. თუ არსებულ ფუნქციას სავალდებულო არგუმენტი დაუმატეთ, ყველა ძველი წესით გაკეთებული გამოძახება გატყდება.

npm-ის დოკუმენტაცია რიცხვებთან დაკავშირებით ძალიან მარტივ წესს გვთავაზობს: პირველი გამოშვება — 1.0.0, შესწორება — 1.0.1, თავსებადი სიახლე — 1.1.0, თავსებადობის დამრღვევი ცვლილება — 2.0.0. თუმცა სამართლიანობისთვის თავიდანვე უნდა ითქვას ისიც, რასაც Python-ის პაკეტების სახელმძღვანელო ამბობს: პრაქტიკაში მკაცრ semver-ს ყველა არ იცავს და საბოლოოდ ნომერი ავტორის შეფასებად რჩება.

ცალკე უნდა ითქვას აღწერაზეც. რადგან საჯარო პუბლიკაციის შეცვლა თხუთმეტი წუთის შემდეგ შეუძლებელია, ცვლილებების ისტორიის დისციპლინირებულად წარმოება თავიდანვე ღირს. აქ Keep a Changelog-ის მიდგომა გამოგადგებათ: ცვლილებების სია ადამიანებისთვის იწერება, თითოეულ ვერსიას კი საკუთარი ჩანაწერი აქვს თარიღითა და გასაგები პუნქტებით. სხვაგვარად ერთი წლის შემდეგ თავადაც ვეღარ გაიხსენებთ, რით განსხვავდებოდა მესამე ვერსია მეორისგან.

რა შეიცვალა ბიბლიოთეკებში Pine Script v6-ის გამოსვლის შემდეგ?

მეექვსე ვერსიამდე ექსპორტირებული ფუნქციის შიგნით მონაცემთა მოთხოვნა აკრძალული იყო, თუ ავტორი დინამიკურ მოთხოვნებს ხელით არ ჩართავდა. 2024 წლის ნოემბერში, v6-ის გამოსვლასთან ერთად, ეს შეიცვალა: request.*() გამოძახებები ციკლების, პირობითი კონსტრუქციებისა და ბიბლიოთეკების ექსპორტირებული ფუნქციების შიგნით დაუშვეს.

ამასთან, ნაგულისხმევი მნიშვნელობაც შეიცვალა. მეხუთე ვერსიაში dynamic_requests გამორთული იყო, მეექვსეში კი ჩართულია. ძველი კოდის გადატანისას ამის გამო ხაფანგში ებმებიან: თუ დეკლარაციაში აშკარად მითითებული dynamic_requests = false დარჩა, ლოკალური არიდან მოთხოვნის გამოძახება აიკრძალება, მაშინაც კი, თუ ის მომხმარებლის ფუნქციის შიგნითაა დამალული. მიგრაციის სახელმძღვანელო მარტივ გამოსავალს გვთავაზობს: კონვერტაციისას აშკარად მითითებული პარამეტრი უბრალოდ წაშალეთ და გადაწყვეტილება კომპილატორს მიანდეთ.

თუ თქვენი ფუნქციებისგან არა უბრალოდ დამხმარე ფუნქციების ნაკრებს, არამედ მოქმედ ალგორითმს ქმნით, შემდეგ ზოგადი შემოწმების ჩარჩო გამოგადგებათ: როგორ არის მოწყობილი ალგოტრეიდინგი და როგორ ამოწმებენ ალგორითმს, სანამ მას გადაწყვეტილებებს ანდობენ.

რისკები და შეზღუდვები

მოცულობის შესახებ. ერთი სკრიპტის დაკომპილირებული ფორმა დაახლოებით ასი ათასი ტოკენითაა შეზღუდული; ზუსტი რიცხვია 100 256. ბიბლიოთეკები ცალკე კომპილირდება და მათი კოდი თქვენი ინდიკატორის ზომას არ ზრდის. სამაგიეროდ, ყველა დაკავშირებული ბიბლიოთეკის საერთო მოცულობა მილიონი ტოკენითაა შეზღუდული, ხოლო თავად კომპილაციის მოთხოვნა ხუთ მეგაბაიტს არ უნდა აღემატებოდეს.

აქედან გამომდინარეობს უსიამოვნო თავისებურება, რომელიც წინასწარ უნდა იცოდეთ: კომპილაციისთვის ბიბლიოთეკა მთლიანად იგზავნება, მიუხედავად იმისა, რამდენი ფუნქცია გამოიძახეთ მისგან. უზარმაზარი ნაკრებიდან ერთი პატარა ფუნქციაც კი მთელ ნაკრებს თან მოიყოლებს. დასკვნა მარტივია: უმჯობესია ბიბლიოთეკები კომპაქტური და თემატურად დაყოფილი იყოს, ნაცვლად იმისა, რომ ყველაფერი ერთში ჩაყაროთ.

კიდევ ერთი მსგავსი წვრილმანი: იმპორტირებული ფუნქციების შიგნით არსებული request.*() მოთხოვნები თქვენს მოთხოვნათა ლიმიტში ითვლება, მაშინაც კი, თუ ზუსტად იგივე არგუმენტების მქონე მოთხოვნა სკრიპტის ძირითად კოდში უკვე არსებობს.

დამოკიდებულების შესახებ. სხვისი ბიბლიოთეკის დაკავშირებისას გამოთვლებთან დაკავშირებულ სხვის გადაწყვეტილებებს იღებთ. თუ ავტორი ახალ ვერსიას გამოუშვებს, თავად გადასვლამდე მას ვერ მიიღებთ და ეს კარგია. თუმცა საპირისპიროც მართებულია: თუ ძველ ვერსიაში შეცდომაა, ის თქვენთან დარჩება, სანამ ხელით არ განაახლებთ.

კონფიდენციალურობის შესახებ. გავიმეოროთ ზემოთ ნათქვამი, რადგან ამ საკითხზე ხშირად ცდებიან: პირადი პუბლიკაცია ლენტისა და ძიებისგან დამალულია, მაგრამ პირდაპირი ბმულით იხსნება. კოდი, რომლის ჩვენებაც არავისთვის შეიძლება, ბიბლიოთეკაში საერთოდ არ უნდა გაიტანოთ.

ავტორობის შესახებ. საკუთარი პუბლიკაციის აღწერაში სხვისი ბიბლიოთეკის ავტორის მითითება თავაზიანობა კი არა, პლატფორმის წესების მოთხოვნაა. პლაგიატისთვის წესები ანგარიშის სამუდამო დაბლოკვასაც ითვალისწინებს, ამიტომ ავტორის მითითება დაზღვევაცაა.

და გულწრფელი შენიშვნა ამ სტატიის შესახებ. ოფიციალურ დოკუმენტაციაში არ არის მოყვანილი კომპილაციის შეცდომების ზუსტი ტექსტები ისეთი შემთხვევებისთვის, როგორებიცაა პარამეტრის გამოტოვებული ტიპი ან ექსპორტირებული ფუნქციის შიგნით input-ის გამოძახება: იქ თავად აკრძალვებია აღწერილი. ამიტომ, თუ კომპილატორმა შეცდომა გაჩვენათ, შეზღუდვების სიას შეადარეთ და არა სხვის გადმოცემებს.