سأتصل بـ dibs على بقية مجلد الصوت

مرحبًا mrdoob ، هل يمكنك من فضلك توضيح كيف تريد منا أن نتعامل مع البرامج النصية داخل مجلد الأمثلة؟

يعجبني # 19989 الانتقال مباشرة للتحويل ولكني أدرك في القيام بذلك لم يعد من الممكن استخدام $ # utils/modularize.js examples/js دون الكتابة فوق هذا العمل. هل يمثل هذا نهاية احتفاظنا بـ examples/js وبداية examples/jsm فقط؟

تحرير: انظر التعليق

هل يمكنني العمل على باقي مجلد الرياضيات؟

هل يمكنني العمل على باقي مجلد الرياضيات؟

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

DefinitelyMaybe سأرى ما الذي يمكن ترحيله أيضًا تحت src/animation/

جزء من src/core : https://github.com/mrdoob/three.js/pull/20008

لطيف. أعتقد أن هذا المجلد على وشك الانتهاء. قد تكون فقط src/core/Object3D.js و src/core/BufferGeometry.js متبقية؟

قد تكون فقط src/core/Object3D.js و src/core/BufferGeometry.js متبقية؟

نعم ، هناك الكثير من فئات ES5 تعتمد على Object3D و BufferGeometry .

العارضين: https://github.com/mrdoob/three.js/pull/20011

شوت ، كان هناك بعض التقدم المذهل في هذا 🎉

سيتم استدعاء dibs على src/lights . عند فتح src/extras و src/renderers في القائمة أعلاه ، اتضح أن هناك مجلدين في كل منهما للعمل من خلاله.

مرحبا جميعا،

ماذا كنا نفعل بخصوص هذا النمط؟

foo.prototype = Object.assign( Object.create( bar.prototype ), {
    ...
    isDirectionalLight: true,
    ...
} );

هل الان:

class foo extends bar {
  static isDirectionalLight = true;
  constructor(  ) {
    ...
  }
}

أو

class foo extends bar {
  constructor(  ) {
    this.isDirectionalLight = true;
  }
}

حاليًا ، كنت أقوم بالثانية ولكن بالنظر إليها ، سأقول أن القصد من ذلك ربما كان أقرب إلى الأول.

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

class foo extends bar {
  constructor(  ) {
    this.isDirectionalLight = true;
  }
}

☝️ هذا صحيح. isDirectionalLight مثال جيد ، يتم استخدامه على النحو التالي:

$ git grep 'isDirectionalLight\b' src/ examples/js ':!*.ts'
examples/js/exporters/GLTFExporter.js:                  if ( light.isDirectionalLight ) {
examples/js/exporters/GLTFExporter.js:                  } else if ( object.isDirectionalLight || object.isPointLight || object.isSpotLight ) {
examples/js/renderers/SVGRenderer.js:                   } else if ( light.isDirectionalLight ) {
examples/js/renderers/SVGRenderer.js:                   if ( light.isDirectionalLight ) {
src/lights/DirectionalLight.js: isDirectionalLight: true,
src/renderers/webgl/WebGLLights.js:                     } else if ( light.isDirectionalLight ) {

ومع ذلك ، يمكن أن تكون هناك مكاسب في الأداء من خلال الاحتفاظ ببعض خصائص النموذج الأولي ...

class foo extends bar {
}
foo.prototype.baz = heavyThing;

ربما يمكننا مراجعة هؤلاء في العلاقات العامة على أساس كل حالة على حدة.

سآخذ لقطة عند src/renderers/webgl 👍 👍

حظ جيد استمتع. هذا ما يحدث فيه بعض الشيء

webxr: https://github.com/mrdoob/three.js/pull/20038

مرحبًا بالجميع - لقد تم تحويل src/renderers/webgl . لقد كان جنونيا. سأستمر في مراجعة كل شيء وانتظر # 20039 قبل أن أبدأ في دفع العلاقات العامة.

👍
نتطلع إلى ذلك

لقد لاحظت أن yomotsu تستخدم أدوات القراءة فقط مقابل خصائص is* في العلاقات العامة للرياضيات ... ربما هذا هو الأفضل!

class foo extends bar {
  get isDirectionalLight() {
    return true;
  }
}

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

عرض حالة jsfiddle سريع

يبدو أن هذا هو الطريق للذهاب:

foo.prototype.isDirectionalLight = true;

سوف ننظر في src/objects . سأرى إلى أي مدى يمكنني الوصول دون كسر الأشياء.

اكتمل مجلد الرياضيات للتو.
( يتم استبعاد فئات أقحم. )

مرحبا جميعا،
سأقوم بالتراجع عن العمل من خلال src/objects ، شخص آخر مرحب به لاستلامه في هذه الأثناء.

مرحبًا ، عمل جيد مع هؤلاء الرجال! 💪

مشكلة واحدة فقط ، foo.prototype.isDirectionalLight = true; لا تسمح بهز الشجرة ، نظرًا لتعديل الفصل في مكانه.
في هذه المرحلة أيضًا ، أود أن أقترح بشدة عدم لمس النموذج الأولي بعد الآن لأننا نستخدم الفصول الآن ويمكن استخلاص النموذج الأولي.

ماذا عن هذا النمط؟ يبدو أكثر وضوحا بالنسبة لي.

constructor( x = 0, y = 0, z = 0 ) {

  Object.defineProperty( this, 'isVector3', {
    value: true,
    enumerable: false,
    writable: false,
    configurable: false,
  } );

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

constructor( x = 0, y = 0, z = 0 ) {

  Object.defineProperty( this, 'isVector3', { value: true } );

marcofugaro ، النسخة القصيرة تبدو جيدة بالنسبة لي 👍

حسنًا ، فعل العلاقات العامة.

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

يمكنني تحديث خط أنابيب البناء لاستخدام @ rollup / plugin-babel الأكثر شيوعًا

يمكنني تحديث خط أنابيب البناء لاستخدام @ rollup / plugin-babel الأكثر شيوعًا
وإصلاح هذه المشكلة إذا كنتم تريدون ذلك.

نعم ، سيكون رائعًا إذا كان بإمكانك إجراء العلاقات العامة 🙏

marcofugaro ، mrdoob yay! نعم من فضلك

مرحبًا بالجميع ، تنبيه سريع لقد قمت بتحديث # 20014 بـ Object.defineProperty وقمت أيضًا بإصلاح التصنيف الفرعي لـ AnimationClip . إذا كان لدى أي شخص الوقت لمراجعته ، سأكون ممتنًا 👀 🙇 🙇

تمام. الآن بعد أن خرج r120 ... هل يمكن لأي شخص أن يتحقق من أن الأشياء تهز الأشجار بشكل صحيح؟

يبدو أنه يعمل نوعا ما بالنسبة لي ، ولكن قليلا.
لم أعد أرى ArrowHelper في ملف الحزمة الخاص بي باستخدام حزمة الويب. لكن العديد من الأكواد غير الضرورية لا تزال موجودة😢

ماذا عن حجم الحزمة؟ قبل وبعد

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

$ shakediff builds/three.module.js Color

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

$ shakediff build/three.module.js Color | diffstat 
 three.module.js | 2878 --------------------------------------------------------
 1 file changed, 1 insertion(+), 2877 deletions(-)

لا توجد حزمة حاليًا ، ولكن يمكنك تثبيتها من الريبو الخاص بي إذا كنت ترغب في تجربتها. نقدر ردود الفعل! ✌️

npm -g i ianpurvis/shakediff.git

مرحبًا mrdoob ، هل يمكنك من فضلك توضيح كيف تريد منا أن نتعامل مع البرامج النصية داخل مجلد الأمثلة؟
يعجبني # 19989 الانتقال مباشرة للتحويل ولكني أدرك في القيام بذلك أنه لم يعد من الممكن استخدام utils / modularize.js في مجلد الأمثلة / js دون الكتابة فوق هذا العمل. هل هذا يشير إلى نهاية احتفاظنا بالأمثلة / js وبداية أمثلة / jsm فقط؟

ما هو الحكم على هذاmrdoob؟ هل من المنطقي جعل jsm مصدر الحقيقة حتى نتمكن من تحويل الأمثلة إلى فئات ES6؟ ربما يمكننا جعل utils / demodularize.js لدعم التحويل في الاتجاه الآخر؟

ستتم إزالة المجلد examples/js في ديسمبر 2020. حتى ذلك الحين ، يجب أن نترك المجلد كما هو ، دون ترقية محتوياته - أو ملفات examples/jsm التي تم إنشاؤها من محتوياته - إلى ES6 Classes. بعد ذلك التاريخ ، ستصبح ملفات examples/jsm مصدر الحقيقة ، ويمكن تحديثها إلى فئات ES6.

لقد لاحظت أنه لا تتم إزالة متغيرات نطاق الوحدة أثناء الاهتزاز. يمكنك أن ترى السلوك مع هذه المتغيرات الأربعة ، build/three.module.js:43059

const _position$3 = new Vector3();
const _quaternion$4 = new Quaternion();
const _scale$2 = new Vector3();
const _orientation$1 = new Vector3();

يبدو أننا يجب أن نضع علامة على هذه الصور نقية مع التعليق الخاص-

const _position = /*@__PURE__*/ new Vector3();

هل هذا يعمل للجميع؟

يبدو جيدا بالنسبة لي 👌

رائع ، هذا يحذف 144 سطرًا آخر عند اهتزاز الشجرة بـ Color 🥳

يرجى من الجميع إعطاء العلاقات العامة المفتوحة معاملة /*@__PURE__*/ عندما يكون لديك الوقت!

ianpurvis عظيم! هل تستخدم التراكمي ، أليس كذلك؟ هل يمكنك مشاركة التكوين الخاص بك؟

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

اختبرت هذا الرمز

import * as THREE from 'three'

console.log(THREE.WebGLRenderer)

0.119.1

0.120.1

لذلك هناك شيء ما يجري تهزه بالأشجار ، عظيم!

بالنظر إليها أكثر ، يبدو أن الفئة AudioListener ليست في الحزمة ، خبر رائع!

يقوم Webpack أيضًا تلقائيًا بإزالة المتغيرات غير المستخدمة التي أشار إليهاianpurvis.

بعد ذلك ، قررت اختبار الأساليب الثابتة المحددة خارج الفصل

ولسوء الحظ ، هذا يجعل الطبقة غير قابلة للاهتزاز بالأشجار

بعد إجراء المزيد من عمليات البحث ، لاحظت أن فئات الهندسة مثل DodecahedronGeometry ، والتي لم يتم استخدامها في أي مكان ، كانت لا تزال في الحزمة

اكتشفت لاحقًا أن هذا كان بسبب هذا العنصر Geometries three.module.js

والذي يتم إنشاؤه تلقائيًا عند استخدام أنماط مثل هذه في ObjectLoader . من المحتمل أن يختفي هذا عندما نجني ObjectLoader للفصل ، و src/geometries سيكون قابل للاهتزاز بالأشجار.

marcofugaro https://github.com/mrdoob/three.js/pull/20239

marcofugaro لا مشكلة ، ها هو ملف التكوين التراكمي

marcofugaro مرحبًا ، أضفت دعم webpack إلى shakediff ... هل يبدو تكوين webpack هذا جيدًا بالنسبة لك؟ نظرًا لأن terser مسؤول عن إزالة الشفرة الميتة في اهتزاز شجرة webpack ، فمن الصعب منع بعض عناصر التحويل في تلك المخرجات. ولكن إذا قمت بالاختلاف باستخدام خوارزمية مدرج تكراري مع تعطيل المسافة البيضاء ، فيمكن التحكم فيها. من اختبار سريع الليلة ، يبدو أن حزمة الويب تقبل كلاً من /*@__PURE__*/ و /*#__PURE__*/ . أعتقد أنه يمكننا توحيد أحدهما أو الآخر. المزيد غدًا ...

ianpurvis لا أعتقد أنه مسموح لي بتثبيت shakediff على جهازي ...

على أي حال ، أجريت اختبارًا بسيطًا:

import { WebGLRenderer } from './src/renderers/WebGLRenderer.js';
console.log( new WebGLRenderer() );

ولاحظت أن Geometry لم تهتز الأشجار. https://github.com/mrdoob/three.js/pull/20394 يعمل على إصلاحه.

ثم حاولت القيام بما يلي:

import { Vector3 } from './src/math/Vector3.js';
console.log( new Vector3() );

ولاحظت أن التراكمية لا تهز الشجرة بالطرق غير المستخدمة ... 😕

mrdoob لسوء الحظ ، في المستقبل المنظور ، لن تكون طرق الفصل الدراسي أبدًا قابلة للاهتزاز بواسطة أي أداة. هيك ، لا يمكن حتى تصغيرها!

هذا لأنه في جافا سكريبت ، يمكنك الوصول إلى طرق مثل this['I am a string'] ، تمامًا مثلما يمكنك الوصول إلى خصائص الكائن ديناميكيًا. لهذا السبب ، لا تعرف الأدوات مسبقًا ما إذا كنت ستستدعي طريقة (يمكن أن تكون this[variable] ).

هذا هو نفسه لكل من فئات ES6 وفئات الوظيفة. على سبيل المثال ، في three.min.js ، تُترك الطرق كما هي ، تمامًا مثل أي خاصية كائن 🙂

ولم يقترح أي شخص وضع "صارم" للمُنشئ ، حيث يُتوقع منك عدم استدعاء طرق مثل this['I am a string'] ؟

لا فكرة 🤷‍♂️

هنا مناقشة حول هذا الموضوع بخصوص التراكمي: https://github.com/rollup/rollup/issues/349

لن تكون طرق الفصل أبدًا قابلة للاهتزاز بأي أداة. هيك ، لا يمكن حتى تصغيرها!

نأسف للخروج عن الموضوع ، ولكن يمكنك الحصول على تصغير للعمل إذا أعطيت المترجم بعض التلميحات حول ما هو "عام" مقابل "خاص". في الماضي ، استخدمت البادئات "_" في طرق لهذا الغرض. راجع https://github.com/developit/microbundle/wiki/mangle.json. لكن ، لسوء الحظ ، ليس لدي أي فكرة أيضًا عما إذا كان أي شيء مشابه ممكنًا لهز الشجرة. 😕

ووه! تم دمج # 20395! الاشياء الجيدة @ marcofugaro

أخبار رائعة عن بابل والهندسة!

ianpurvis لا أعتقد أنه مسموح لي بتثبيت shakediff على جهازي ...

mrdoob Hm ، يبدو أن Parcel لديه اعتماد على هذا الإصدار من fsevents ... ربما يمكنني تثبيت ذلك على شيء أعلى.

لمعلوماتك ، معلومات جيدة هنا حول تحسينات اهتزاز الأشجار في Webpack 5 ...

لمعلوماتك ، معلومات جيدة هنا حول تحسينات اهتزاز الأشجار في Webpack 5 ...

تقدم ... آمل أن يقوم التراكمي بتنفيذ هذا أيضًا ...

أهلا بكم،

ما هي أهداف .is**Classname** property و this.type = **Classname** بالضبط؟
أليست بقية من نمط الطبقة الزائفة القديمة؟
لماذا لا تتخلص منه تمامًا وتستبدل هذا الاستخدام بطريقة التحقق من النوع العادي؟

obj instanceof Vector3  // prefer this one for inheritance
// or
obj.constructor === Vector3  // prefer this for no inheritance

أعني ، كجزء من الانتقال إلى فئات ES ، سيكون للكائنات أنواع صحيحة يمكن التحقق منها بالفعل ...

استخدمت المكتبة obj instanceof Vector3 من قبل.
لكن ريتش هاريس نفذ جميع الشيكات وغيّرها إلى is* للسماح بهز الشجرة: # 9310

استخدمت المكتبة obj instanceof Vector3 من قبل.
لكن ريتش هاريس نفذ جميع الشيكات وغيّرها إلى is* للسماح بهز الشجرة: # 9310

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

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

بطريقة مرئية ...

هذا النمط يجعل WebGLRenderer يشتمل دائمًا على Geometry عند التجميع:

import { Geometry } from '../core/Geometry.js';
import { BufferGeometry } from '../core/BufferGeometry.js';

if ( geometry instanceof Geometry ) {
} else if ( geometry instanceof BufferGeometry ) {
}

هذا النمط لا:

if ( geometry.isGeometry === true ) {
} else if ( geometry.isBufferGeometry === true ) {
}

مرحبا جميعا،

بالنظر إلى هذا ما هي أفكارنا للمضي قدمًا من هنا؟

لا أعتقد أن هناك أي تغيير ، حتى الآن. أي شيء (1) ليس في examples/js و (2) لا يتم تمديده بشيء في examples/js يمكن تحويله إلى ES6 Classes. إذا تم الانتهاء من هذه العملية ، فيجب أن نقرر متى نبدأ في تحويل examples/js إلى الفصول الدراسية.

من الذاكرة ، وبعد نظرة سريعة ، قمنا بعمل جيد ولا يزال هناك بعض العلاقات العامة جاهزة في الانتظار.

قد أحاول إعادة تجميع قائمة التبعيات / قائمة الأمثلة الموسعة.

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

تمام،
قد أبدأ بعض العلاقات العامة للحصول على أمثلة لإعادة الكتابة إلى فصول ES ...
mrdoob هل هي مشكلة بالنسبة لك عند تنفيذ البرنامج النصي jsm إلى js أم لا؟ (لا أعتقد ذلك ولكن أخبرني إذا كنت تفضل منا الانتظار)

قبل تحويل رمز المثال إلى فئات ، يجب أولاً دمج # 20527 أو # 20529 أو حل مختلف. باستثناء الكود الذي يفي بالشروط المذكورة في https://github.com/mrdoob/three.js/issues/19986#issuecomment -718308451.

DefinitelyMaybe قلت في التعليق الأول :

• استخدم حقول الفصل

1) هل يعني ذلك أنه يمكننا استخدام حقول الفصل في كل شيء؟
مثل ذلك :

class Light extends Object3D {

    type = 'Light';
    isLight = true;

    color = new Color;
    intensity = 1;

    constructor(color, intensity = 1) {

        super();

        this.color = new Color(color);
        this.intensity = intensity;

    }

    copy() {
        ...
    }
}

... أم أنها لخاصية .is* فقط؟

إذن ، 2) ماذا عن المنشئات الفارغة؟ ذكرت مواصفات ES2015 أن المُنشئين الذين لديهم استدعاء super() فقط يكون ضمنيًا إذا لم يتم توفيره ، لذلك يمكن تعريف بعض الفئات الفرعية بشكل أسهل:

class MapControls extends OrbitControls {

    screenSpacePanning = false; // pan orthogonal to world-space direction camera.up

    mouseButtons = { LEFT: MOUSE.PAN, MIDDLE: MOUSE.DOLLY, RIGHT: MOUSE.ROTATE };

    touches = { ONE: TOUCH.PAN, TWO: TOUCH.DOLLY_ROTATE };

}

و 3) وماذا عن حقول الحصص الخاصة؟

class OrbitControls extends EventDispatcher {
    ...

    #offset = new Vector3();

    // so camera.up is the orbit axis
    #quat = new Quaternion().setFromUnitVectors( object.up, new Vector3( 0, 1, 0 ) ); <= this will go in constructor because of object.up
    #quatInverse = this.#quat.clone().inverse();

    #lastPosition = new Vector3();
    #lastQuaternion = new Quaternion();

    #twoPI = 2 * Math.PI;

    update() {
        ... ( no more closure and return function here )
    }

}

يدعم أحدث إصدار من Chrome كلاً من حقول الفصول الدراسية العامة والخاصة في الأصل ...

20395

المفتاح الأول هو اجتياز جميع الاختبارات.

ستواجه مشاكل أقل في البداية من خلال تقليل التغيير.

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

class EdgesGeometry extends BufferGeometry {

    constructor( geometry, thresholdAngle ) {

        super();

        this.type = 'EdgesGeometry';

تغير إلى:

class EdgesGeometry extends BufferGeometry {

    type = 'EdgesGeometry';

    constructor( geometry, thresholdAngle ) {

        super();

من المحتمل أننا سنواجه بعض المحاذير الأخرى حول المكان ، مثل كيف واجهت " new this.contructor() != new Foo() ".

مجالات الطبقة الخاصة

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

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

نعم يمكن القيام بذلك الآن. ومع ذلك ، لا يمكننا فعل ذلك لخصائص .is* حيث يجب أن تكون غير قابلة للتعداد وغير قابلة للكتابة ، بالنسبة لأولئك الذين يتعين علينا استخدام Object.defineProperty(this, ... .

كيف يتم فحصها مرة أخرى؟ هل يمكننا استخدام الكلمة الرئيسية static بدلاً من Object.defineProperty(this, ... ؟

كيف يتم فحصها مرة أخرى؟ هل يمكننا استخدام الكلمة الرئيسية static بدلاً من Object.defineProperty(this, ... ؟

لا أعتقد ذلك ، لأن obj.is* يجب أن يكون في النسخ ، وليس في الفصل نفسه ...

لست متأكدًا مما يمكن لـ babel transpile بالضبط في التكوين الحالي ، ولكن قد نستخدم الزخارف لتعيين حقل فئة على أنه غير قابل للعد / غير قابل للكتابة:

import { unwrittable, unenumerable } from 'some/decorator/helpers.js'

class Foo {
    @unwrittable<strong i="12">@unenumerable</strong>
    isFoo = true;
}

DefinitelyMaybe static خصائص مختلفة ، لا يمكن الوصول إليها من المثيل ، وليس من الفصل نفسه.

class Test {
  static staticProp = true

  constructor() {
    Object.defineProperty(this, 'definedProp', { value: true })
  }
}
const test = new Test()

console.log(test.staticProp, test.definedProp)

نتيجة:

undefined true

نقطتي الرئيسية هي أنه إذا أردنا تعديل الكود الذي يتحقق من هذه الخاصية ، فيمكننا الانتقال من:

class Test {
  constructor() {
    Object.defineProperty(this, 'definedProp', { value: true })
  }
}

ل

class Test {
  static definedProp = true
  constructor() {
  }
}

لذلك كنت أتساءل أين ولماذا يتم إجراء هذا الفحص وما إذا كان بإمكاننا تغييره أم لا.

DefinitelyMaybe تكمن المشكلة في الحصول على معلومات من نوع مثيل. لذا ، إذا كان بإمكانك الوصول إلى فئة المثيل للحصول على الخاصية الثابتة الخاصة بها ، فلماذا إذن لديك خاصية ثابتة؟ لديك بالفعل اسم الفصل ...

obj.constructor.isFoo == true
obj.constructor.name == 'Foo'

تحرير: كتابة هذا يمكنني معرفة أن وجود العديد من .is * يمكن أن يكون مفيدًا للاختبار على كل سلسلة وراثة أخيرًا ، مقارنةً باسم الفصل النهائي الفردي فقط ...

obj.constructor.isFoo || obj.constructor.isBar || obj.constructor.isBaz

Edit2: نعم أيضًا يمكن تحقيق الشيء نفسه مع أسماء الفئات أخيرًا ، ولكن اختباره أكثر تعقيدًا ...

let types = getInheritanceNames(obj) // looping each .constructor.prototype.constructor.name
types.contains( 'Foo' ) || types.contains( 'Bar' ) || types.contains( 'Baz' ) 

من المثال

أووبس. إعادة قراءة ذلك. نعم ، لا تهتم بما كنت أقوله.

if ( scope.object.isPerspectiveCamera ) {
...
}

if ( geometry.isBufferGeometry ) {
...
}

if ( material.isShaderMaterial ) {
...
}

الصحيح. شيئان.

• ماذا بقي لدينا؟

يجب أن نقرر متى نبدأ في تحويل examples/js إلى الفصول الدراسية.

• الاقتراب من الحاجة إلى مناقشة هذا من أجل التقدم.

لا أعرف ما إذا كان علينا انتظار # 20527 أو # 20529 لأن كلاهما سيحاول إعادة إنشاء examples/js بصيغته الحالية ، وهو ليس المكان الذي نهدف إليه. اقتراحي الأولي هو بدء تحويل examples/js كما هو. السؤال هو ، ما هي المشاكل التي نواجهها ...

أردت أيضًا إعادة تكرار شيء قاله mrdoob مؤخرًا

أكره إجبار المبتدئين على التعرف على polyfills أو bundlers من أجل تقديم أول مكعب.

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

أيضًا ، ربما تساعد إضافة REPL لكن الموجهة لـ Three.js في هذا المجال؟ مثال على كونها رشيق

سنحتاج أيضًا إلى توضيح كيفية استبدال بعض الأنماط غير الطبقية مثل:

function Foo() {

    this.update = function () {

        var priv = 'foo'

        return function update() {
            ...
        };

    }();

}

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

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

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

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

أي اقتراحات حول أي نص؟

عمليات البحث: internal ، private ، readonly 👀

انتظر ، هل كان من المفترض أن تكون جميع متغيرات _* خاصة؟

...

قد يكون الفيل في هذه الغرفة src/renderers/WebGLRenderer.js

ماذا عن WebGLAnimation ، إنها فئة صغيرة لطيفة ... https://github.com/mrdoob/three.js/pull/20070

أي اقتراحات حول أي نص؟

أركز على exemples/js ووجدت هذا في OrbitControls ...

أظهر ما يفعله بابل به.

أنا متأكد من أنه لن ينتج شيئًا يطابق بناء جملة mrDoob الذي يعتقده 😅

إلى اليمين.

وعفوًا. أين يوجد عقلي ... سنحتاج إلى واحد من # 20527 أو # 20529 (أو غير ذلك) للدمج من أجل البدء في تحويل المجلد examples . examples/js يظل ثابتًا في المستقبل المنظور مما يعني أن لمس المجلد examples/js بالفئات هو لا مطلق. هذا قد يكسر التوافق مع IE ... * تنهد *.

جعل تراكمي / بابل transpile إلى النمط القديم

تخمين تفكيرها من خلال ودعم هؤلاء JSM لشبيبة العلاقات العامة. يمكننا استهداف examples/jsm بمجرد الوصول إلى قرار.

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

إن لمس المجلد examples/js الذي يحتوي على فئات هو رفض مطلق.

عفوًا ، سيئتي ، كنت أتحدث عن البحث في exemples/jsm بالطبع ، exemples/js سيكون الإصدار "المبني" في المستقبل القريب ...

هذا قد يكسر التوافق مع IE ... * تنهد *.

ماذا؟؟؟ هل ما زلنا نتحدث عن Internet Explorer في عام 2020؟ هل نتحدث عن توافق مكتبة WebGL مع هذا الديناصور البالغ من العمر 7 سنوات؟ عنجد !! 1.4٪ ...
_ (يجب أن نضيف أداة تجميع إحصائيات في lib لجمع ما إذا كان هناك ثلاثة مستخدمين يخططون لاستخدام ما بموجب IE) _

😞 راجع للشغل ، هذا هو سبب وجود بابل ...

يجب أن تظل ملفات الإصدار three.js و three.min.js بالإضافة إلى جميع الملفات الموجودة في examples/js تدعم المتصفحات القديمة مثل IE 11.

كانت هناك علاقات عامة في العام الماضي يجب أن تتوقف عن دعم IE 11 (# 18091) ولكن اتضح أنه لا يزال هناك مستخدمون يعتمدون على هذا المتصفح. والسياسة الحالية للمشروع هي توفير الملفات ذات الصلة للمستخدم حتى لا يقوموا بتحويل ES6 إلى ES5 بأنفسهم. نوقش هذا أيضًا في # 20455.

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

حسنًا ، لا توجد مشاكل مع هذه السياسة إذا كان من الممكن تطوير المصدر بطريقة حديثة ، وإذا كان من المفترض ألا تكون البنيات الناتجة قابلة للقراءة ولكنها تعمل فقط ...
لأن المخرجات transpilers مثل هذا الرمز القبيح!
لذلك لا أرى أي مشاكل في كتابة src في ESnext ، وكونها قبيحة ، لكنها مشكلة محتملة في exemples/js إذا كان يجب أن تكون هذه الملفات قابلة للقراءة والتعليق عليها وصياغة جيدة ...

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

_ (لقد بدأت رحلتي مع ثلاثة من خلال بحث: "webgl rotating cube" ومثال على ذلك أدى إلى ماراثون كود ليلي واحد لتطوير لعبة صغيرة مع مكعب يتحرك على منصات ^ ^) _

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

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

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

هذا صحيح لمستخدمي وحدات ES فقط ؛)