Three.js: ملف Google Closure Compiler "externs" لـ three.js؟

لا ، ليس لدى three.js أي تبعيات خارجية ، لذا لم تكن هناك حاجة لشيء كهذا حتى الآن.

أعلم ، لكن من المفيد أيضًا للمشاريع الخاصة دمج THREE.js في بيئة قابلة للترجمة.

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

mrdoob ، تجد بعض الأمثلة على:

http://code.google.com/p/closure-compiler/source/browse/#svn٪ 2Ftrunk٪ 2Fexterns

أو

http://code.google.com/p/closure-compiler/source/browse/#svn٪ 2Ftrunk٪ 2Fcontrib٪ 2Fexterns

وما يلي مهم أيضًا:

http://code.google.com/closure/compiler/docs/js-for-compiler.html

تعليقات / رؤوس؟ أعتقد أن هذا سيجعل قراءة الكود أكثر صعوبة ...

نعم ، لكنني أعتقد أنه مخصص لهذا الملف الخارجي فقط وليس للكود بأكمله. يمكن للمرء أن يفعل ذلك ، لكنه ليس ضروريًا.

لقد جربته مع http://www.dotnetwise.com/Code/Externs/index.html . لكنها لا تعمل بشكل كامل مع Three.js. لم يتم استخراج كافة التعاريف.

هنا هو إدخال المدونة:

http://blog.dotnetwise.com/2009/11/closure-compiler-externs-extractor.html

يبدو أنه يدعم النمط this.method = function(){} ، لكن ليس النماذج الأولية ...

mrdoob ، ما هي توصيتك لدمج THREE.js في تطبيق خاص مع مُحسِّن متقدم لمجمع الإغلاق؟ هل صحيح أن هذا غير ممكن حاليا؟

بقدر ما أفهم أن المحسن المتقدم يتضمن فقط الفئات المستخدمة ، أليس كذلك؟ من الناحية النظرية يجب أن تعمل ... أليس كذلك؟

لم أحاول التحسين المتقدم باستخدام three.js ، لكنني أتذكر أشياء أخرى كانت تستخدم لكسر الشفرة. بشكل عام ، لم يكن الأمر "آمنًا" - مع التحسين الافتراضي البسيط ، فإنه يعمل دائمًا ، مع التقدم في بعض الأحيان لا يعمل.

إنه يكسر الكود إذا كنت تقوم بالتجميع كمكتبة ، ولكن كتطبيق (مع استدعاء الأساليب وكل ذلك) يجب أن يعمل ، أليس كذلك؟

mrdoob لاستخدام مكتبة https://github.com/mishoo/UglifyJS . لكني لم أجربها.

برامج الإغلاق الخارجية من Google عبارة عن ملف يصف كائنات كاملة سنستخدمها في التعليمات البرمجية المجمعة.
بدون مترجم الملف هذا ، يقوم فقط من أسماء الوظائف بشيء مثل a () أو b ().

على سبيل المثال ، هذا خاص بـ JQuery: http://code.google.com/p/closure-compiler/source/browse/trunk/contrib/externs/jquery-1.7.js

سيكون أمرًا رائعًا أن يكون الأشخاص الخارجيون لمدة ثلاثة شبيهات.

أنا ممتن مع ذلك ، لكن لا يمكنني التعامل معه بنفسي. سيحتاج شخص آخر إلى تصعيد هذا الأمر.

yurikor ، عند استخدام node.js ، يمكنك استخدام node-browserify و uglify-js معًا. ثم لا تحتاج إلى بناء أي شيء.

remoe شكرا جزيلا على النصيحة. سأحاول ذلك.

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

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

أيضًا ، لمنع مترجم الإغلاق من إعادة تسمية رموز الواجهة العامة الخاصة بي ، كان علي إضافة عدة أسطر من التعليمات البرمجية (هذه الوظائف الأربعة هي الوظائف العامة الوحيدة لمكتبتي). لاحظ أن مترجم الإغلاق يعيد تسمية جميع الخصائص التي تم الوصول إليها عبر blah.xyz ، لكنه لا يلمس أي خصائص تم الوصول إليها عبر blah["xyz"] .

أخيرًا ، كان السطر window['ColladaLoader2'] = ColladaLoader2 (لاحظ مرة أخرى استخدام سلسلة نصية) مطلوبًا لإخبار مترجم الإغلاق أنه يجب تصدير هذه الفئة إلى النطاق العام.

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

مرسل من هاتفي ، آسف لقواعد اللغة والتوتر.
في 12 شباط (فبراير) 2013 5:19 صباحًا ، كتب "Robert Carnecky" [email protected] :

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

بالنسبة لمشروعي ، قمت بإنشاء ملف بسيط يأتي
مع كتابة التعليقات التوضيحية والتي كانت مفيدة جدًا لأنها أتاحت الإغلاق
مترجم للتحقق من جميع الأنواع والعثور على اثنين من الأخطاء في الكود الخاص بي. أملك
إنشاء هذا الملف يدويًا. أنا أستخدم مترجم الإغلاق بشكل أساسي من أجل الخطأ
التحقق ، بالنسبة للتقليل الفعلي ، أستخدم الأقل قوة ولكنها آمنة
uglifyjs https://github.com/mishoo/UglifyJS.

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

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

-
يمكنك الرد على هذه الرسالة الإلكترونية مباشرةً أو عرضها على Gi tHubhttps: //github.com/mrdoob/three.js/issues/341#issuecomment -13426131.

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

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

كمثال ، يقوم الوضع البسيط بتحويل الكود التالي

function fn() {
    var foo = {}; // local variable, safe to rename this
    foo.bar();    // undefined property, will crash here
}
fn();

دون أي تحذيرات

function fn(){({}).bar()}fn();

والتي من الواضح أنها ستنهار على ({}).bar() . يُخرج الوضع المتقدم الكود التالي

({}).a(); // fn() inlined, private member 'bar' renamed to 'a'

الذي لا يزال يتعطل ، ولكن المترجم يعطي تحذيرًا أيضًا

Property bar never defined on foo at line 3 character 0.

• تم العثور على إغلاق الخلل من نوع الأخطاء حيث كان لدي خطأ إملائي في اسم الوظيفة أو حيث مررت THREE.Vector3 إلى Matrix4.makeTranslation بدلاً من ثلاثة أرقام منفصلة للمكونات x و y و z .
• إذا كانت لدي تغطية اختبارية كاملة (وهو ما لا أفعله) ، لكنت وجدت هذه الأخطاء عاجلاً أم آجلاً. في بعض الأحيان يصعب تصحيح الأخطاء ، إذا لم تظهر على الفور.
• إذا قدمت threejs ملف تصدير محدثًا مع كل إصدار جديد (جهد كبير للمحافظة عليه) ، فإن مترجم الإغلاق سيكتشف جميع المشكلات القادمة من واجهة برمجة التطبيقات المتغيرة (كما كان الحال بالنسبة لـ Matrix4.makeTranslation ).
• يعد إعداد مترجم الإغلاق الكثير من العمل بالنسبة لي ، لأنه يحتاج إلى وقت تشغيل جافا. تستند جميع الأدوات الأخرى اللازمة لبناء مكتبتي على العقدة / جافا سكريبت.

أقوم حاليًا بإنشاء ملف externs.js الخاص بمكتبة الإغلاق من أجل دمج تطبيق THREE.js مع Closure Library. ما نحاول اكتشافه في الأساس هو:
هل توجد قائمة في مكان ما بجميع فئات THREE.js وطرق النماذج الأولية التي تنفذها؟ يجب أن تكون القائمة شيئًا مثل هذا:

ثالثا: الملمس
ثالثا: الملمس
ثالثا ، الملمس ، الاستنساخ
ثالثا: الملمس
ثري. DataTexture.clone

(وما إلى ذلك وهلم جرا...)

Ps- تعد Three.js أمرًا رائعًا ، ولكن باستخدام jsDocs المناسب ، يمكن استخراج هذه القائمة بسهولة :)

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

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

taoeffect : التعليقات هي في الغالب للوضع المتقدم

crobi ، أوه التعليقات تؤدي إلى الكتابة القسرية؟ هذا رائع نوعًا ما ، لم أكن أعرف أنه فعل ذلك.

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

معظم التعليقات حول وضع التحسينات المتقدم للإغلاق غير دقيقة.

لمعالجة المشكلة الرئيسية ، يمكنك استخدام الأداة التالية لإنشاء مصادر خارجية للإغلاق تلقائيًا لأي مكتبة http://www.dotnetwise.com/Code/Externs/

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

--language_in=ECMASCRIPT5

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

يوم الإثنين ، 13 كانون الثاني (يناير) 2014 الساعة 12:31 مساءً ، رودريجو فورميغون <
[email protected]> كتب:

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

--language_in = ECMASCRIPT5

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/mrdoob/three.js/issues/341#issuecomment -32191167
.

تحياتي الحارة،
بن هيوستن
الصوت: 613-762-4113 سكايب: ben.exocortex تويتر:exocortexcom
http://Clara.io - إنشاء محتوى ثلاثي الأبعاد قائم على WebGL بمستوى احترافي

أعتقد أنني قد أكتب مثل هذا المنشور. فقط للتوضيح ، على الرغم من ذلك ، فإن السبب وراء رغبة المرء في تشغيل Three.js من خلال الإغلاق (مع أو بدون ملف خارجي) ليس بالضرورة لتحسين الأداء فقط. يهدف الإغلاق بشكل أساسي إلى مساعدتك في كتابة تعليمات برمجية قابلة للصيانة في JavaScript (خاصة ، قواعد التعليمات البرمجية الكبيرة جدًا). الهدف هو مساعدة المطورين على "ترويض" JavaScript (كتابة JS الأصلية) ، بدلاً من "تجنبها" (باستخدام GWT أو أدوات أخرى مماثلة). إذا حاولت ببساطة تجميع Three.js كجزء من مشروع Closure ، فقد يصرخ المترجم عليك لأن Three.js قد لا يتوافق مع بعض معاييره (ليست JSDoc كافية ، ربما؟). يؤدي استخدام علامة المترجم --language_in إلى حل هذه المشكلة اعتبارًا من الآن ، على الرغم من أنك ستتلقى بعض التحذيرات. إذا كنت ترغب ببساطة في تجميع كود JS الخاص بك ، ولكن قم بالإشارة إلى Three.js كمكتبة خارجية (وبالتالي ترك جميع التعليمات البرمجية الخاصة بـ Three.js دون تغيير أو تحسين) ، فستحتاج إلى ملف externs المذكور أعلاه. بدون ملف externs ، ستلقي Closure أخطاء تجميع تقول أن THREE. * لم يتم التصريح عنها في أي مكان ، وما إلى ذلك.

على الرغم من أنني لا أتمكن من كتابة منشور المدونة الخاص بي لشرح كيف ولماذا قد يرغب المرء في استخدام Three.js في مشروع Closure ، فإليك أفضل عرض تقديمي تمهيدي حول أدوات Google Closure رأيته: (من Google I / O 2011) https://www.youtube.com/watch؟v=M3uWx-fhjUc (أعلم أنه مقطع فيديو طويل ، ولكنه يوضح حقًا ما هو الغرض من المترجم ، وما تفعله أوضاع الترجمة المختلفة بالفعل. كما أنه يصف لماذا تحتاج إلى ملف externs).

مرحبًا ، أنا أتطلع إلى تطوير تطبيق باستخدام three.js ، ولذا أرغب في دعم خيارات ADVANCED_OPTIMIZATIONS.

تعمل إزالة التعليمات البرمجية الميتة بقوة عندما يستخدم تطبيق التضمين جزءًا فقط من وظائف Three.js.

في الوقت الحالي ، تتطلب three.js تطوير كل وظيفة واحدة ، لأن الاستخدام المقصود يقتصر على "تتطلب فقط three.min.js!". هذا الأسلوب الكلاسيكي سهل الفهم ، ولكن بالنسبة للرموز المكتوبة بواسطة هذا الأسلوب ، يمكن أن تقلل أدوات تصغير JavaScript الشفرة الحجم فقط عن طريق تقليص أسماء المتغيرات (غير فعال لأسماء المتغيرات القصيرة) ، وإزالة المسافات (فعالة فقط للمسافات البادئة ، وعلامات التبويب وفواصل الأسطر) وغيرها من الحيل الرخيصة.

باستخدام خيار ADVANCED_OPTIMIZATIONS إلى رمز "Closure compiler style" ، يمكنه إزالة "الرموز غير المطلوبة" بالكامل ، والتي غالبًا ما تزن المكتبات الكبيرة. أصبحت المكتبات مثل Closure library كبيرة ، لكن مستخدمي المكتبات والمطورين لا يهتمون بها لأنهم يعلمون أنه ستتم إزالة معظم الكود في مرحلة التجميع.

نظرًا لأن three.js مكتوبة بالفعل بأسلوب موجه للكائنات ، أعتقد أنه ليس من الصعب (من الناحية الفنية) تحديث الكود بالكامل إلى كود "Closure compiler style". الأشياء التي أقلق بشأنها ...

• يتطلب أسلوب مترجم الإغلاق التعليقات التوضيحية لكل وظيفة. حاليا ، لا يوجد أي منهم. كم من الوقت ستستغرق إضافة التعليقات التوضيحية إلى جميع الوظائف التي تم تطويرها على الإطلاق؟
• يتطلب مترجم الإغلاق تعريفات صارمة للنوع. حتى بالنسبة لـ null و undefined ، يجب أن تعمل معهم بشكل صحيح. قد يكون عملاً شاقًا للوظائف التي تحتوي على معلمات "مسموح بها خالية" ، ومعلمات "غير مسموح بها" ، ...
• يجب أن تعد ملفًا خارجيًا مناسبًا ، إذا كنت تتطلع إلى إعداد "مكتبة ذات إصدار كامل" تم تجميعها بواسطة ADVANCED_OPTIMIZATIONS.

Hai Schedul Xor ،

هذه فكرة جيدة. هل يمكنك مشاركة مقتطف صغير حول كيفية القيام بذلك
هذا يجب أن يضاف إلى three.js؟

مع تحياتي

رامسوندار مادهافان

يوم الثلاثاء ، 24 يونيو 2014 الساعة 4:23 مساءً ، مجدول Xor [email protected]
كتب:

مرحبًا ، أتطلع إلى تطوير تطبيق باستخدام three.js و
لذلك الرغبة في دعم خيار ADVANCED_OPTIMIZATIONS.

تعمل إزالة التعليمات البرمجية الميتة بقوة عندما يستخدم تطبيق التضمين فقط
جزء من وظائف Three.js.

حاليًا ، تتطلب three.js تطوير كل دالة على حدة ، لأن ملف
يقتصر الاستخدام المقصود على "تتطلب فقط three.min.js!". هذا كلاسيكي
النهج سهل الفهم ، ولكن بالنسبة للرموز المكتوبة بواسطة هذا الأسلوب ،
يمكن أن تقلل أدوات تصغير JavaScript حجم الشفرة فقط من خلال تقليص أسماء المتغيرات
(غير فعال لأسماء المتغيرات القصيرة) ، وإزالة المسافات (فعالة فقط
للمسافات البادئة وعلامات التبويب وفواصل الأسطر) وغيرها من الحيل الرخيصة.

باستخدام خيار ADVANCED_OPTIMIZATIONS إلى "نمط مجمع الإغلاق"
رمز ، يمكنه إزالة "الرموز غير المطلوبة" بالكامل ، والتي غالبًا ما تكون أوزانًا
مكتبات كبيرة. مكتبات مثل Closure Library
https://developers.google.com/closure/library/ أصبح كبيرًا ، لكن
لا يهتم مستخدمو المكتبة والمطورون بها لأنهم يعرفون ذلك
ستتم إزالة معظم الكود في مرحلة التجميع.

نظرًا لأن three.js مكتوبة بالفعل بأسلوب موجه نحو الكائنات ، أعتقد أنه
ليس من الصعب (من الناحية الفنية) تحديث الكود بأكمله إلى "Closure compiler
رمز على غرار ". الأشياء التي أقلق بشأنها ...

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/mrdoob/three.js/issues/341#issuecomment -46957189.

@ Schedul-xor نحن بالتأكيد بحاجة إلى المساعدة في ذلك ... هل الكود anontations مطلوب حقًا أم أنه كافٍ مع الخارجين؟

أهلا،

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

مع تحياتي

رامسوندار مادهافان

في الثلاثاء ، 24 يونيو 2014 الساعة 7:23 مساءً ، كتب Mr.doob [email protected] :

@ Schedul-xor https://github.com/schedul-xor نحن بالتأكيد بحاجة إلى المساعدة
مع ذلك ... هل الكود anontations مطلوب حقًا أم أنه يكفي
الخارجون؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/mrdoob/three.js/issues/341#issuecomment -46973166.

ضع في اعتبارك أن التحسينات المتقدمة تتطلب أسلوب ترميز معين أو أنها ستكسر الكود الخاص بك. على سبيل المثال ، تمزج Three.js بين uniforms["diffuse"] و uniforms.diffuse ، وهو أمر غير مسموح به في ظل التحسينات المتقدمة للإغلاق. أنظر أيضا # 3222.

تعد إضافة التعليقات التوضيحية من النوع الصارم في كل مكان قدرًا كبيرًا من العمل ، وتضيف الكثير من سطور التعليقات (في مشروعي ، أدت إلى زيادة عدد الأسطر بمقدار 2).

من الجيد وجود ملفات خارجية لأطر / لغات الويب الأخرى.

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

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

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

نظرًا لأن Three.js مشروع كبير ، فأنا أتساءل أين يجب أن أعمل أولاً. سيكون من الأفضل البدء بما يمكن القيام به بسهولة.

ماذا عن وضع رؤوس الملفات وتغيير نمط تعريف الوظيفة لكل وظيفة؟

THREE.Material = function(){
  :
};
THREE.Material.prototype = {
    constructor: THREE.Material,
    setValues: function ( values1, value2 ) {}
    getValues: function () { return this.a; }
    :
};

↓

goog.provide('THREE.Material'); ← Write goog.provide('package.classname') at the first line

← three empty lines before <strong i="10">@constructor</strong>

/**
 * <strong i="11">@constructor</strong> ← Add <strong i="12">@constructor</strong> annotation to constructor
 */
THREE.Material = function(){
  :
};

← two empty lines before function definition
/**
 * <strong i="13">@param</strong> {!Array.<!string>} values1 Values1 explanation ← values1 is an array of strings. values1 can't be null, and elements inside values1 can't be null.
 * <strong i="14">@param</strong> {!number} value2 Value2 explanation ← value2 is a number.
 */
THREE.Material.prototype.setValue = function(values1, value2){
  goog.asserts.assertArray(values1);
  goog.asserts.assertNumber(value2);
  :
};


/**
 * <strong i="15">@return</strong> {!number} ← This function returns a non-null number.
 */
THREE.Material.prototype.getValue = function(){
  return this.a;
};

سيكون من الأسهل تقييد جميع أنواع المعلمات وإرجاع أنواع القيم إلى non-null. هذا سيجعل الأمر أسهل بكثير لتمرير أخطاء التحويل ADVANCED_OPTIMIZATIONS.

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

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

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

أخيرًا ، نقل مثل هذا المشروع الكبير مثل three.js إلى أي لغة / إطار عمل / أسلوب ترميز آخر أمر يجب مناقشته بالتفصيل.

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

آسف ، لا استطيع الانتظار. سأفترق الالتزام الحالي وأبدأ في النقل.

أهلا،

هل من الممكن أتمتة إضافة هذه التعليقات التوضيحية؟ إذا كان الأمر كذلك ، فيمكننا إضافتها
to build.py وإضافتها قبل تمكين التحسين المتقدم للإغلاق.

مع تحياتي

رامسوندار مادهافان

يوم الأربعاء 25 حزيران (يونيو) 2014 الساعة 6:05 صباحًا ، مجدول Xor [email protected]
كتب:

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

آسف ، لا استطيع الانتظار. سأفترق الالتزام الحالي وأبدأ في النقل.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/mrdoob/three.js/issues/341#issuecomment -47047966.

@ ramsundhar20 ، في رأيي ، فإن إضافة التعليقات التوضيحية (غير دقيقة؟ أفضل من لا شيء. ليست مشكلة كبيرة. يمكن تحديثها) أولاً سيجعل التشغيل الآلي أسهل بكثير.

يحتوي Three.js حاليًا على 163 ملف جافا سكريبت مع تحديد 1354 وظيفة. نعم إنه ضخم ، لكنه ليس هدفًا بعيد المنال.

// أنا خائفة إذا كان هذا الموضوع في غير محله ...

@ Schedul-xor مرة أخرى ، لست من المعجبين حقًا بوجود تعليق لكل وظيفة: /

mrdoob حسنًا ، فهمت.

احترامًا لسياستك ، أود إضافة تعليقات لكل وظيفة فقط في مفترقتي. أيضًا ، لن أقدم أي طلبات سحب مطلقًا. بدلاً من ذلك ، سأقوم بنقل تعديلات three.js الأصلية إلى شوكة الإغلاق الخاصة بي. سيكون موضع تقدير النظر الخاص بك.

هذا يبدو جيدا :)

شكرا لك! سأبدأ العمل عليها.

هل يوجد على الأقل ملف externs base three.js لاستخدامه مع برنامج التحويل البرمجي للإغلاق؟ لا يتطلب ذلك أن يكون لشفرة المصدر Three.js أي تعليقات توضيحية إضافية على نمط google ، هذا فقط لجعل الارتباط من تطبيق خارجي.

أنا أيضًا مهتم جدًا بجودة ملف خارجي كامل لـ three.js. هذه واحدة ، لكنها ليست كاملة:

https://github.com/cljsjs/packages/blob/master/three/resources/cljsjs/three/common/three.ext.js

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

نعم ، احسب تصويتي. مثالي للوضع المتقدم القابل للتجميع ، ثلاثي js مكتوب بنسبة 100٪ - أو ملف خارجي على الأقل.

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

لن تؤدي الإعدادات فائقة القوة ، وهي الوضع المتقدم + ضغط JS + التحسينات المستندة إلى النوع ، إلى إزالة التعليمات البرمجية الميتة فحسب ، بل يمكنها أيضًا القيام بكل الأشياء الرائعة التي يمكن أن يقوم بها المترجم المحسن:

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

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

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

لا أجد الفرع المذكور أعلاه. هل لا يزال أي شخص يعمل على نسخة مطبوعة؟

mrdoob أي أمل في تغيير

يسعدني تقديم المساعدة.

mrdoob أي أمل في تغيير

في الوقت الحالي ، أركز على إعادة هيكلة WebGLRenderer 😇

يمكن تغيير الثوابت إلى const بدلاً من var ولديه دعم جيد لجميع متصفحات WebGL https://kangax.github.io/compat-table/es6/ (const-> basic) و js بدأت المحركات في التحسين مقابل const تسريع الثوابت العالمية باستخدام تحسين المجال الثابت

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

العودة إلى دعم مترجم الإغلاق: قمت ببعض القراءة والتجريب. هذا ما اكتشفته:

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

هناك ثلاث حالات استخدام مختلفة:

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

يتطلب الملف الثالث ملفًا خارجيًا لجميع ملفات Three.js وهو يتطلب الكثير من العمل لتحقيق فائدة قليلة جدًا من IMO. لذلك سأناقش الأولين فقط - فهذه هي المفضلة ، على أي حال:

عندما يرى المترجم

anObject['aProperty']

لن يلمس اسم الخاصية (لم يتم تغيير أي سلاسل على الإطلاق).

anObject.aProperty

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

ها هي الوصفة:

• نجعل اللودر يصل باستمرار إلى الخصائص باستخدام تدوين النقطة.
• نكتب الإدخال ونكتب ملف خارجي فقط لـ JSON .
• يجب أن يكون التجميع باستخدام ملف externs هذا هو كل ما يلزم لتشغيل حالة الاستخدام 2.
• بالنسبة لحالة الاستخدام 1 ، لا نستخدم ملف externs ، ولكن بدلاً من ذلك نزيل علامات الاقتباس من مفاتيح الكائن في JSON:

{
    "camera": {
        "object": {
    // ...

سيصبح ببساطة

{
    camera: {
        object: {
    // ...

بسيط جدا ، أليس كذلك؟

تصبح حالة الاستخدام 1 أكثر جاذبية عندما يسمح تنسيق JSON ببيانات ثنائية خارجية (خام أو مضغوطة عبر webgl-loader أو o3dgc) - من الناحية الفنية ميزة أخرى متعامدة تمامًا لدعم الإغلاق ، بالطبع.

يمكن أن يحل ملف externs أيضًا محل صفحات Wiki القديمة التي توثق تنسيق الملف :-).

أعلم أن هذه المشكلة قد تم إغلاقها لبعض الوقت. ومع ذلك ، فقد واجهت مؤخرًا نفس المشكلة باستخدام three.js ضمن مشروع مترجم الإغلاق وهبطت في هذه الصفحة. لقد كتبت أداة تحول .d.ts (ملفات التصريح المطبوع عليها) إلى ملف مجمع الإغلاق. باستخدام الأداة والملف الموصوف الرائع DefinitelyTyped / threejs ، فإنه يعمل بشكل مثالي.
الأداة: https://github.com/eredo/tsd2cce أو التثبيت عبر npm install -g tsd2cce

أتمنى أن يساعدك هذا...

eredo الذي

eredoCorkle أو أي شخص آخر، يمكنك تبين لنا كيفية استخدام tsd2cce ؟ من الواضح أن الوسيط الأول هو ملف تعريف .d.ts ، لكن ما هو الوسيط الثاني؟ أنا أتلقى هذه المشكلة. https://github.com/eredo/tsd2cce/issues/6

في الواقع لقد وجدت أن استخدام r73 d.ts من فبراير يعمل بشكل جيد مع tsd2cce ، فإن r73 قديم جدًا بالنسبة لي رغم ذلك.

الطريقة الصحيحة للقيام بذلك الآن هي استخدام tsickle للتوليد من ملفات d.ts.

مرحبا جميعا،

من أجل الأجيال القادمة ومصلحة الجميع ، قررت الإبلاغ هنا عن محاولاتي لتقليص حجم المكتبة بشكل أكبر باستخدام ADVANCED_OPTIMIZATIONS من Google Closure Compiler وبعض التعديلات الأخرى.

لقد قمت بإنشاء extern.js الذي يسمح لـ Three.min.js مع تشغيل التحسينات المتقدمة. إنه بعيد عن الكمال.

لإنشائه ، بدأت مع extern.js بناءً على أمثلة سابقة في هذا الموضوع. تم كسر المكتبة عند تجميعها بهذه الطريقة بسبب الخصائص المشوهة التي لم يتم تضمينها في هذا الملف الخارجي. باستخدام الخيار --property_renaming_report في مترجم الإغلاق ، حصلت على القائمة الكاملة للخصائص المشوهة. بعد إضافة جميع هذه الخصائص إلى extern.js ، لم تعد الخصائص مشوهة وكان الناتج هو نفسه SIMPLE_OPTIMIZATIONS. من هناك بدأت بشكل انتقائي / يدويًا في التعليق على أقسام extern.js والتأكيد على أن المكتبة لا تزال تعمل في شكل مصغر.

أود أتمتة هذا التخمين والتحقق والحصول على extern.js مثالي يغير بأمان أكبر عدد ممكن من أسماء الممتلكات. خطرت لي فكرة استخدام اختبارات الوحدة لـ THREE.JS وتحديد برمجي أي من أسماء البروتوكولات المشوهة أدت إلى اختبارات فاشلة ، ولكن لا يبدو أنه من الممكن تشغيل اختبارات الوحدة من سطر الأوامر حاليًا ، على سبيل المثال مع phantomjs. (ربما بسبب WebGL)؟

في كلتا الحالتين ، يعد هذا "تقدمًا" نحو مكتبة مصغرة مصغرة ، مما يساعدني في تقليل حجم جافا سكريبت SPA الإجمالي.

externs.js

تم تحديث الأمر package.json build-stop

لقد استخدمت أيضًا أوامر استبدال السلسلة لإزالة جميع رسائل خطأ console.warn و console.error من المكتبة ، كما ترون في أمر الإنشاء-الإغلاق. مع هذا ، والتعليق على أقسام معينة من الكود ، قمت بتقليص lib المصغر بنحو 20٪ حتى الآن ، وهناك مجال للتحسين.

mrdoob عند القيام بشيء مثل أسلوبي هنا ، يمكنك في النهاية توفير extern.js الذي يسمح بـ ADVANCED_OPTIMIZATIONS دون تشويش التعليمات البرمجية بالتعليقات التوضيحية الخاصة بهذا المترجم ، والذي يبدو أنه شاغلك الأساسي.

@ medmr1 رائع! هل حاولت تجميع تطبيقك باستخدام مكتبة three.js كلها في واحد؟ هذا من شأنه أن يمنع الحاجة إلى ملف خارجي بشكل مثالي.

لم أحاول بناء كل شيء داخل الإغلاق ، لا. قد يعمل ذلك بشكل جيد ولكني أظن أنه ستظل هناك مشكلات فيما يتعلق بتشويه بعض الخصائص المشار إليها برمجيًا؟ أشياء مثل var thing = ShaderLib[ shaderType + "BumpMapFrag"] لكن ربما سأوفر على نفسي الكثير من المتاعب؟

نعم ، شيء مثل var thing = ShaderLib[ shaderType + "BumpMapFrag"] سيتوقف عن التحسينات المتقدمة. يجب أن تكون مراجع الخصائص قابلة للتحليل بشكل ثابت. يمكنك فعل شيء مثل:

function(shaderType) {
  if (shaderType == "a") {
    return ShaderLib.aBumpMapFrag;
  }
  if (shaderType == "b") {
    return ShaderLib.bBumpMapFrag;
  }
...

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

بدلاً من الخارجيين ، يمكنك أيضًا تجربة التعليق التوضيحي export .
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#export -export-someype