Libelektra: مكتبة للأنواع

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

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

@ bauhaus93 إذا كنت لا ترى فائدة فورية في الحصول على مكتبة نوع (على سبيل المثال إعادة الاستخدام مع ملحق آخر) ، يرجى إغلاق المشكلة.

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

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

قد يشجع امتلاك المكتبة أيضًا شخصًا ما على كتابة مكون إضافي جديد للتخزين ، نظرًا لأن بعض العمل قد تم بالفعل.

لكنني قمت بتمييز هذا على أنه low priority ، بالضبط لأنني كنت أعرف أن هناك الكثير من العمل وربما لا يوجد أحد يريد القيام بذلك.

بالنسبة للأنواع ، لست متأكدًا من قابلية إعادة الاستخدام ، باستثناء ربما التحقق من صحة / تحويل الأعداد الصحيحة غير العشرية (ثنائي / ثماني / سداسي عشري) أو أوقات (تستخدم TOML RFC 3339 datetimes).
غير مرتبط بالأنواع ، أرى بعض القابلية لإعادة الاستخدام في إعداد مجموعات المفاتيح المراد كتابتها (على سبيل المثال ، الوظائف التي تقوم بتحديث / إضافة array metakeys أو إزالة array metakeys من المصفوفات غير الصالحة أو إكمال comment/#X المفقود بيانات metakey

ربما لم تكن قد لاحظت ذلك حتى الآن ، ولكن قد تكون هناك أيضًا مشاكل في تطبيع القيم المنطقية التي يقوم بها البرنامج المساعد من النوع. ربما يكون هذا هو الرمز الأكثر استخدامًا ، نظرًا لأن معظم التنسيقات ستستخدم true / false لكن Elektra تستخدم 1 / 0 . أعتقد أن yamlcpp اضطر إلى إضافة بعض الأكواد الخاصة ، حتى لا يتم تحويل القيم المنطقية إلى أعداد صحيحة أو العكس (أو شيء من هذا القبيل).

آه نعم ، نسيت ذلك ، يجب أن يقوم المكون الإضافي TOML أيضًا بتطبيع هذه القيم.

لا تكمن المشكلة فقط في أنه يتعين عليك تطبيع القيم. يجب أيضًا أن تعرف بالضبط ما يفعله المكون الإضافي type ، لأنه يعمل قبل المكوّن الإضافي toml في المرحلة kdbSet . لست متأكدًا ، إذا قمنا بتطبيقه من قبل ، ولكن يجب عليك أيضًا التأكد من أن المكون الإضافي type ينتج فقط 1 / 0 أو true / false في المرحلة kdbSet ، بغض النظر عن التكوين المقدم من المستخدم. بخلاف ذلك ، يجب أن يكون toml قادرًا على تحليل تكوين المكون الإضافي type ، حيث يمكن للمستخدم تعيين قيم صحيحة وخاطئة مخصصة (انظر حالة الاختبار أدناه)

https://github.com/ElektraInitiative/libelektra/blob/4b0e9f8bdd6d890a1a3abaf04c543b9c7d33e984/src/plugins/type/testmod_type.c#L734 -L771

الجزء المثير للاهتمام هو:

https://github.com/ElektraInitiative/libelektra/blob/4b0e9f8bdd6d890a1a3abaf04c543b9c7d33e984/src/plugins/type/testmod_type.c#L749 -L753

يتلقى المكون الإضافي type 1 في kdbGet (يمكن أن يكون من toml ) ، لكنه يُرجع t في kdbSet . قد يصل هذا الأمر إلى حد قيام المستخدم بتحديد أن true = 0 و false = 1 الأمر الذي من شأنه أن يربك المكوّن الإضافي toml . (أعتقد أن جميع القيم المنطقية ستقلب على كل kdbSet )

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

نظرًا لأن المكوّن الإضافي toml يتعامل أيضًا مع الأرقام السداسية العشرية ، فمن المحتمل أيضًا أن يمنع بشكل صريح استخدام المكوّن الإضافي hexnumber . (على الرغم من أنه في هذه الحالة هناك احتمال أقل للمشاكل على ما أعتقد)

قد يشجع امتلاك المكتبة أيضًا شخصًا ما على كتابة مكون إضافي جديد للتخزين ، نظرًا لأن بعض العمل قد تم بالفعل.

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

بالنسبة للأنواع ، لست متأكدًا من قابلية إعادة الاستخدام ، باستثناء ربما التحقق من صحة / تحويل الأعداد الصحيحة غير العشرية (ثنائي / ثماني / سداسي عشري) أو أوقات (تستخدم TOML RFC 3339 datetimes).

التاريخ / الأوقات كانت موجودة في Elektra فقط للتحقق من الصحة ولكن لم يتم دعم سوى RFC2822. يمكن أن يعيد المكون الإضافي للتاريخ استخدام المحلل اللغوي للتحقق من صحة RFC 3339 لكنني سأعتبر ذلك ذا أولوية منخفضة للغاية.

ما قد يكون أكثر إثارة قليلاً هو شيء مثل keyGetDateTime(Key *k, struct tm *tm) من مفتاح بتاريخ (TOML).

غير مرتبط بالأنواع ، أرى بعض قابلية إعادة الاستخدام في إعداد KeySets المراد كتابتها (على سبيل المثال ، الوظائف التي تقوم بتحديث / إضافة مجموعة metakeys أو إزالة metakeys من المصفوفات غير الصالحة أو إكمال التعليق المفقود / # X metakey data).

نعم ، قد يكون ذلك ممتعًا. ولكن الأمر الأكثر روعة هو إمكانية تعديل القواعد النحوية واللمس بشكل مباشر بأقل قدر ممكن: wink:

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

ما هو مفقود هو بعض البرامج التعليمية / الشرح في doc / tutorials / storage-plugins.md والذي يعطي عرضًا محدثًا للمكونات الإضافية التي يجب أن يعتمد عليها المكون الإضافي للتخزين. سيُظهر # 2330 ما إذا كانت هناك حاجة إلى "ثنائي" وما زال مناسبًا للتخزين الافتراضي.

عليك أيضًا أن تعرف بالضبط ما يفعله نوع البرنامج المساعد ، لأنه يعمل قبل المكون الإضافي toml في مرحلة kdbSet.

ربما ، يجب أن تتوقف مكونات التخزين الإضافية عن استخدام المكون الإضافي من النوع وأن تقوم ببساطة بتطبيعها بنفسها (من كل ما هو صحيح / خطأ في تنسيقها إلى 1/0 في Elektra وما إلى ذلك). @ bauhaus93 ما هي الوظائف الأخرى لنوع البرنامج المساعد الذي تستخدمه؟

يمكن أن يصل هذا إلى حد تعريف المستخدم أن true = 0 و false = 1 مما قد يربك المكون الإضافي toml تمامًا.

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

نظرًا لأن المكون الإضافي toml يتعامل أيضًا مع الأرقام السداسية العشرية ، فمن المحتمل أيضًا أن يمنع بشكل صريح استخدام المكون الإضافي hexnumber. (على الرغم من أنه في هذه الحالة هناك احتمال أقل للمشاكل على ما أعتقد)

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

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

هذا يبدو سحريًا بعض الشيء ليكون ممكنًا. قد يكون ذلك ممكنًا باستخدام منشئ رمز مخصص استنادًا إلى قواعد نحوية معدلة لـ Yacc أو ANTLR. لكن لا أعتقد أن هناك طريقة للحصول على رمز ينشئ KeySet s ببساطة من القواعد النحوية لتنسيقات مختلفة إلى حد كبير مثل JSON و XML و TOML و edn . نظرًا لأن @ 'sanssecours وجدت أن هناك أيضًا تنسيقات مثل YAML يصعب التعبير عنها بتنسيق نحوي قياسي.

على الرغم من ذلك ، يبدو لي أن مكتبة النوع وحدها متخصصة بشكل كبير لتكون مفيدة للغاية للمهمة الكبيرة المتمثلة في "كتابة مكون إضافي للتخزين".

يمكننا بالطبع توسيع المكتبة إلى مكتبة عامة storage توفر المزيد من الوظائف المساعدة لمكونات التخزين (على سبيل المثال التعامل مع stdin / stdout وأنابيب للاستيراد / التصدير). ستكون عناصر الكتابة جزءًا من ذلك.

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

مكتبة أخرى من النوع القياسي تضمن أيضًا رسائل الخطأ القياسية لمشاكل الكتابة. لذلك ستكون هناك ميزة للمستخدمين النهائيين.

ما سيكون أكثر إثارة قليلاً هو شيء مثل keyGetDateTime (Key * k، Struct tm * tm)

يبدو وكأنه وظيفة لجزء التحويل libease (مثل elektraKeyToDateTime (const Key * key, struct tm * dateTime) ).

@ bauhaus93 قد تكون الوظائف هناك مفيدة مقابل toml أيضًا. تم تصميمها بحيث تكون على سبيل المثال elektraKeyToFloat و elektraFloatToString ذهابًا وإيابًا بشكل مثالي وبدون خسارة (بغض النظر عما إذا كنت تبدأ بعوامة لسلسلة) ويتم استخدامها أيضًا في واجهة برمجة التطبيقات عالية المستوى. لذلك إذا أنشأ toml المفتاح بـ elektra*ToString فمن المؤكد أنه يمكن قراءته بشكل صحيح بواسطة واجهة برمجة التطبيقات عالية المستوى و toml يمكنه بالتأكيد قراءة كل ما ينتج عن واجهة برمجة التطبيقات highlevel بشكل صحيح elektraKeyTo* .

عرض محدث للمكونات الإضافية التي يجب أن يعتمد عليها المكون الإضافي للتخزين.

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

حتى التعامل مع المفاتيح الثنائية ، يمكن حله بشكل أفضل من خلال مكتبة التخزين / النوع. مرة أخرى يضمن بعض المعايير الأساسية لرسائل الخطأ وما إلى ذلك. كما أنه يتجنب استخدام المكوّن الإضافي binary للتنسيقات التي لا تحتاج إليه. بينما يعمل binary مع مثال quickdump ، إلا أنه سيء ​​لكل من السرعة وحجم التخزين.

ربما ، يجب أن تتوقف مكونات التخزين الإضافية عن استخدام البرنامج المساعد من النوع وتقوم ببساطة بتطبيعها بنفسها

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

سأؤيد تقليل وظائف البرنامج المساعد من النوع.

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

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

حقا ليست هناك حاجة لذلك. هناك مشكلة فقط ، إذا كان هناك أكثر من مكون إضافي يحدد القيمة المنطقية.

حتى true = 0 و false = 1 بخير تمامًا. تقوم شركة Elektra نفسها بتغريم القيم المنطقية لأن " 1 هي القيمة الحقيقية الوحيدة و 0 هي القيمة الزائفة الوحيدة".

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

أنا أعترض. سيكون من المستحيل بالطبع الحصول على قائمة شاملة (بعد كل شيء ، هناك أيضًا مكونات إضافية تابعة لجهات خارجية) ، لكن الحل بسيط. دع المكونات الإضافية تقوم بالتحقق بنفسها. إما في elektra<Plugin>Get أو في دالة أخرى يتم استدعاؤها أثناء kdb mount .

بالإضافة إلى منطقية ، يقوم المكون الإضافي TOML أيضًا بتعيين أنواع السلسلة والمزدوجة والطويلة (غير الموقعة) عند القراءة.

أتفق مع kodebach ، على أن المكوّن الإضافي type يجب أن يُستخدم فقط بواسطة الإضافات التي لا تحتوي على نظام من النوع المدمج ، بسبب صعوبات في التفاعل.
على سبيل المثال. يعيّن المكون الإضافي TOML type metakey للأعداد الصحيحة عند القراءة أيضًا على القيم غير العشرية (أثناء تحويله إلى رقم عشري ، وتخزين التمثيل غير العشري في origvalue ). ومع ذلك ، إذا كنت ترغب في تغيير هذه القيمة المكتوبة بـ kdb set (وقم بذلك عن طريق القيمة الثنائية / الثماني / السداسية) ، فلا يمكنك القيام بذلك مباشرة (عن طريق تعيين قيمة المفتاح) ، لأن type عمليات التحقق من نوع المكون الإضافي origvalue metakey بدلاً من ذلك. (لن ينجح حذف metakey type قبل تعيين قيمة جديدة ، حيث سيتم إعادة تعيين metakey عند القراءة.)

لا تكمن المشكلة فقط في أنه يتعين عليك تطبيع القيم. عليك أيضًا أن تعرف بالضبط ما يفعله نوع البرنامج المساعد ، لأنه يعمل قبل المكون الإضافي toml في مرحلة kdbSet. لست متأكدًا ، إذا قمنا بتنفيذها من قبل ، ولكن يجب عليك أيضًا التأكد من أن المكون الإضافي من النوع ينتج فقط 1/0 أو صحيح / خطأ في مرحلة kdbSet ، بغض النظر عن التكوين المقدم من المستخدم. بخلاف ذلك ، سيتعين على toml أن يكون قادرًا على تحليل تكوين المكون الإضافي لنوع ، حيث يمكن للمستخدم تعيين قيم صحيحة وخاطئة مخصصة (انظر حالة الاختبار أدناه)

نعم لقد تساءلت بالفعل ، إذا / كيف يمكنني التحقق من القيم المنطقية التي يحددها المستخدم. في الوقت الحالي ، عند الكتابة ، يعتبر المكون الإضافي TOML فقط قيم "1" و "true" أنها صحيحة ، سيتم اعتبار الباقي كاذب.

kodebach كتب:

هذا يبدو سحريًا بعض الشيء ليكون ممكنًا.

مع Augeas من الممكن (لكن الأشجار التي تحصل عليها ليست مرغوبة جدًا). سيكون من المثير للاهتمام مدى بعدنا عن حل TOML الحالي. بالطبع أنت بحاجة إلى كتابة بعض التعليمات البرمجية للباعث ولكن هذا ليس بالأمر الدراماتيكي في العادة.

JSON و XML

من مزايا Elektra أنه يمكن تنفيذ مثل هذه التنسيقات المختلفة إلى حد كبير في تقنيات مختلفة. ربما لا تكون محاولة تطبيق XML من البداية هي أفضل فكرة. إذا أمكن تغطية تنسيقات تشبه INI ، فسيكون ذلك مذهلاً بالفعل.

ولكن بالطبع فإن أول وأهم شيء هو الحصول على ملحق TOML جيد: 1st_place_medal:

مكتبة أخرى من النوع القياسي تضمن أيضًا رسائل الخطأ القياسية لمشاكل الكتابة.

يمكن إجراء الفحص بسهولة في المكونات الإضافية الأخرى (بمجرد الانتهاء من # 2963). إذا كان المكون الإضافي يقوم بالتحقق والفشل برسالة خطأ جميلة ، فهناك تفاعلات قليلة / معدومة.

يبدو وكأنه وظيفة لجزء التحويل من libease

نعم ، من المحتمل أن تذهب بعض الأشياء من TOML إلى libease أو libmeta.

IMO ، يجب ألا يعتمد المكون الإضافي للتخزين على أي مكون إضافي آخر.

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

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

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

لماذا إزالة الوظائف التي تم تنفيذها بالفعل؟

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

لسوء الحظ ، حتى الكود المنفصل في المكونات الإضافية يخلق مشاكل: على سبيل المثال في خادم البناء أو بمجرد أن يحاول المستخدم استخدامه ، هناك تفاعلات غير مرغوب فيها / docu مفقود / ...

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

وهذا أيضًا هو سبب استبدال TOML بـ INI. # 3491

دع المكونات الإضافية تقوم بالتحقق بنفسها.

نادرا ما كان هذا حلا جيدا. يصبح الأمر غير متسق للغاية وقد يؤدي ترتيب إضافة المكونات الإضافية إلى نتائج مختلفة. هل هذا الرمز موجود بالفعل في مكان ما؟

@ bauhaus93 كتب:

بالإضافة إلى منطقية ، يقوم المكون الإضافي TOML أيضًا بتعيين أنواع السلسلة والمزدوجة والطويلة (غير الموقعة) عند القراءة.

ولكن هل كل ذلك من تلقاء نفسه بدون نوع البرنامج المساعد؟ ما هو نوع البرنامج المساعد المستخدم؟

يجب عليك تغيير metakey origvalue بدلا من ذلك.

نعم هنا ليس لدينا حل جيد بعد (# 3056). keySetString يزيل Origvalue ولكن بطريقة ما السلوك لا يزال ليس كما يتوقع المستخدم.

في الوقت الحالي ، عند الكتابة ، يعتبر المكون الإضافي TOML فقط قيم "1" و "true" صحيحة ، أما الباقي فسيُنظر إليه على أنه خطأ.

ربما يجب أن نكون أكثر صرامة وأن نفشل في كل شيء ليس "0" أو "1". في ملف TOML نفسه ، أنت تسمح أيضًا فقط بـ "صواب" و "خطأ" ولا شيء آخر؟

ولكن هل كل ذلك من تلقاء نفسه بدون نوع البرنامج المساعد؟ ما هو نوع البرنامج المساعد المستخدم؟

نعم ، إنها تفعل ذلك بنفسها ، ستتم مطابقة الأنواع المختلفة أثناء lexing. ومع ذلك ، فإنه لا يتحقق مما إذا كانت القيم العشرية / المزدوجة تتخطى / تحت التدفق long_long / double ، لذلك أعتقد أن هذا يتم بواسطة المكوّن الإضافي type .

ربما يجب أن نكون أكثر صرامة وأن نفشل في كل شيء ليس "0" أو "1". في ملف TOML نفسه ، أنت تسمح أيضًا فقط بـ "صواب" و "خطأ" ولا شيء آخر؟

نعم ، يمكنني أن أجعل ذلك أكثر صرامة. في الملف نفسه فقط true أو false تتم كتابته / قراءته على أنه منطقي.

بالنسبة لجميع الوظائف الأخرى ، هذا أيضًا استنتاجي.

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

إذا كان هناك عدد كبير من الاحتمالات الصحيحة ، فقد يكون البرنامج التعليمي / الوصف أفضل

ولكن في هذه الحالة ، لن يكون الحل أيضًا هو المكون الإضافي المنفصل ، لأنه يوجد أيضًا عدد كبير من التفاعلات المحتملة التي يجب مراعاتها في كلا المكونين الإضافيين.

هل هذا الرمز موجود بالفعل في مكان ما؟

AFAIK ، لست متأكدًا حتى من أن البرنامج المساعد يمكنه اكتشاف المكونات الإضافية الأخرى المثبتة.

ولكن هل كل ذلك من تلقاء نفسه بدون نوع البرنامج المساعد؟ ما هو نوع البرنامج المساعد المستخدم؟

نعم ، إنها تفعل ذلك بنفسها ، ستتم مطابقة الأنواع المختلفة أثناء lexing. ومع ذلك ، فإنه لا يتحقق مما إذا كانت القيم العشرية / المزدوجة تتخطى / تحت التدفق long_long / double ، لذلك أعتقد أن هذا يتم بواسطة المكوّن الإضافي type .

نعم ، يقوم type أيضًا بفحص النطاق ، والتحقق من صحة float / double وبعض الأشياء الأخرى مثل enum s.

ربما يجب أن نكون أكثر صرامة وأن نفشل في كل شيء ليس "0" أو "1". في ملف TOML نفسه ، أنت تسمح أيضًا فقط بـ "صواب" و "خطأ" ولا شيء آخر؟

وهذه بالضبط واحدة من هذه الحالات المعقدة للغاية والمعقدة للأنواع أو بشكل أكثر تحديدًا التحويل / التطبيع.

لنفترض أن toml يقبل فقط true / false كإدخال ولا ينتج سوى 0 / 1 في kdbGet و هو يقبل فقط 0 / 1 وينتج فقط true / false kdbSet . هذا من شأنه أن يتوافق مع كل من مواصفات Elektra ومواصفات TOML لـ booleans. ولكن ربما يتوقع المستخدم أن kdb set /some/key/mounted/with/toml true سيعمل. ومع ذلك ، فهي لا تفعل ذلك. مع التكوين الصحيح لـ type قد يعمل ، لكنه سرعان ما يصبح محرجًا. على سبيل المثال ، ماذا لو كان المفتاح موجودًا من قبل. ثم لا يوجد type metakey والمكوِّن الإضافي type يتجاهله فقط ، toml يتلقى true ويشكو من أن true ليس صالحًا قيمة منطقية ...

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

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

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

IMO ، يجب ألا يعتمد المكون الإضافي للتخزين على أي مكون إضافي آخر.

Iirc هذا الاستنتاج لم يتم قبوله على نطاق واسع (sanssecours؟) ولم يتم توثيقه.

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

كما أنني لا أعتقد أن هذا عظيم من وجهة نظر الفصل بين الاهتمامات. إن كتابة مكون إضافي جيد للتخزين هو بالفعل الكثير من العمل في رأيي.

هذا هو الهدف من المكتبة المساعدة. إنه يقسم الكود المشترك وبالتالي يوفر (بعض) فصل الاهتمامات بالإضافة إلى تسهيل تطوير البرنامج المساعد.

فيما يتعلق بمخاوف @ markus2330 من أن تطوير مكتبة للأغراض العامة أصعب من أي مكون إضافي مماثل: هذا خطأ من الناحية الواقعية ، لأنه يمكنك ببساطة توفير نسخة معدلة قليلاً من الوظيفة elektraTypeGet كمكتبة. التعديلات مطلوبة فقط لأننا نحتاج إلى استبدال Plugin * handle بـ KeySet * config . على الرغم من أن هذا قد لا يحل جميع المشكلات ، إلا أنه على الأقل يتيح للمكوِّن الإضافي للتخزين التحكم في كيفية ووقت إجراء عناصر الكتابة بالضبط.

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

باختصار ، المكتبة بسيطة ومرونة أكثر بكثير من المكوِّن الإضافي من وجهة نظر مكون التخزين. على الأقل مع إمكانيات تكوين البرنامج المساعد الحالي.

إن اشتراط أن يعتني مكون التخزين الإضافي بتحويل النوع ومفاتيح الدليل والبيانات الثنائية (ترميز Base64) لا يجعل هذه المهمة أسهل.

لنفصل هذا:

• البيانات الثنائية: لا يوجد فعلاً أي جهد ينطوي على القيام بشيء مثل:
  if (keyIsBinary (key)) { writeValue (elektraBase64Encode (keyValue (key), keyGetValueSize (key))); } else { writeValue (keyString (value)); }
  سيعمل المكون الإضافي المنفصل أيضًا ، طالما أن المكون الإضافي للتخزين يمكنه فرض تثبيت المكون الإضافي الآخر في جميع الظروف ويمكنه ببساطة افتراض عدم وجود مفاتيح ثنائية. إذا كان لا يزال يتعين على المكون الإضافي الاتصال بـ keyIsBinary ووجد خطأ ، فلا فائدة من هذا الحل. لا أحب أيضًا أن يقوم المكون الإضافي الثنائي المنفصل بتحويل KeySet بالكامل مرة واحدة ، لأن جميع مفاتيح Base64 تضيع وقتًا كبيرًا من الذاكرة.
• مفاتيح الدليل: أولاً ، هذه المفاتيح غير الورقية ذات القيم غريبة في جميع الظروف تقريبًا ويجب أن نوصي بالفعل بتجنبها. عندما يتعلق الأمر بالتعامل مع هذه المفاتيح ، كما هو مذكور في # 3256 ، أعتقد أن المكتبة مناسبة بشكل أفضل لهذه الحالة. هناك العديد من الأسباب ، بما في ذلك الذاكرة ومعالجة الحمل الزائد ، مما يؤدي إلى تعقيد تكوينات نقطة التحميل والمرونة دون داعٍ. يبدو أن @ markus2330 (إلى حد ما) يتفق معي في هذه النقطة.
• الأنواع: أي مكون إضافي للتخزين لتنسيق يحتوي على نظام كتابة أصلي يجب أن يقوم ببعض الأعمال على الأقل للأنواع. يمكن أن يتراوح هذا من إجراء التحويل الكامل من نقطة الصفر من خلال استدعاء بعض المكتبات إلى تكوين مكون إضافي آخر. لن يكون من الممكن أبدًا أن يعمل كل شيء فقط. حتى إذا كان هناك مواصفات رسمية مفصلة للغاية للأنواع بحيث لا تكون هناك حاجة إلى تكوين مباشر لنوع المكون الإضافي ، فسيتعين على المكون الإضافي للتخزين تنفيذ هذه المواصفات بطريقة أو بأخرى.

ومع ذلك ، فإنه لا يتحقق مما إذا كانت القيم العشرية / المزدوجة تتخطى / تحت التدفق long_long / double ، لذلك أعتقد أن هذا يتم بواسطة typeplugin.

حسنًا ، لذلك فأنت تستخدمه فقط للتحقق.

ولكن في هذه الحالة ، لن يكون الحل أيضًا مكونًا إضافيًا منفصلاً

لا ، المكونات الإضافية المنفصلة ليست هي الحل للأسف. لقد فشلنا هناك. الحل الحالي هو أن كل مكون إضافي للتخزين ينفذ كل شيء (باستثناء المعالجة الثنائية) بناءً على المستند / البرامج التعليمية / storage-plugins.md

ولكن ربما يتوقع المستخدم أن kdb set / some / key / mount / with / toml true سيعمل.

لا ، يجب ألا يتوقع المستخدم ذلك. في Elektra 1/0 هي صحيحة / خطأ. قد تعين مكونات التخزين الإضافية فقط هذا إلى شيء آخر.

الأساس المنطقي: نظرًا لأن مستوى المواصفات 1/0 يعمل فقط ، فسيكون من المربك فقط عمل صح / خطأ في أي مكان آخر (باستثناء مكونات التخزين الإضافية).

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

نعم اوافق.

هذه نقطة عادلة ، على الرغم من أنني لا أعتقد أن حذف الكود هو الحل الصحيح.

بالطبع نحتاج إلى حذف الكود "الصحيح": الرمز الذي يمنحك التوقعات دون الوفاء بها أو إدخال مشاكل مع أجزاء أخرى من Elektra. ويبدو أن بعض وظائف البرنامج المساعد من النوع تسبب مشاكل مع أجزاء أخرى من Elektra.

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

لسوء الحظ ، هذا لا يعمل (حتى الآن *). لا يحكم الأشخاص على حالة المكونات الإضافية بشكل صحيح ، على سبيل المثال انظر مؤخرًا: # 3472 حيث يُعتقد أن المكون الإضافي INI الذي لم تتم صيانته والمزود بالأخطاء ، والأسوأ من ذلك ، المكون الإضافي xmltool القديم المحبط ، يعمل بشكل مثالي.

• قد يعمل بشكل أفضل إذا قمت بإعادة صياغة # 666 وقمنا بإخراج تحذيرات أثناء التركيب.

إن اشتراط أن يعتني مكون التخزين الإضافي بتحويل النوع ومفاتيح الدليل والبيانات الثنائية (ترميز Base64) لا يجعل هذه المهمة أسهل.

sanssecours كيف تتعامل ملحقات YAML مع تحويل النوع؟

هذا خطأ في الواقع

سنرى عند الانتهاء: stuck_out_tongue_winking_eye:

باختصار ، المكتبة بسيطة ومرونة أكثر بكثير من المكوِّن الإضافي من وجهة نظر مكون التخزين. على الأقل مع إمكانيات تكوين البرنامج المساعد الحالي.

لم يجادل أحد في ذلك. لكن المرونة تأتي أحيانًا بسعر باهظ.

لا يوجد أي جهد في الواقع ينطوي على فعل شيء مثل

Base64 ليست الطريقة الوحيدة لتشفير البيانات الثنائية. بالنسبة للمعايير التي تتطلب base64 ، يمكن أن تكون مشفرة. ( sanssecours هل هذا هو الحال بالنسبة لـ YAML؟)

بالنسبة إلى TOML ، فإنه يقول ببساطة "Base64 أو ترميز ASCII أو UTF-8 مناسب آخر" ، لذلك يمكن استخدام المكونات الإضافية الثنائية الأخرى. لذا فإن الحل الحالي له مزايا ، حيث يمكن للمستخدمين تركيب مكونات إضافية ثنائية أخرى حسب الرغبة أو الحاجة.

يجب تغيير @ bauhaus93 - infos/needs = base64 إلى - infos/needs = binary .

أولاً ، هذه المفاتيح غير الورقية ذات القيم غريبة في جميع الظروف تقريبًا ويجب أن نوصي بالفعل بتجنبها.

هناك الكثير من الأشكال الشائعة. ويمكن أن تكون مفيدة جدًا عند توسيع تحديد (إنشاء مفاتيح فرعية من مفاتيح لها قيم).

[مفاتيح الدليل] يبدو أن @ markus2330 (إلى حد ما) يتفق معي في هذه النقطة.

أوافق على أن مكونات التخزين الإضافية تحتاج إلى التعامل معها (ربما مع مكتبة ولكن ليس مع المكون الإضافي "directoryvalue" لأن escaping لا يعمل والهروب الصحيح هو أحد المهام الرئيسية لمكوِّن إضافي للتخزين).

حسنًا ، لذلك فأنت تستخدمه فقط للتحقق.

لا أتفق مع العبارة "المكوّن الإضافي toml يستخدم المكوّن الإضافي type ". في الإصدار الحالي ، توصي فقط type .

https://github.com/ElektraInitiative/libelektra/blob/c61e388c4aa950cf84aa2f00fba7cdd34a47640e/src/plugins/toml/README.md#L5 -L6

حتى لو تم التصريح عن type كـ needs ، فلن أسميها "باستخدام". لا يمتلك toml أي سيطرة مباشرة على type . هذا هو السبب في أنني قلت toml يعتمد على type . تتوقع type القيام بأشياء معينة بطريقة معينة ، لكن لا يمكنني فعل أي شيء ، إذا لم يكن الأمر كذلك.

قد يعمل بشكل أفضل إذا قمت بإعادة صياغة # 666 وقمنا بإخراج تحذيرات أثناء التركيب.

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

Base64 ليست الطريقة الوحيدة لتشفير البيانات الثنائية.

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

هناك الكثير من الأشكال الشائعة.

هل لديك مثال؟

ويمكن أن تكون مفيدة جدًا عند توسيع تحديد (إنشاء مفاتيح فرعية من مفاتيح لها قيم).

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

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

ولكن ليس مع البرنامج المساعد "directoryvalue" حيث لا يعمل escaping

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

sanssecours كيف تتعامل ملحقات YAML مع تحويل النوع؟

يستخدم Yan LR و YAML CPP المكوّن الإضافي type للمنطقين. تستخدم YAML CPP أيضًا المكوّن الإضافي base64 للبيانات الثنائية.

Base64 ليست الطريقة الوحيدة لتشفير البيانات الثنائية. بالنسبة للمعايير التي تتطلب base64 ، يمكن أن تكون مشفرة. ( sanssecours هل هذا هو الحال بالنسبة لـ YAML؟)

نعم ، بقدر ما أعرف ، تستخدم البيانات الثنائية في YAML دائمًا ترميز Base64.

[مفاتيح غير طرفية ذات قيم] هل لديك مثال؟

XML ومعظم لهجات INI (لأنها تسمح بـ key=value حتى عند وجود [key] )

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

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

على سبيل المثال ، يحتوي deluser.conf على BACKUP = 0 و BACKUP_TO = "." . باستخدام الأقسام ، قد تستخدم معظم التطبيقات BACKUP_ENABLE بدلاً من مجرد BACKUP .

هناك أيضًا أفكاري من # 3223 التي من شأنها أن تحل مشكلة الهروب (لكل حالة استخدام ليس فقط directoryvalue ) بالإضافة إلى بعض الأشياء الأخرى.

لقد قمت الآن بتحديث الاقتراح في # 3223. آمل أن يكون فهمه أسهل الآن (ما زال طويلاً جدًا).

https://github.com/kodebach/libelektra/blob/dcec6e865bba32f6d83c40c2f711c2e70dde6d62/doc/proposals/keynames.md

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

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

السؤال الكبير هو من سينفذ كل هذا.

هذا هو السؤال دائما ...

إنه بعيد تمامًا عن الوضع الراهن ، أي الكثير من العمل (وحده تغيير المصطلحات هو قدر هائل من العمل).

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

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

سأبدأ علاقات عامة ، لكن ما إذا كان لدي الوقت لإنهائه (بمفردي) في المستقبل ، لا أستطيع أن أقول.
لدي بالفعل فرع محلي حيث تم استبدال جميع المكالمات لـ keyBaseName و keySetBaseName و keyAddBaseName بـ keyLastUnescapedPart ، keySetLastUnescapedPart / keySetLastLiteralPart و keyAddUnescapedPart / keyAddLiteralPart . لقد صنعت ذلك باستخدام استبدال regex شبه تلقائي بعد أن كتبت الاقتراح الأول.

ولكن في هذا الفرع ، تكون الوظائف الجديدة فقط #define s للوظائف القديمة ، لذلك لا يزال يتعين كتابة التنفيذ الفعلي ومن ثم يجب تحديث الاختبارات وربما مكونات التخزين الإضافية.

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

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

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

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

لذا يرجى السماح لنا بالتركيز على # 3447 (docu) ، وأخيراً إنجاز # 2969 ، وتحسين المكوِّن الإضافي TOML والموضوعات المهمة الأخرى التي نحتاجها لـ 1.0 (https://github.com/ElektraInitiative/libelektra/milestone/12 and https: // github.com/ElektraInitiative/libelektra/milestone/14). بمجرد أن يبدو هذا جيدًا ، يمكننا رؤية الأفكار الأخرى التي يمكننا تحقيقها.

بالنسبة لي ، فإن استنتاج هذه المناقشة هو أن هناك حاجة بالتأكيد للمكتبات لتسهيل كتابة مكونات إضافية للتخزين لأن نهج المكون الإضافي لم يعمل (باستثناء ما هو ثنائي يجب رؤيته). يجب أن يكون هذا الاستنتاج في البرنامج التعليمي للمكوِّن الإضافي للتخزين.
@ bauhaus93 هل يمكنك تولي المهمة لمتابعة البرنامج التعليمي

العلاقات العامة التي تدمر جميع ملحقات التخزين باستثناء واحدة غير قابلة للدمج.

لم أكن أتوقع أن يقوم أي شخص بدمج مثل هذه العلاقات العامة ... لقد قلت للتو أنه سيكون من الجيد أن يساعد الأشخاص الآخرون في تحديثات مكونات التخزين الإضافية. من الناحية المثالية ، المؤلف الأصلي للمكوِّن الإضافي. بعد # 3491 ، ستتم إزالة بعض ملحقات التخزين الأكثر تعقيدًا على أي حال ، وبالتالي ستكون المهمة بأكملها أسهل.

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

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

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

مع بعض التحسينات ، قد يكون الأمر أفضل من الوضع الراهن ، لكنني ببساطة لا أرى كيف يمكننا إدارة مثل هذه المهمة الكبيرة مع العديد من المهام المفتوحة الملحة الأخرى التي لدينا الآن.

لم أتوقع أن يتم اعتماد هذا الاقتراح على الفور. لكن أعتقد أنه يجب علينا بالتأكيد التفكير في تنفيذه قبل الإصدار 1.0. بمجرد إصدار الإصدار 1.0 ، سيكون الاقتراح بمثابة تغيير كبير. لا أعتقد أن إصدار الإصدار 2.0 حتى بعد عام أو عامين من الإصدار 1.0 (فما باللك قبل ذلك) سيكون فكرة جيدة ، مع الأخذ في الاعتبار الجمهور المستهدف من Elektra.

لذا من فضلك دعنا نركز على # 3447 (docu) ، وأخيراً ننجز # 2969 ، وتحسين المكوِّن الإضافي TOML والموضوعات المهمة الأخرى التي نحتاجها لـ 1.0

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

بالنسبة لي ، فإن استنتاج هذه المناقشة هو أن هناك حاجة بالتأكيد للمكتبات لتسهيل كتابة ملحقات التخزين

👍

ما عدا ثنائي هو أن ينظر إليه

IMO ، حالة القيم الثنائية مختلفة جدًا. إنها ترجمة ذات قيمة رئيسية 1: 1 ، مثل العديد من الآخرين ( rgbcolor ، macaddr ، ipaddr ، إلخ) ، لذا فإن المكوّن الإضافي مناسب بالفعل هنا. ومع ذلك ، كما قلت ، يمكن أن تكون واجهة برمجة التطبيقات الإضافية الجديدة التي تتعامل مع مفتاح واحد فقط في الوقت نفسه بمثابة تحسين. ولكن يمكن إضافة ذلك بسهولة بعد الإصدار 1.0 لأنه لن يكون تغييرًا جذريًا إذا تم بشكل صحيح.

معظم -> يجب؟

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