Julia: مراجعة اتساق API

نعتذر إذا لم يكن هذا هو المكان المناسب لذكر ذلك ، ولكن سيكون من الجيد أن تكون أكثر اتساقًا مع الشرطة السفلية في أسماء الوظائف من الآن فصاعدًا.

لا ، هذا مكان جيد لذلك. ونعم ، يجب أن نسعى جاهدين لإزالة جميع الأسماء التي تكون فيها الشرطة السفلية ضرورية :)

• معالجة متسقة لـ "حساب عبر هذا [هذه] الأبعاد [الأبعاد]" وسيطات الإدخال ، وما هي الأنواع المسموح بها وما إلى ذلك ، ضع في اعتبارك ما إذا كان القيام بذلك باعتباره وسيطات الكلمات الرئيسية قد يكون مرغوبًا
• سرد وترتيب أولويات اصطلاحات ما يأتي أولاً من حيث حجج الوظيفة لكتل ​​الفعل ، وحجج الإدخال / الإخراج للوظائف التي تطبع ، ومخرجات الوظائف الموضعية ، وما إلى ذلك (تحرير: يعتقد أنه قد يكون هناك بالفعل واحد مفتوح لهذا)

للحصول على نقطةtkelman الثانية ، راجع https://github.com/JuliaLang/julia/issues/19150

كان هناك أيضًا Julep مؤخرًا بخصوص API لـ find والوظائف ذات الصلة: https://github.com/JuliaLang/Juleps/blob/master/Find.md

هل يجب علينا إهمال القنوات put! و take! (وربما نفعل الشيء نفسه للعقود الآجلة) نظرًا لأن لدينا push! و shift! عليها؟ أقترح فقط إزالة كلمتين مكررتين في واجهة برمجة التطبيقات.

أشك في أن يكون shift! سهل الاستخدام. المرشح هو fetch! لدينا بالفعل fetch وهو الإصدار غير المتحول من take!

المرجع # 13538 # 12469

تضمين التغريدة

تحرير: من المنطقي إعادة استخدام send و recv على القنوات. (أنا مندهش من أن هذه تستخدم فقط لـ UDPSockets في الوقت الحالي)

+1 لاستبدال put! / take! بـ push! / fetch!

سأضيف إعادة تسمية @inferred إلى @test_inferred .

تحقق جيدًا من أن التخصصات متوافقة مع الوظائف الأكثر عمومية ، أي أنها ليست شيئًا مثل # 20233.

راجع جميع الوظائف التي تم تصديرها للتحقق مما إذا كان يمكن التخلص من أي منها عن طريق استبدالها بإرسالات متعددة ، على سبيل المثال print_with_color

الاقتران النموذجي هو push! و shift! عند العمل مع بنية بيانات تشبه قائمة الانتظار.

إذا لم نكن سنستخدم اقتران الاسم النموذجي لهذا النوع من بنية البيانات لأننا قلقون من أن تتضمن العملية اتصالاً لا يتم نقله بشكل كافٍ بواسطة هذه الأسماء ، فأنا لا أعتقد أن push! المنطقي أيضًا. send و recv أفضل حقًا.

ربما تحقق جيدًا من وجود اتساق عام بين ما إذا كانت الدوال تأخذ tuple كوسيطة أخيرة أو vararg.

ربما تكون كبيرة جدًا بالنسبة لهذه المشكلة ، ولكن سيكون من الجيد وجود قواعد متسقة بشأن الوقت الذي يجب أن تتسبب فيه الوظائف في حدوث أخطاء ، ومتى يجب أن تُرجع Nullable s أو Union s (على سبيل المثال parse / tryparse ، match ، إلخ.)

لا توجد مشكلة كبيرة جدًا ، @ simonbyrne - هذه قائمة الغسيل.

راجع للشغل: هذا ليس حقًا لتغييرات محددة (مثل إعادة تسمية وظائف معينة) - إنه يتعلق أكثر بأنواع الأشياء التي يمكننا مراجعتها. بالنسبة للتغييرات المقترحة المحددة ، ما عليك سوى فتح مشكلة تقترح هذا التغيير.

لدينا الكثير من الأدوات مثل code_xxx المقترنة بالوظائف الأساسية مثل code_xxx

لست متأكدًا مما إذا كان هذا هو ما تتحدث عنه ، ولكن راجع CreateMacrosFrom.jl

• ما إذا كان يجب أن تكون واجهات برمجة التطبيقات "نوع الإخراج" من حيث نوع العنصر أو نوع الحاوية الإجمالي (المرجع # 11557 و # 16740)

• توثيق جميع الوظائف التي تم تصديرها (بما في ذلك العقيدة)

توثيق جميع الوظائف التي تم تصديرها (بما في ذلك العقيدة)

إذا كان هذا جزءًا من هذا ، فربما أيضًا: تذكر تسمية اختباراتك برقم المشكلة / العلاقات العامة. إنه يسهل كثيرًا فهم سبب وجود هذا الاختبار. أعرف كيف يعمل git blame ، ولكن عند إضافة مجموعات الاختبارات (فقط لإعطاء مثال) ، يكون الأمر في بعض الأحيان غامضًا بعض الشيء الذي يتم اختباره ، وسيكون من الرائع أن يكون رقم المشكلة / العلاقات العامة موجودًا دائمًا.

dpsanders : وتصدير وحدات الماكرو! على سبيل المثال ، لا يحتوي @fastmath على سلسلة مستندات.

هذا بسيط للغاية ، لكن الدالتين string و Symbol تقومان بنفس الشيء تقريبًا ولها أحرف مختلفة. أعتقد أن symbol سيكون أكثر منطقية.

amellnik الفرق هو أن Symbol مُنشئ نوع و string دالة عادية. اعتدنا أن يكون لدينا IIRC symbol ولكن تم إهماله لصالح مُنشئ النوع. لست مقتنعًا بأن التغيير ضروري لهذا ، ولكن إذا كان هناك أي شيء أعتقد أنه يجب علينا استخدام مُنشئ String بدلاً من string .

إذا كان هناك أي شيء أعتقد أنه يجب علينا استخدام مُنشئ String بدلاً من السلسلة النصية.

لا ، إنها وظائف مختلفة ولا ينبغي دمجها

julia> String(UInt8[])
""

julia> string(UInt8[])
"UInt8[]"

لا ، إنها وظائف مختلفة ولا ينبغي دمجها

يبدو هذا وكأنه موقف حيث يجب فقط إهمال string(args...) لصالح sprint(print, args...) ، إذن - وجود كل من string و String أمر محير. يمكننا التخصص في sprint(::typeof(print), args...) لاستعادة أي أداء مفقود. على طول هذه الأسطر ، قد يكون من المنطقي أيضًا إهمال repr(x) مقابل sprint(showall, args...) .

يبدو هذا جيدًا على الرغم من أن استدعاء string لتحويل شيء ما إلى سلسلة يبدو عاديًا جدًا ....

سلسلة استدعاء لتحويل شيء ما إلى سلسلة تبدو قياسية جدًا

نعم ، ولكن هذا هو المكان الذي يأتي فيه قطع الاتصال بين String و string .

sprint(print, ...) زائدة عن الحاجة. إذا تخلصنا من string ، فيمكننا إعادة تسمية sprint إلى string حتى نحصل على string(print, foo) و string(showall, foo) وهو ما يقرأ جيدًا في رأيي .

قد تكون هذه حالة يكون فيها الاتساق مبالغًا فيه. أعتقد أنه من الجيد أن يكون لديك string(x) مقابل "أعطني تمثيل سلسلة لـ x". إذا كان الأمر أكثر تعقيدًا من ذلك ، مثل مطالبتك بتحديد وظيفة الطباعة المراد استخدامها ، فإن استخدام اسم آخر مثل sprint أمر منطقي.

سيكون من المقبول أيضًا إعادة تسمية String(UInt8[]) إلى شيء آخر ، واستخدام String بدلاً من string . يمنحنا string مزيدًا من المرونة في المستقبل لتغيير نوع السلسلة التي نعيدها ، ولكن لا يبدو أن هذا يحدث على الأرجح.

هل reinterpret(String, ::Vector{UInt8} منطقي على الإطلاق ، أم أن هذا تورية على reinterpret ؟

يبدو أن هذا منطقي.

المشكلة هي أن هذه الوظيفة يتم نسخها في بعض الأحيان ، لذا فإن هذا الاسم مضلل إلى حد ما.

صحيح ، لكن من المفترض أن تكون الأوتار غير قابلة للتغيير ، لذا يمكننا على الأرجح التخلص من ذلك.

هناك أيضًا طريقة String(::IOBuffer) ، ولكن يبدو أنه يمكن إهمالها إلى readstring .

لقد فكرت في تغيير API المقترح أيضًا ، ولكن واجهة string(a, b...) هي أنها تقوم بترتيب وتوصيل وسيطاتها ، وهذا من شأنه أن يجعل استثناء مسكتك مزعجًا للوسيطات الأولى القابلة للاستدعاء. إذا أزلنا التسلسل من string فيمكن جعله يعمل.

نعم ، موافق ؛ الاتساق وتجنب المسك هو الأهم.

تدوين المشكلات # 18326 و # 3893 في فئة "وسيطات الأبعاد".

إذا كان بإمكاني معالجة عنصر آخر: التأكد من أن سلوك حاويات المتغيرات موثق ومتسق.

@ JaredCrean2 : هل يمكنك توضيح ما تعنيه بذلك؟

آمل بالتأكيد ألا يتضمن ذلك عمل الكثير من "النسخ الدفاعية".

على سبيل المثال ، إذا كان لدي مصفوفة من الأنواع القابلة للتغيير وقمت باستدعاء sort عليها ، فهل تشير المصفوفة المرتجعة إلى نفس الكائنات مثل مصفوفة الإدخال ، أم أنها تنسخ الكائنات وتجعل المصفوفة المرتجعة تشير إلى معهم؟

نفس الأشياء. أنا متأكد من أن جميع طرق الفرز ، getindex ، التصفية ، البحث ، إلخ. تتبع هذه القاعدة ، أليس كذلك؟

لا أعتقد أن هناك أي نقص في الوضوح أو الاتساق في هذه النقطة - إنها دائمًا نفس الأشياء.

في الواقع ، أعتقد أن الوظيفة القياسية الوحيدة التي لم يكن الأمر كذلك فيها هي deepcopy حيث أن بيت القصيد هو أنك تحصل على جميع الكائنات الجديدة.

هل هذا موثق في مكان ما؟

لا - يمكننا ولكن لست متأكدًا من المكان الأفضل لتوثيقه. لماذا تقوم الدوال بعمل نسخ غير ضرورية؟ من أين لك انطباع بأنهم قد يفعلون ذلك؟

مرحبا. لم أر أنا أصدق أي ملاحظات حول تسلسل البيانات.

قريباً أو لاحقًا ، سيتم كتابة برامج جوليا وتشغيلها علنًا ، وستبدأ البيانات في التقسيم الطبقي أحيانًا ، لسنوات. تسلسل البيانات على سبيل المثال. السلسلة: يجب بناء الكائن إلى بايت مدفوع بالنوع (ربما أكثر من json أو ...) ليكون مرنًا للوقت. قد يكون التفكير في الإصدار الدلالي وواجهة برمجة تطبيقات الويب أمرًا مهمًا أيضًا.

هل يمكننا توقع بقاء التسلسل لبيانات المستخدم بالقرب من https://github.com/JuliaLang/julia/blob/v0.5.1/base/serialize.jl ؟

لماذا تقوم الدوال بعمل نسخ غير ضرورية؟ من أين لك انطباع بأنهم قد يفعلون ذلك؟

لا أعرف ما إذا كانوا يعرفون أم لا. بقدر ما أستطيع أن أقول ، السلوك غير محدد. من تعليق JeffBezanson ، هناك أشخاص يؤيدون عمل نسخ دفاعية ، وهو ما يعارضه. لذا يجب أن تتناول الوثائق مسألة النسخ الدفاعية في مكان ما.

يبدو أنك تشير إلى نوع من مبدأ أقل الإجراءات ، ولكن اعتمادًا على تفاصيل الخوارزمية ، فإن ما هو "الإجراء الأقل" يصبح غامضًا. من أجل الحصول على تناسق عبر واجهة برمجة التطبيقات ، أعتقد أن هناك حاجة إلى مزيد من الإرشادات المحددة.

@ o314 : هذه مشكلة تتعلق بمراجعة تناسق واجهة برمجة التطبيقات ، ولست متأكدًا من كيفية ارتباط التسلسل.

@ JaredCrean2 : سواء تم نسخ كائن المستوى الأعلى أم لا ، فمن المؤكد أنه يحتاج إلى توثيق. ما أقوله هو أن الأشياء الأعمق لا يتم نسخها أبدًا ، إلا عن طريق النسخ العميق (من الواضح).

ما أقوله هو أن الأشياء الأعمق لا يتم نسخها أبدًا ، إلا عن طريق النسخ العميق (من الواضح).

دار نقاش حديث حول هذا الأمر في سياق copy لبعض أغلفة المصفوفات ، على سبيل المثال SubArray و SparseMatrixCSC ولكن أيضًا Symmetric ، LowerTriangular . يبدو لي أنه بموجب السياسة المذكورة أعلاه ، سيكون copy بمثابة noop لأنواع الغلاف هذه. هل السياسة التي تذكرها هي المستوى الصحيح من التجريد هنا؟ على سبيل المثال ، أعتقد أنه يعني أنه إذا تم تنفيذ Array s في Julia (تغليف المخزن المؤقت) ، فيجب أن يتغير سلوك copy على Array s إلى noop.

إذا كان العرف هو أن الكائنات الأعمق لا يتم نسخها أبدًا ، فكل ما تبقى هو توثيقها. التوثيق جزء مهم حقًا من واجهة برمجة التطبيقات. قد يبدو هذا السلوك واضحًا لك (ربما لأنك كتبت أجزاءً من الكود) ، لكن من منظور خارجي ليس واضحًا جدًا.

تحرير: لا يرى أندرياس آخر. هذا اعتبار مثير للاهتمام.

StefanKarpinski أتفق مع وجهة نظرك.
وجميع الموضوعات الرئيسية التي تم ذكرها هنا جيدة جدًا وذكية.

لكن في بعض الأحيان أشعر ببعض الخوف فيما يتعلق بالموازنة بين العملية والبيانات في جوليا:

يمكننا استدعاء فورتران أو سي بسهولة بالتأكيد ،
ولكن سيتم نشر الكود بنفس السهولة في مركز البيانات الحديث ، على سبيل المثال. aws lambda بوظيفتها كنمط خدمة. هل يمكن استدعاء الكود بسهولة من خلال الإنترنت ، أو فتح API؟

في بعض الأحيان ، يتعين على المرء أن يخفض الحمل الوظيفي إلى الحجم (لا يوجد عام ، ولا توجد vaargs على توقيع الوظيفة ، ولا يوجد ترتيب عالٍ في api العام) وربط البيانات بشكل أكثر منهجية خلف (مخطط json / openapi).

لقد رأيت بعض مكتبات الثعبان الجيدة تغرق بهذه الطريقة وهذا أمر مؤسف.

أعتقد أنها نقطة مهمة للغة 1.0 للحفاظ على البيانات والوظائف متوازنة ونمطية لتكون قادرة على النشر بسهولة على الويب. ولهذه الوظيفة ، يجب أن تكون واجهة المستخدم أقل من الحيوانات الأليفة وأن تكون موجهة نحو الماشية عند الحاجة.

قد لا يكون هذا هو الهدف في هذا الموضوع.

StefanKarpinski ربما أساء فهم رسالتك. عندما قلت

سواء تم نسخ كائن المستوى الأعلى أم لا ، فمن المؤكد أنه يحتاج إلى توثيق

ماذا يعني "كائن المستوى الأعلى"؟ إذا كان لدي x::Vector{MyMutableType} ، فهل كائن المستوى الأعلى x أم عناصر x ؟

يشير كائن المستوى الأعلى إلى x نفسه ، وليس عناصر x .

andreasnoack يجب أن تشير فكرة كائن المستوى الأعلى إلى الهيكل المجرد المطبق ، وليس إلى تفاصيل التنفيذ.

ربما تضيف float ووظيفة أخرى مماثلة تعمل على كلا النوعين مقابل القيم؟

بالانتقال إلى ملاحظات الإصدار 0.6 ، يبدو من الغريب أن يتم تقديم iszero(A::Array{T}) ، في حين أن العديد من الوظائف الأخرى (مثل sumabs ، isinteger ، isnumber ) فوق المصفوفات هي متوقف لصالح all(f,A) .

لا توجد مصفوفات صفرية ، وهي عبارة عن عناصر صفرية في فضاء المتجه. يختبر iszero بشكل عام ما إذا كان الشيء هو معكوس الجمع أم لا.

إعادة. تناسق الشرطات السفلية في أسماء الوظائف ، إليك مسار تنقل إلى count_ones و count_zeros .

يبدو لي أنه إذا كنت تريد الحفاظ على اتساق واجهة برمجة تطبيقات جوليا باستمرار ، فستحتاج إلى بعض البرامج التي تتيح لك (أ) تحديد قواعد / اصطلاحات واجهة برمجة التطبيقات ، (ب) إجراء تحليل ثابت لرمز جوليا للكشف عن الانحرافات عن تلك القواعد / الاتفاقيات ، و (ج) تقديم الاقتراحات. ستفيد مثل هذه الأداة كلاً من Julia Base وجميع حزم جوليا. قد تؤدي حزمة جوليا الجديدة إلى حل المشكلة. (اللسان في الخد: أول شيء يجب أن تفعله هذه الحزمة هو اقتراح اسمها الخاص ؛ APICheck.jl ، ApiCheck.jl ، API_Check.jl ، APIChecker.jl ، JuliaAPIChecker.jl ، إلخ.) أنا جديد إلى حد ما على Julia ، لذلك لا تريد أن تأخذ زمام المبادرة في مثل هذا الشيء. ومع ذلك ، لا أمانع في المساهمة. أي اقتراحات حول كيفية المضي قدما في هذا؟

نود أن يكون لدينا ذلك في Lint.jl!

num2hex و hex2num (# 22031 و # 22088)

أنا أيضًا أعتقد أن Lint.jl هي الحزمة الصحيحة لفحص تناسق Julia API. ولكن إذا سلكنا هذا الطريق ، فيجب أن تكون قائمة ستيفان الأصلية أكثر دقة. على سبيل المثال ، عندما يكتب "يجب أن نتأكد من أن جميع المجموعات في DataStructures بها واجهات برمجة تطبيقات متسقة" ، فإن الأسئلة التي تتبادر إلى الذهن هي:

• ما الذي يجعل بنية البيانات مجموعة؟ (قائمة المجموعات في القاعدة)
• ما هي الوظائف التي يجب أن تدعمها المجموعة؟ (جدول بيانات الوظائف حسب المجموعات)
• ماذا يجب أن يكون التوقيع على كل من هذه الوظائف؟
• هل واجهات برمجة التطبيقات التي توفرها Base للمجموعات متسقة بالفعل؟

لإدارة مثل هذه المخزونات والتحليلات ، قد نرغب في إضافة مشروع إلى مستودع Julia (المشروع رقم 8) ، أو إلى مستودع JuliaPraxis (اقترحه TotalVerb في وضع عدم الاتصال) أو إلى مستودع Lint. في هذه الحالة ، سنحتاج إلى تحديد من سيمتلك مثل هذا المشروع ، وأي الأشخاص يجب أن يشاركوا من البداية ، ومن يجب أن يتخذ القرارات النهائية بشأن ماهية اتفاقيات جوليا في الواقع (لغرض الفحص).

ولكن قبل المضي قدمًا في هذه الخطوط ، أود أن أسأل

أوافق على أن تحديد هذا على وجه التحديد فكرة جيدة. إن معرفة ما يجب أن تكون عليه هذه القائمة هو جزء من العمل هنا - إذا كنت ترغب في التعامل معها ، فسيكون ذلك رائعًا.

هل نحتاج حقًا إلى Base.datatype_module و Base.function_module؟

تبدو "وحدة" الوظيفة الموحدة (ربما getmodule) التي يتم إرسالها عند نوع البيانات والوظيفة أكثر اتساقًا بالنسبة لي.

ماذا عن الشرطة السفلية في @code_typed والأصدقاء؟

هذه فرصة جيدة لإعادة البناء (السبب المعلن لحظر الشرطة السفلية). يمكن أن يكون لديك ماكرو @code مع كون الوسيطة الأولى هي نوع الكود الذي تريده.

(bramtayl، يرجى تذكر أن وضع backticks حول وحدات الماكرو لأن ذلك الأصوات وجيثب المستخدم "كود" إن لم يكن؛ @code )

FWIW ، يعمل إكمال علامة التبويب مع أسماء الوظائف فقط. أن تكون قادرًا على القيام بـ @code_<TAB> أمر جيد ....

إذا تم النظر في إعادة الهيكلة ولكن تم رفضها ، فإن ما إذا كانت هناك شرطات سفلية أم لا هي موضع نقاش ، لأن النقطة الوحيدة في حظر التسطير السفلي هي تشجيع إعادة البناء. في الواقع ، في هذه الحالة ، يبدو أنه يجب تشجيع الخطوط السفلية لجعل اللغة أكثر وضوحًا

التأكيد على التدقيق.

اقتراح مضاد: ما زلنا نراجع هذه الأسماء ، لكننا بدلاً من ذلك نضيف المزيد من الشرطات السفلية حيث ستجعل قراءة الكود أسهل (codetyped vs code_typed ، isos2 vs is_os2).

أنا لست مطلقة بشأن هذا. أعتقد أن code_typed ما يرام ، ومن المفيد إكمال علامة الجدولة كما يشير KristofferC ، وليس هناك حقًا أي شيء واضح لتمريره كحجة لتحديد الإخراج الذي تريده.

بالنسبة لي ، يبدو أن السفينة قد أبحرت عند إضافة المزيد من الخطوط السفلية ، حيث يتعين علينا إهمال نصف القاعدة بشكل أساسي. على سبيل المثال ، هناك 74 دالة مسند تبدأ بـ is وستة فقط تبدأ بـ is_ . أيهما أكثر منطقية ، يتم إهمال 6 أو 74؟

حسنًا ، هناك عدة أهداف متضاربة هنا:

1) جعل الأسماء أكثر قابلية للقراءة
2) تقليل زخم الشفرة
3) تشجيع إعادة البناء

إزالة الشرطات السفلية عن طريق تصادم الكلمات معًا يفشل على الجبهات الثلاثة.

يبدو أن أساليب show تقبل دفقًا لا تنتهي بـ ! غير متسقة مع الاصطلاح المعتاد؟ المرجع. https://github.com/JuliaLang/julia/pull/22604/commits/db9d70a279763ded5088016d9c3d4439a49e3fca#r125115063. الأفضل! (تحرير: أفترض أن هذا يتطابق مع طرق write تقبل البث.)

هناك تناقضات مع السمات API. يتم حساب بعض السمات عن طريق استدعاء السمة مثل
TypeArithmetic(Float64)
بينما يجب كتابة هذه الوظيفة بأحرف صغيرة أخرى:
iteratorsize(Vector{Float64})

ضع في اعتبارك إعادة تسمية size -> shape (xref # 22665)

Array{T,1}() المحتمل أن يتم إهمال

julia> Array{Int,1}()                                                                                                                  
0-element Array{Int64,1}                                                                                                               

julia> Array{Int,2}()                                                                                                                  
WARNING: Matrix{T}() is deprecated, use Matrix{T}(0, 0) instead.                                                                       

كنت أفكر في المجموعات. لدينا ثلاثة أنواع أساسية:

• مجموعات بسيطة تشبه المجموعات (أو تشبه الحقيبة) ، والتي تحتوي فقط على بعض القيم.
• مجموعات تشبه المصفوفة ، والتي تضيف فهرسًا إلى جانب البيانات.
• مجموعات تشبه Dict ، والتي تحتوي على مؤشرات كجزء من البيانات ، مثل أزواج k=>v .

لقد أصبحت متشككًا في السلوك الشبيه بالديكت. طائر الكناري في منجم الفحم هو map ، حيث لا يكون العمل على أزواج ذات قيمة رئيسية أمرًا طبيعيًا ، نظرًا لأنك عادة لا تريد تغيير مجموعة المفاتيح. من الممكن أيضًا أن تقوم المصفوفات والإملاء بتنفيذ نفس الواجهة:

• keys يتوافق مع eachindex
• mapindexed و filterindexed مفيدًا لكل من المصفوفات والمصفوفات. هذه مثل الخريطة والتصفية باستثناء تمرير الوظيفة الخاصة بك إلى فهرس العنصر المعني.
• يمكن أن تستخدم المصفوفات والإملاءات (والمسمى tuples ، وربما أشياء أخرى) مكررًا pairs ، وهو في الأساس اختصار لـ zip(keys(c), values(c)) .

ضع في اعتبارك إعادة تسمية ind2sub و sub2ind ، وهما عبارة عن matlabisms على ما يبدو ، والتي لها اسم غير جولياني وغريب لمستخدم غير matlab. قد تكون الأسماء المحتملة indice و linearindice على التوالي. لم أجرؤ على إجراء العلاقات العامة لأنني لست متأكدًا مما يعتقده الناس بشأن ذلك ، لكنني سأفعل إذا كان هناك دعم.

نفس الشيء مع rad2deg و deg2rad .

المرجع. # 22791 ( select -> partialsort ). الأفضل!

شيء واحد لم أره هنا: هل تذهب الحجج الموضعية الاختيارية أولاً أم أخيرًا؟ أحيانًا تكون الوسيطات الموضعية الاختيارية أولاً ، كما في sum(f, itr) و rand([rng,] ..) . لكن في مكان آخر يذهبون أخيرًا ، على سبيل المثال في median(v[, region]) أو split(s::AbstractString[, chars]) . في بعض الأحيان يمكنهم أن يذهبوا أولاً أو أخيرًا ، لكن ليس كلاهما! (على سبيل المثال ، يمكن أن يأخذ mean دالة أولاً أو بعدًا أخيرًا ، لكن ليس كلاهما.)

تفرض دلالات اللغة الحالية على الوسائط الاختيارية أن تذهب أخيرًا: يمكنك كتابة f(a, b=1) لكن ليس f(b=1, a) . ولكن إذا استمرت جميع الحجج الاختيارية أخيرًا ، فما الذي يحدث للكتل الملائمة؟

إذا لم يكن هناك شيء آخر ، فهو ثؤلول بسيط يجب على اللغة تحديد طرق مثل ذلك ، من rand.jl : shuffle!(a::AbstractVector) = shuffle!(GLOBAL_RNG, a) . يجب أن تهتم صيغة الحجة الموضعية الاختيارية بحالة الاستخدام هذه بالضبط.

ربما ينبغي الخوض في قضية منفصلة ، لكن يبدو أنه من الممكن نقل الحجج الاختيارية حيثما تريد. على سبيل المثال ، سيحدد f(a = 1, b, c = 2) f(x) = f(1, x, 2) و f(x, y) = f(x, y, 2)

xref # 22460 لمحاولة (غير شعبية) لتمكين Args الافتراضية في أي موضع.

ربما إعادة تسمية warn إلى warning (تستخدم matlab هذا أيضًا) ، ليست صفقة كبيرة ، لكن أعتقد أنني سأذكر؟

أحب warn لأنه فعل ، مثل throw .

لقد أصبت بالحيرة من هذا:

julia> f(;a=1,b=1) = a+b                                                                                                                              
f (generic function with 1 method)                                                                                                                    

julia> f(a=4,5)            # I intended to write f(a=4,b=5)                                                                                                                           
ERROR: MethodError: no method matching f(::Int64; a=4)                                                                                                
Closest candidates are:
  f(; a, b) at REPL[13]:1

أقترح السماح للكلمات الرئيسية فقط بالبقاء عند استدعاء الوظائف ، على غرار تحديد وظائف الكلمات الرئيسية.

أقترح السماح للكلمات الرئيسية فقط بالبقاء عند استدعاء الوظائف ، على غرار تحديد وظائف الكلمات الرئيسية.

هناك الكثير من واجهات برمجة التطبيقات حيث يكون تمرير الكلمات الرئيسية في مواضع أخرى مفيدًا ومريحًا.

بدافع الفضول ، هل هناك ترتيب محدد لتقييم الحجج الموضعية والكلمات الرئيسية؟ لقد رأيت بعض المشكلات القديمة و https://docs.julialang.org/en/latest/manual/functions/#Evaluation -Scope-of-Default-Values-1 تتحدث عن النطاقات ، لكن لم أجد شيئًا يوضح ما إذا كان على سبيل المثال يتم تقييم الوسائط من اليسار إلى اليمين ، أو يتم تقييم جميع الوسائط الموضعية قبل كل وسيطات الكلمات الأساسية ، أو إذا لم يكن هناك ترتيب تقييم محدد (أو أي شيء آخر).

yurivish ، للحصول على الكلمات الرئيسية ، انظر المستندات (أيضًا https://github.com/JuliaLang/julia/issues/23926). بالنسبة للقصص الاختيارية ، تكون القصة أكثر تعقيدًا بعض الشيء ، ربما اقرأ هنا . (لاحظ أنه من الأفضل طرح الأسئلة على https://discourse.julialang.org/)

لا يبدو أنه يستحق المشكلة الخاصة به ، ولكن يبدو لي دائمًا أنه من الغريب أن يقوم bits(1) بإرجاع String ، يبدو أنه يجب أن يكون BitVector أو Vector{Bool} .

أود اقتراح مراجعة لجداول الطريقة التي يتم إرسالها على Function أو Callable . دعنا نحاول التأكد من أن واجهات برمجة التطبيقات هذه هي الطريقة التي نريدها ... وأننا لا نفوت فرصة للسماح بإعادة هيكلة الجداول بحيث يمكننا السماح باستدعاء أي كائن.

بالنسبة إلى all و any ، يبدو من السهل التخلص منها إلى all(f(x) for x in xs) ، والتي تم تخفيضها بالفعل إلى all(Generator(f, xs)) وبالتالي لا يجب أن يكون لها أي نفقات إضافية.

لست متأكدًا مما إذا كان هذا هو ما تقصده ولكنني اعتقدت أنه من الجدير ذكره في حالة: أنا شديد ضد إهمال أي واجهات برمجة تطبيقات ذات نمط وظيفي للمولدات. لدينا any(f, x) و all(f, x) وهما مستخدمان على نطاق واسع ؛ -10000000 لإزالة تلك (أو أي طرق من هذا القبيل ، حقًا).

ايم برو مولد. يبدو وكأنه لبنة أساسية من البرمجة البطيئة ويجب تصديرها. all(Generator(f, xs)) أكثر ملاءمة أحيانًا للوظائف المحددة من all(f(x) for x in xs) . أيضا +10000000 لاستعادة التوازن

أنا أفضل وجود بنية أقل هنا إن أمكن. إذا كان من السهل والمقروء والأداء التعبير عن فكرة "خذ xs ، وطبق f على كل شيء ، وأعيد صوابها إذا كانت كل هذه الأمور صحيحة" ، فلماذا إذن نضعها في فعل واحد؟

إذا كان مصدر القلق هو الاسم غير الضروري x في f(x) for x in xs ، فإن اقتراحbramtayl بتصدير Generator (ربما باستخدام اسم أفضل مثل Map ؟) من المنطقي.

أشياء مثل all(isnull, x) أبسط من all(isnull(v) for v in x) . لقد أوقفنا وظيفة allnull من NullableArrays لصالح all(isnull, x) ؛ إذا اختفى هذا النحو ، فربما يتعين علينا إعادة تقديمه.

ماذا عن إعادة تسمية strwidth إلى stringwidth (أعتقد أن هذه هي وظيفة معالجة السلسلة الوحيدة المصدرة التي تحتوي على سلسلة مختصرة إلى str)

في الواقع تمت إعادة تسميته إلى textwidth (https://github.com/JuliaLang/julia/pull/23667).

IMO ، هذه المشكلة واسعة جدًا بحيث لا يمكن الحصول عليها 1.0 علامة فارقة ، نظرًا لأننا نريد الحصول على ميزة التجميد قريبًا. قد نحتاج إلى العديد من المالكين وتعيين مجموعات من الوظائف للمراجعة إذا أردنا القيام بذلك.

أيضًا ، هذا مكان آخر حيث يمكن لـ FemtoCleaner تحديث العديد من الأشياء تلقائيًا بعد الإصدار 1.0 ، على الرغم من أنه سيكون من الجيد الحصول عليها بشكل صحيح.

مجرد تعليق على عرض النص:

INFO: Testing Cairo
Test Summary:   | Pass  Total
Image Surface   |    7      7
Test Summary:   | Pass  Total
Conversions     |    4      4
Test Summary:   | Pass  Total
TexLexer        |    1      1
WARNING: both Compat and Cairo export "textwidth"; uses of it in module Main must be qualified
Samples        : Error During Test
  Got an exception of type LoadError outside of a <strong i="6">@test</strong>
  LoadError: UndefVarError: textwidth not defined
  Stacktrace:
   [1] include_from_node1(::String) at .\loading.jl:576
   [2] include(::String) at .\sysimg.jl:14
   [3] macro expansion at C:\Users\appveyor\.julia\v0.6\Cairo\test\runtests.jl:86 [inlined]
   [4] macro expansion at .\test.jl:860 [inlined]
   [5] anonymous at .\<missing>:?
   [6] include_from_node1(::String) at .\loading.jl:576
   [7] include(::String) at .\sysimg.jl:14
   [8] process_options(::Base.JLOptions) at .\client.jl:305
   [9] _start() at .\client.jl:371
  while loading C:\Users\appveyor\.julia\v0.6\Cairo\samples\sample_pango_text.jl, in expression starting on line 28

تبدو رسالة الخطأ واضحة جدًا حول ماهية المشكلة؟ يحتاج Cairo لتوسيع الطريقة الأساسية.

help?>  Base.textwidth
  No documentation found.

  Binding Base.textwidth does not exist.

julia> versioninfo()
Julia Version 0.6.0

julia> Compat.textwidth
textwidth (generic function with 2 methods)

ليس لدي أدنى شك في أن الرسالة (التي تلقيتها عبر travis) لا بأس بها ، ولكن لماذا يقوم Compat بتصدير عرض النص إذا لم يكن في 0.6؟

لأن هذا هو الهدف من Compat؟ هذه المناقشة تخرج عن نطاقها كثيرًا على الرغم من أنني أقترح أن نواصلها على الخطاب أو التراخي.

أقترح تغيير copy إلى shallowcopy و deepcopy إلى copy لأنني استغرقت مؤخرًا بعض الوقت لأدرك أن هذه النسخة نسخة "سطحية" و الوظيفة التي كتبتها كانت تحور مصفوفة من المصفوفات. أعتقد أنه سيكون أكثر سهولة إذا كان copy سيقوم بعمل نسخة "عميقة" ويستخدم شيء مثل shallowcopy للنسخ الضحلة؟ متى تستخدم deepcopy ، لكن أعتقد أن العديد من المستخدمين الآخرين سيواجهون نفس المشكلة.

دعنا نحاول من فضلك الحفاظ على هذه المشكلة من أجل اتساق واجهة برمجة التطبيقات ، وليس حقيبة من "أشياء محددة لا أحبها".

Associative يبدو الاسم غير متوافق

أولاً ، الأنواع ليست عادةً صفات. الاسم هو Association ، ويستخدم على الأقل من قبل بعض مستندات Mathematica التي وجدتها.

أعتقد أن AbstractDict سيكون أكثر اتساقًا بشكل كبير مع الأنواع الأخرى مثل AbstractArray و AbstractRange و AbstractSet و AbstractString ، كل منها يحتوي أنواع الخرسانة النموذجية Dict ، Array ، Range ، Set و String .

أنواع الاستثناءات الخاصة بنا موجودة قليلاً في كل مكان: بعضها يسمى FooError ، والبعض الآخر يسمى BarException ؛ يتم تصدير عدد قليل ، ومعظمها ليس كذلك. يمكن أن يستخدم هذا تمريرة من أجل الاتساق.

إذن ما هو الأفضل ، FooError أو BarException ؟ تصدير أم لا؟

بالنسبة لي ، يتضمن BarException مكان ما نمط رفع / اصطياد.

أنا أفضل كثيرًا ، وبعض الآخرين في العالم الوظيفي أيضًا ، استخدم النمط Some / None (*) حيث يكون تدفق التحكم أكثر مباشرة ويمكن التنبؤ به.

لذا +1 مقابل FooError

(*) Some / Void ex Optional في جوليا # 23642.

هل لا تزال هذه الأشياء مطروحة على الطاولة نظرًا لتجميد الميزات؟ أرغب بشكل خاص في معالجة الوسيطات الاختيارية مقابل الكلمات الرئيسية ، لكن قائمة الوظائف ذات الوسائط الاختيارية المتعددة (أوضح حالة لاستخدام وسيطات الكلمات الرئيسية بدلاً من ذلك) طويلة جدًا.

من فضلك الق نظرة! لم تتح لي الفرصة لمتابعة هذه القضايا بشكل منهجي.

راجع للشغل ، لقد لاحظت عدم اتساق في تسمية السمات: لدينا iteratorsize ، iteratoreltype ، لكن IndexStyle ، TypeRangeStep ، TypeArithmetic و TypeOrder . يبدو أن متغيرات CamelCase أكثر عددًا وأكثر حداثة ، لذلك ربما ينبغي علينا تبني هذه الاتفاقية في كل مكان؟

يجب أن تكون هذه بالتأكيد متسقة. هل تريد عمل علاقات عامة؟

أعتقد أنه يجب إصلاح هذا كجزء من https://github.com/JuliaLang/julia/pull/25356.

تحرير: راجع أيضًا https://github.com/JuliaLang/julia/issues/25440

يتم ذلك في الغالب أو يمكن القيام به في إصدارات 1.x. يمكنني تحديث مربعات الاختيار ، لكننا مررنا بها للتو في مكالمة الفرز وكل شيء ما عدا # 25395 وتم إجراء تدقيق الشرطة السفلية.

التأكيد على التدقيق

فيما يلي تحليل لجميع الرموز المصدرة من Base والتي تحتوي على شرطات سفلية ، ولم يتم إهمالها ، وليست وحدات ماكرو سلسلة. الشيء الرئيسي الذي يجب ملاحظته هنا هو أن هذه أسماء مُصدرة فقط ؛ هذا لا يشمل الأسماء غير المُصدرة التي نطلب من الأشخاص الاتصال بها مؤهلين.

لقد فصلت الأشياء حسب الفئة. نأمل أن يكون هذا مفيدًا أكثر مما هو مزعج.

انعكاس

لدينا وحدات الماكرو التالية مع الوظائف المقابلة:

• [] @code_llvm ، code_llvm
• [] @code_lowered ، code_lowered
• [] @code_native ، code_native
• [] @code_typed ، code_typed
• [] @code_warntype ، code_warntype

أي تغيير يتم تطبيقه على وحدات الماكرو ، إن وجد ، يجب تطبيقه بالمثل على الوظائف.

• [x] module_name -> nameof (# 25622)
• [x] module_parent -> parentmodule (# 25629 ، راجع # 25436 لمحاولة سابقة لإعادة التسمية)
• [x] method_exists -> hasmethod (# 25615)
• [x] object_id -> objectid (# 25615)
• [] pointer_from_objref

ربما يمكن استخدام pointer_from_objref باستخدام اسم وصفي أكثر ، ربما شيء مثل address ؟

الأسماء المستعارة لـ C interop

الأنواع المستعارة التي تحتوي على شرطات سفلية هي C_NULL ، Cintmax_t ، Cptrdiff_t ، Csize_t ، Cssize_t ، Cuintmax_t ، و Cwchar_t . يجب أن تبقى تلك التي تنتهي بـ _t ، حيث تم تسميتها لتكون متوافقة مع أنواع C المقابلة لها.

C_NULL هو الشيء الغريب الموجود هنا ، كونه الاسم المستعار C الوحيد الذي يحتوي على شرطة سفلية لا تنعكس في C (نظرًا لأن هذا في C هو فقط NULL ). يمكننا التفكير في استدعاء هذا CNULL .

• [] C_NULL

العد بت

• [] count_ones
• [] count_zeros
• [] trailing_ones
• [] trailing_zeros
• [] leading_ones
• [] leading_zeros

لمناقشة إعادة تسمية هذه ، انظر # 23531. أفضّل بشدة إزالة الشرطات السفلية لهذه ، بالإضافة إلى بعض البدائل المقترحة في ذلك العلاقات العامة. أعتقد أنه يجب إعادة النظر فيه.

عمليات غير آمنة

• [] unsafe_copyto!
• [] unsafe_load
• [] unsafe_pointer_to_objref
• [] unsafe_read
• [] unsafe_store!
• [] unsafe_string
• [] unsafe_trunc
• [] unsafe_wrap
• [] unsafe_write

ربما يكون من الجيد الاحتفاظ بهذه الأشياء كما هي ؛ قبح تسطير يؤكد كذلك عدم سلامتهم.

الفهرسة

• [] broadcast_getindex
• [] broadcast_setindex!
• [] to_indices

يبدو أن broadcast_getindex و broadcast_setindex! موجودون. لا أفهم ما يفعلونه. ربما يمكنهم استخدام اسم وصفي أكثر؟

ومن المثير للاهتمام ، أن إصدار الفهرس الفردي من to_indices ، Base.to_index ، لم يتم تصديره.

آثار

• [] catch_backtrace
• [x] catch_stacktrace -> stacktrace(catch_backtrace()) (# 25615)

من المفترض أن تكون هذه هي ما يعادل كتلة catch لـ backtrace و stacktrace ، على التوالي.

المهام والعمليات والإشارات

• [] current_task
• [] task_local_storage
• [] disable_sigint
• [] reenable_sigint
• [] process_exited
• [] process_running

تيارات

• [] redirect_stderr
• [] redirect_stdin
• [] redirect_stdout
• [x] nb_available -> bytesavailable (# 25634)

سيكون من الجيد أن يكون لديك وظيفة إعادة توجيه أكثر عمومية IO -> IO يمكن دمج كل هذه العناصر فيها ، على سبيل المثال redirect(STDOUT, io) ، وبالتالي إزالة كل من الشرطات السفلية والتصدير.

ترقية وظيفية

• [] promote_rule
• [] promote_shape
• [] promote_type

راجع # 23999 للمناقشة ذات الصلة بخصوص promote_rule .

طباعة

• [x] print_with_color -> printstyled (انظر رقم 25522)
• [] print_shortest (انظر # 25745)
• [] escape_string (انظر # 25620)
• [] unescape_string

escape_string و unescape_string غريبان بعض الشيء من حيث أنهما يمكنهما الطباعة إلى دفق أو إرجاع سلسلة. راجع # 25620 للحصول على اقتراح لنقل / إعادة تسمية هذه.

تحميل الكود

• [] include_dependency
• [] include_string

include_dependency . هل هذا حتى يستخدم خارج القاعدة؟ لا أستطيع التفكير في موقف تريد فيه هذا بدلاً من include في أي سيناريو نموذجي.

include_string . أليست هذه مجرد نسخة معتمدة رسميًا من eval(parse()) ؟

أشياء لم أزعج تصنيفها

• [x] gc_enable -> GC.enable (# 25616)
• [] get_zero_subnormals
• [] set_zero_subnormals
• [] time_ns

get_zero_subnormals و set_zero_subnormals مع المزيد من الأسماء الوصفية. هل هم بحاجة للتصدير؟

+1 لـ method_exists => methodexists و object_id => objectid . من السخف أيضًا وجود catch_stacktrace . يمكن إهماله إلى تعريفه ، stacktrace(catch_backtrace()) .

كيف نشعر حيال إلغاء تحديد C_NULL ؟ لقد اعتدت على ذلك كثيرًا ، لكنني أيضًا أشتري الحجة القائلة بأن أيا من الأسماء الأخرى C* لها شرطة سفلية.

أسماء C الأخرى هي أنواع ، بينما C_NULL ثابت. أعتقد أنه من الجيد كيف يتم ذلك ويتبع إرشادات التسمية.

ويتبع إرشادات التسمية.

كيف ذلك؟

غالبًا ما تكون الثوابت عبارة عن أحرف استهلالية ذات شرطات سفلية - يتبعها C_NULL . كما قال @ iamed2 ، إنها قيمة وليست نوعًا ، لذا فإن اصطلاح التسمية Cfoo لا ينطبق بالضرورة.

ظننت خطأً أن https://github.com/JuliaLang/julia/blob/master/doc/src/manual/variables.md#stylistic -conventions تشير إلى ثوابت لكنها لم تفعل ذلك. ربما ينبغي.

أقترح واجهة متسقة وصحيحة رياضياً لمساحات هيلبرت العامة التي لا تكون المتجهات فيها مصفوفات جوليا. يمكن استبدال أسماء الوظائف مثل vecdot ، vecnorm ، وما إلى ذلك بالمفاهيم العامة inner و norm كما تمت مناقشته في https: // github. كوم / JuliaLang / جوليا / قضايا / 25565.

كما قلت عدة مرات ، هذه ليست مشكلة عامة للأشياء التي يريد المرء تغييرها.

أعتقد أن العناصر الوحيدة المتبقية تحت هذه المظلة لـ 1.0 هي # 25501 و # 25717.

أود أن أفعل شيئًا باستخدام (get|set)_zero_subnormals ولكن ربما يكون أفضل حل قصير المدى هو إلغاء تصديرها فقط.

الشيء الذي ربما يجب مراجعته هو كيفية معالجة الأرقام في سياق عمليات التجميع مثل map و collect . تمت الإشارة إلى أن الأول يُرجع عددًا ولكن الأخير يُرجع مصفوفة 0D.