Julia: فكرة مجنونة: قم بتغيير الكلمة الأساسية `type`

سيكون من الرائع جعل كلمة type قابلة للاستخدام في سياقات أخرى.

أنا أحب mutable للاتساق.

إذا تم ذلك ، فيجب أن يتم ذلك في أسرع وقت ممكن بحيث يمكن تضمينه في 0.6

إذا كان هذا سيحدث ، فاستخدم ما يتعرف عليه الجميع قبل التفكير: struct

أعتقد أيضًا أن type أمر محرج بعض الشيء. عندما أشرحها لأشخاص آخرين ، عادةً ما أقول "مثل البنية" ، لذا +1 لذلك.

إذا كان هذا سيحدث ، فاستخدم ما يتعرف عليه الجميع قبل التفكير: struct

اعتقدت أن immutable كان مثل الهيكل؟

+1 لـ mutable

immutable على تخطيط الذاكرة الخاص ببنية C
type لديه قابلية التغيير في بنية C.

وبالتالي فإن البنية مرتبطة بكليهما. أعتقد أن mutable بدلاً من struct أفضل لتوضيح ذلك.

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

بالنسبة لشخص قادم من Fortran ، فإن الكلمة الرئيسية type طبيعية بالفعل.
بالنسبة لشخص قادم من C ، ستكون الكلمة الرئيسية struct طبيعية.
بالنسبة لشخص يستخدم immutable كثيرًا ، فإن الكلمة الرئيسية المقابلة mutable ستكون طبيعية.

لذا ربما يجب أن نتركه كما هو.

struct{mutable}
struct{immutable}

أو

record{mutable}
record{immutable}

إذا كان المطلوب هو نموذج وصفي أكثر.

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

أظن أن مبرمجي فورتران على دراية بمصطلح "الهيكل".

+1 لـ mutable بسبب الاتساق. إذا تم اختيار struct ، ألن يملي التناسق التغيير الثابت إلى شيء مثل const struct ؟ ؛)

أعتقد أن struct و immutable struct سيكونان جيدًا في الواقع ؛ struct مصطلحًا مألوفًا للغاية وسنحتاج فقط إلى إضافة كلمة رئيسية واحدة جديدة. قد يكون السماح mutable struct أمرًا منطقيًا أيضًا ، على الرغم من أنه ليس مطلوبًا تمامًا.

يجب أن أوضح أنني أعتقد أن struct يعد اسمًا ميزة. سيكون من الأفضل عدم استخدام الصفات فقط لتسمية هذه الأشياء.

يؤدي الاضطرار إلى إضافة struct إلى immutable struct إضافة ضوضاء خط غير ضرورية ، بل أكثر من ذلك بعد أن اعتدت على عدم الاضطرار إلى كتابة هذا.

Otoh ، أعتقد أن لدى Fortran كلمة رئيسية type تقوم بشيء مشابه جدًا لما يفعله لدينا. ومع ذلك ، فأنا لا أعارض تغيير هذا.

KristofferC أعلاه صحيح: أجد نفسي أيضًا أقول "هيكل" عند شرح ما هو هذا. حتى في المناقشات الداخلية كان type مشكلة ؛ سيقول أحدهم "افترض أن x هو نوع" ، وليس من الواضح ما إذا كان ذلك يعني "الشيء الذي تم الإعلان عنه بالكلمة الرئيسية type " أو "النوع" بمعنى آخر.

إذا كانت هذه الأسماء موجودة بالفعل على الطاولة (يبدو s/type/new name/ بغيضًا إلى حد ما) ، فأقترح أننا قد نرغب في الاستفادة القصوى من هذه الفرصة لجعل الإعلان الافتراضي غير قابل للتغيير.
لذا فإن struct سيحل محل immutable ، و mutable [struct] سيحل محل type.

فقط كفكرة ، قد يكون مصطلح آخر محتمل للتغير هو أيضًا Ref .

قد يكون الاسم الآخر المحتمل هو composite ، نظرًا لأن مصطلح CS العام لهذا النوع هو mutable Foo و immutable Foo إلى mutable struct Foo و immutable struct Foo - struct (أو composite أو class ، أو أيا كان) تبدو غير ضرورية.

: +1: to noun (s)

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

أجد نفسي أيضًا أقول "بنية" عند شرح ماهية هذا

تخيل تقديم الوافد الجديد إلى struct T ثم إخبارهم T::DataType ويمكنك الإرسال باستخدام ::Type{T} ، كل ذلك أثناء شرح "نظام الكتابة القوي" لجوليا. أعتقد أن هذا مجرد ركل الدلو على الطريق.

كونه اسم ميزة

: +1: to noun (s)

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

أخيرًا ، نظرًا لأن الموضوع هو "فكرة مجنونة" ، فإن هذه الكلمات الرئيسية - بشكل أو بآخر - تنشئ DataType جديدًا ، فهل يمكننا إزالة الكلمات الرئيسية بالكامل واستخدام المُنشئ فقط؟

# Similar-ish to current
MyType = DataType(
    a::Int,
    b::Float64
)

# A DataFrame-like constructor
MyType = DataType(a = Int, b = Float64)

أعتقد أن هذه يجب أن يتم تحليلها بشكل خاص (بشكل ثابت) مثل ccall ويمكن استدعاؤها فقط في toplevel في الوقت الحالي. (أيضًا - لست متأكدًا مما إذا كنا سنحتاج إلى Mutable <: DataType و Immutable <: DataType و BitsType <: DataType لتغطية جميع الاحتمالات ، وربما const للربط).

اعتقدت أنه غير قابل للتغيير كان مثل الهيكل؟

غير قابل للتغيير لديه تخطيط ذاكرة لهيكل C
النوع له قابلية تغيير بنية C

صحيح ... أعتقد أنني كنت أفكر في Swift ، حيث:

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

الذي يبدو مثل immutable مقابل type ، وهو المرجع الوحيد الذي يسمح بالتغيير في سياق دلالات روابط جوليا.

يتضمن DataType جميع الأنواع الاسمية: abstract ، أنواع البت ، الهياكل الثابتة والمتغيرة. لذلك لا تضيف الكثير من الوضوح لاستبدال type بـ DataType . لقد استخلصت أيضًا استنتاجًا مختلفًا من سيناريو "الوافد الجديد": ::Type و ::DataType حدد مجموعات فرعية من الأشياء المحددة بواسطة type T ، لذلك ليس من الجنون أن يكون لديهم أسماء مختلفة . " struct هو نوع واحد من Type " أكثر منطقية من " type نوع واحد من Type ".

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

أحب structure و mutable structure للأنواع. ربما a = 1 و mutable a = 1 للتخصيص المتغير. الابتعاد عن فكرة الرغبة في الاتساق وعدم الاختصارات والثبات افتراضيًا.

تحرير: ربما constant بدلاً من const في حالة التغيير افتراضيًا

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

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

هذه نقطة جيدة - لكنني سأعتبر سلوك الإحالة مقابل سلوك "القيمة" أكثر أهمية وإثارة للاهتمام لوصفه من "هل هو هيكل أم نوع بت؟" (غالبًا لأن bitstype لا يظهر بشكل متكرر - كل نوع Julia أنشأته هو هيكل). الثبات هو مجرد نتيجة لربط الدلالي والقيمة المارة.

لتجنب الحاجة تمامًا إلى struct مقابل bitstype يمكننا أيضًا تضمين هذه الفكرة من quinnj والتي كانت

immutable 32 Int32 <: Integer

أو يمكن أن يكون لديك حقول غير مزينة بعدد البتات

immutable Int32 <: Integer
   32
end

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

ثم يكون مجرد اختيار بين نوع القيمة (ما هو غير قابل للتغيير حاليًا) مقابل نوع المرجع (ما هو قابل للتغيير حاليًا - ولكن من المحتمل أن يكون مع حقول const في المستقبل وهذا سبب آخر لعدم تسميته mutable ) والأسماء المناسبة لتمييزها. وأخيرًا ، فإن استخدام struct لنوع مرجع القيمة سيؤدي إلى إرباك مبرمجي Swift ...

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

لقد اخترنا في الأصل immutable لأننا شعرنا أن هذه ستكون الميزة الأكثر وضوحًا: على عكس الكائنات الأخرى ، لا يمكنك تعديلها. في الواقع ، لا يتم تمريرها دائمًا بالقيمة ؛ الثبات يعني أنه لا يمكنك معرفة الفرق. بعض immutable s مضمنة في مصفوفات وكائنات أخرى ، والبعض الآخر ليس كذلك. الثبات يعني أن الاختلاف لا يسبب مشاكل لرمز جوليا العادي ؛ تصبح مشكلة فقط عندما يكون تخطيط الذاكرة مهمًا حقًا على سبيل المثال لـ C interop.

في الواقع ، لا يتم تمريرها دائمًا بالقيمة

نقطة جيدة! رغم ذلك ، هناك خطط لتغيير ذلك ، أليس كذلك؟

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

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

الغرض الحقيقي من مفهوم "تمرير القيمة" هو الإجابة عن السؤال عما يحدث عندما يعدل f(x) (بمعنى ما) x : هل يقوم بتعديل نفس x المتصل مر ، أم أن التعديل محلي فقط؟ لم يكن لدى جوليا أبدًا (آمل) أنواعًا أو حججًا أو وظائف تختلف فيما يتعلق بهذا السلوك ولن تمتلكها أبدًا. كل شيء "يمر بالمشاركة". بالنسبة إلينا ، توجد قيمة التمرير فقط على مستوى ABI ، ولكن هذه المناقشة تنتمي فقط إلى قسم FFI من الدليل. لست متأكدًا من أنه سيكون لدينا نوع من النوع يتم تمريره دائمًا بالقيمة أو مضمّنًا دائمًا ، حيث يمكن أن يؤدي ذلك بشكل أسوأ للأشياء الكبيرة.

على أي حال ، أعتقد أن immutable و mutable خيارات قابلة للتطبيق للكلمات الرئيسية.

من الصحيح أن bitstype قد اختفى تمامًا منذ أن تم إدخال نظام ثابت

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

FWIW ، نظرًا لأنه لم يكن هناك الكثير من الدعم لعدم تغيير الأشياء ، أعتقد أن type و immutable جيدان كما هما.

(بناء الجملة do يزعجني ، رغم ذلك ... ؛-)

كل شيء "يمر بالمشاركة".

يمكنني احترام ذلك - وشكرًا على المناقشة.

كل شيء "يمر بالمشاركة".

في هذه الملاحظة ، مجرد ملاحظة - إذا كان لدينا كلمات رئيسية const في تعريفات النوع ، يصبح immutable غير ضروري تمامًا:

type Complex{T}
    const re::T
    const im::T
end

(يمكن للمترجم أن يحدد أن هذا النوع غير قابل للتغيير تلقائيًا ، ويمكن للمستخدمين أن يفهموا أن أنواع const تسمح لنا بالتجميع إلى كود أسرع). ثم type أو struct معنى. setfield! يمكن تعطيل على const الحقول في حالة مختلطة.

ماذا عن type و const type ؟ - الكلمة المفتاحية من النوع تبدو أكثر أناقة بالنسبة لي من الهيكل ومع الهيكل أنا نوع من الربط بين تخطيط الذاكرة الفني وليس الكائن الذي له على سبيل المثال منشآت داخلية. نظرًا لأن النوع المركب هو "... إلى حد بعيد النوع الأكثر استخدامًا من قِبل المستخدم في Julia ..." ، فربما لا يكون ذلك سيئًا إذا كان "النوع هو نوع واحد من النوع"؟ في الاتصال ، يجب أن يوضح استخدام "النوع المركب" ، تمامًا مثل "النوع المجرد". فيما يتعلق بضوضاء الخط ، فإن "النوع الثابت" ليس أسوأ من "ثابت".

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

تتمثل المشكلة الرئيسية في استخدام struct أن الأشخاص قد يضعون افتراضات بشكل طبيعي اعتادوا عليها من C / C ++ والتي ليست بالضرورة صحيحة في Julia ، على سبيل المثال ، لا يتم تخزين النوع المركب القابل للتغيير بالقيمة في مصفوفة بينما غير قابل للتغيير.

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

لماذا يجب فصل النوع إلى فئتين متميزتين عند نقطة تعريفهما بدلاً من نقطة الإرسال / الاستخدام (أشبه const في C ++)؟ باستخدام type / struct / composite لتحديد الأنواع المركبة وإدخال بنية Immutable{T} للترويج للتغيير إلى غير قابل للتغيير ، يمكننا الحصول على:

type CompositeType end
f(x::Immutable{CompositeType}) = x
a = f(CompositeType())
b = f(a)

أيضًا ، هل يمكن اعتبار التغيير إلى abstract و bitstype هنا؟ AFAICT استخدام "الملخص" كصفة وليس اسما. يجب أن يكون هناك على الأقل الاتساق اللغوي عبر نوع الكلمات الرئيسية: جميع الأسماء، وجميع الصفات، وما إلى ذلك bitstype قد ذكر أفضل مجرد bits أو primitive .

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

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

andyferris أحب هذه الفكرة حقًا ؛ مزيج من struct و const سيكون جيدًا. إذا ذهبنا بهذه الطريقة ، فأنا أريد أيضًا أن أكون قادرًا على قول const struct أو const type ، (1) لتجنب الحاجة إلى كتابة const في كل حقل ، (2 ) لذلك لا يتعين علينا إضافة الميزة الجديدة لثبات كل مجال على الفور. إذا أردنا إضافة هذه الميزة ، فسيكون من الجيد أن يكون لدينا مفردات متسقة متاحة لها.

في التواصل ، يجب أن يوضح استخدام "النوع المركب"

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

لماذا يجب فصل النوع إلى فئتين متميزتين عند نقطة تعريفهما بدلاً من نقطة الإرسال / الاستخدام (أشبه بـ const في C ++)؟

هذا سهل: تقديم ضمانات عالمية. في C ++ ، لا يزال من الممكن تغيير كائن "const" تحته إذا كان لدى شخص ما مرجع غير ثابت.

أيضا ، هل يمكن النظر هنا في تغيير الملخص و bitstype؟

تقديم اقتراح. بالنسبة إلى bitstype ، نادرًا ما يتم استخدام الكلمة الرئيسية ، لذلك لا أريد سرقة كلمة صغيرة مفيدة مثل bits لها.

يبدو أيضًا أن immutable -> const type مناسب لي. مع type -> composite أو struct ، إذا كنا نريد حقًا تحرير type .

لست سعيدًا جدًا بكل التغييرات البرمجية التي سيؤدي إليها هذا الأمر ، خاصةً أنه لا يمكن دعمها بواسطة @compat ، ولكن. إذا كان لا بد من القيام بذلك ، أعتقد أن مسار الترقية يجب أن يكون شيئًا مثل (1) تقديم مرادفات جديدة للكلمات الرئيسية في 0.6 ولكن _لا _ تتجاهل المرادفات القديمة (بسبب عدم وجود @compat ) ، ثم (2) قم بإيقاف القديمة في 0.7.

بالنسبة إلى bitstype ، ماذا عن تسمية هذا النوع primitive ؟ الاسم الحالي مزعج بعض الشيء بسبب تشابهه مع an isbits composite type

تعجبني الطريقة التي تتجنب بها جوليا غالبًا بعض الاختصارات "def / func / elif" على غرار بعض اللغات الأخرى. (الاختصارات Dn w ، kthx.) لذا فإن mutable يفوز بأكثر من struct بالنسبة لي.

يستخدم FWIW ، OCaml type للسجلات والمتغيرات (الهياكل والنقابات) والأسماء المستعارة. يستخدم ML القياسي datatype ما أعتقد.

التماثل جميل ، لكني أجد أن mutable غير وصفي بشكل كافٍ ؛ immutable أيضًا ، لهذا الأمر (أحب فكرة const type ).

كما يشير ستيف ، سيؤدي هذا إلى حدوث خلل في التعليمات البرمجية السيئة عبر المجتمع. والفائدة مشكوك فيها.

أرى بالتأكيد حالة const type ؛ سيكون net -1 الكلمة الأساسية ، وتوضيح العلاقة بين type و immutable. سيكون من الرائع حقًا أن تكون قادرًا على استخدام type بطرق أخرى. بدون هذه الفائدة يكون من الصعب للغاية تبرير التغيير. لكن تحديث الكود لهذا يجب أن يكون سهلاً للغاية ؛ بناء جملة type لا يمكن استخدامه بشكل أساسي في أي سياق آخر.

+1 لـ composite / const composite .

أشعر أن primitive مقابل composite هو عامل تمييز رائع ، حيث تمت إضافة الكلمات الرئيسية const عند الضرورة.

هل نحتاج إلى const primitive للتمييز عن بعض البتات التي يمكن أن تتغير (وللتناسق)؟ لذلك سيكون لدينا بشكل متماثل

primitive        # something new... 
const primitive  # bitstype
composite        # type
const composite  # immutable

يجب تنفيذ المشكلة كونها نوعًا بدائيًا متغيرًا ... (بالطبع قد يكون هذا في وقت لاحق ، لكننا نريد bitstype -> const primitive _now_ إذا كان ذلك سيحدث لتصبح شيئًا. لكونها أبسط ، يمكن أن تكون هدف "تدريب" جيد لجلب المتغيرات إلى المكدس ، لكنني لست خبيرًا في ذلك).

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

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

منطقي تماما بالنسبة لي.

لقد بحثت عن نوع البيانات composite ووجدت أن Ada و Visual Basic على الأقل يشتملان أيضًا على أنواع مصفوفة تحته. (بخلاف ذلك ، تم العثور بشكل عشوائي قليلاً: Haskell: القوائم و tuples (مع ذلك تم طلب تعريف) ؛ Python: القوائم ، المجموعات ، الإملاء ؛ Lisp: القوائم ، المتجهات ، جداول التجزئة ، الفئات التي يحددها المستخدم ، الهيكل).

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

حسنًا ، قد يكون هذا صحيحًا: يبدو أن هذا النوع المعين من النوع يُطلق عليه دائمًا اسم هيكل أو هيكل أو سجل (أو فئة أو كائن) ، مع كون مصطلح "مركب" مصطلحًا أوسع. هناك العديد من الأمثلة على http://rosettacode.org/wiki/Compound_data_type

سيكون من الجيد استعادة type كمعرف واستخدام اسم أكثر تحديدًا. سيكون كسر كل حزمة تافهة مكتوبة قبل ~ 0.6 أمرًا مؤسفًا للغاية ، ولست متأكدًا من كيفية موازنة ذلك.

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

بالنسبة للأسماء التي ستحل محل type ، يبدو أن struct يتجنب الغموض بشكل جيد (كثيرًا ما أجد العبارات "نوع قابل للتغيير" و "نوع ثابت" متشابهة جدًا)

أعتقد أن ما يلي يبدو لطيفًا إلى حد ما:

struct A
    a::Float64
end

const struct B
    b::Float64
end

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

أنا أردد هذا الشعور.

إذا كنا سنقوم بتغيير الأسماء ، فكيف سيتم التعامل مع الإهمال؟ هل سيظل type و immutable صالحين في 0.6 وربما 1.0 مع وجود تحذيرات؟ يمكن Compat.jl معالجة هذا بشفافية. سيظهر قدر كبير من الأدبيات على الشبكة (منشورات المدونة ، والبرامج التعليمية ، إلخ) تحذيرات - مضايقات بسيطة للوافدين الجدد.

لا يزال بإمكاننا حجز type و immutable لفترة أطول من المعتاد لتسهيل الانتقال.

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

أنا شخصياً أنا أتصل به struct . وقد قلت ذلك

لن أخلط بين المناقشة حول التسمية الفعلية والألم الذي سيترتب على الانتقال.

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

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

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

immutable -> const type هو الطريق الأقل مقاومة ، ومن المؤكد أنه يجب تنفيذ IMO. أعتقد أن هذا يفسر الأشياء أجمل بكثير.

type -> composite أكثر دقة من type لكن أقل دقة من struct ، بينما أقل الاصطلاح العام من struct (إلى المبرمجين الجدد). تمرر "كتابة جملة جيف لشرحها لاختبار مبتدئ" واسترداد الكلمة الرئيسية type . وعلى الجانب السلبي ، لا أعتقد أن composite يظهر في لغات أخرى ، لذلك نحن أن تذهب وحدها.

type -> struct هو الأكثر دقة ، ولكن ربما structure سيكون أجمل من الاختصار (أحاول أن أفكر في الاختصار بأنه قبيح مثل struct eye() هو تقليد مثير للاشمئزاز من منظور اللغة الإنجليزية).

bitstype -> primitive منطقيًا إذا تم تغيير type .

tbreloff صحيح - لقد أظهر

أتساءل عما إذا كان ، نظرًا لأن immutable يجب أن يكون هو المعيار ما لم تكن بحاجة صراحة إلى التغيير ، فهل يجب أن تكون إعادة التسمية:

• immutable -> struct
• type -> mutable

ثم يعتبر الاسم الشائع / المتوقع هو أفضل الممارسات ، وهناك اسم واضح وواضح لطلب قابلية التغيير.

أنا أحب bitstype -> primitive أيضًا ...

لا أعتقد أن const يجب أن يكون الخيار الافتراضي. التحسينات التي تقلل من الوظائف لا ينبغي أن تكون الافتراضية.

+1 لـ struct و const struct .

المصطلح composite أكثر وصفيًا ولكن المصطلح struct قصير ، ومعروف بشكل شائع بالنوع المركب.

أفضل عدم سرقة كلمة فعلية لشيء نادر الاستخدام مثل bitstype . ربما primtype أو primitivetype ؟

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

من -1 إلى struct . لا أستخدم هذا المصطلح لشرح ما هو تعريف النوع ما لم أتحدث إلى مبرمج سي ، وبعد ذلك فقط لأذكر أن التخطيط متوافق ومقارنة / تباين خصائصهم.

من -1 إلى const . سارت C في هذا الاتجاه المتمثل في الحصول على الحد الأدنى من الكلمات الرئيسية تمامًا ، والآن نحن عالقون في العديد من الكلمات الرئيسية التي لها معاني حساسة للسياق. لا أعتقد حقًا أن const هي الخاصية الرئيسية لهذه الأنواع ، لكنها بالأحرى أنواع قيم (على عكس أنواع المراجع).

إذا كنت تسير في اتجاه آخر ، فماذا عن استخدام الكلمة الرئيسية new ؟

new abstract Abstract
new value Value <: Abstract
    Value() = new()
end
new primitive 8 BitsByte <: Abstract
new record Object <: Abstract
    Object() = new()
end
new function WhyNot # equivalent to `function WhyNot end`

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

أرى إلى أين أنت ذاهب مع التسجيل ، ولكن بصراحة أعتقد أن هذا المصطلح أقل شيوعًا من struct (حتى إذا كنت تستخدم google "نوع السجل ruby" مقابل "Struct type ruby" ، أو استبدل python أو perl أو بعضًا لغة أخرى غير C). هناك أيضًا مشكلة أن record كلمة إنجليزية مفيدة تمامًا وسيكون من العار حجزها ككلمة رئيسية ، في حين أنه من غير المحتمل أن تكون هناك حاجة إلى struct لأي شيء آخر في البرنامج.

struct شائع الاستخدام ؛ بالنظر إلى rosettacode ، يتم استخدامه من قبل:

algol، C، C #، C ++، lisp، D، elixir، go، maxima، Rust، seed7، swift، visual basic ( structure )

record بواسطة:

أدا ، كلوجور ، دلفي ، باسكال ، إيرلانغ ، أيقونة ، نموذج -2 ، بعض المخططات

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

ومن المثير للاهتمام على الرغم من أن seed7 يستخدم new struct .

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

يستخدم structure في الواقع في PL / I و visual basic. يحتوي VB أيضًا على structure immutable . ومع ذلك ، فإن struct شائع جدًا لدرجة أنني أشعر أنه أصبح تقريبًا كلمة جديدة خاصة به.

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

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

func بالنسبة لي ليس مصطلحًا قائمًا بذاته ولكنه مجرد اختصار.

func بالنسبة لي ليس مصطلحًا قائمًا بذاته ولكنه مجرد اختصار.

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

على أي حال ، أفضل mutable ، لذلك لا أهتم كثيرًا إذا كان هيكلًا أو هيكلًا. mutable من شأنه تجنب كتابة const طوال الوقت لما هو الآن immutable .

ولكن ، حتى لو انتهى الأمر إلى أن تكون struct أو حتى strct أو stct أو strctr فمن غير المرجح أن أغير Julia لأي لغة أخرى عملي ، لذلك ... :)

آسف إذا كان هذا لا معنى له في اللغة الإنجليزية: ولكن ليس struct اختصار construct . على الأقل في اللغة الألمانية ، تبدو الكلمة Konstrukt أكثر منطقية لوصف ماهية النوع المركب.

في اللغة الإنجليزية ، عدم القدرة على معرفة ما إذا كان construct هو اسم أو فعل قد منع استخدامه في لغات البرمجة المعتمدة على اللغة الإنجليزية :) الاستخدام الألماني للأحرف الكبيرة مفيد هناك.

struct هي كلمتها الخاصة بنفس الطريقة التي يستخدم بها TV و ASAP و LOL كلمات. نادرا ما أسمع الناس يقولون "هيكل". من واقع خبرتي ، فإن الكلمة هي "تنظيم" منطوقة ومكتوبة.

راجع للشغل: تستخدم Matlab الكلمة struct ، إذا كان ذلك يحدث أي فرق.

OTOH ، كما هو مذكور أعلاه ، في C # و Swift struct يتوافق مع نوع القيمة (على عكس class ). لذا فإن استخدام مصطلحات مماثلة لكل من الأنواع المتغيرة وغير القابلة للتغيير لن يساعد حقًا الأشخاص على دراية بهذه اللغات. لست متأكدًا مما إذا كانت هذه نقطة حاسمة ....

يبدو أن الخيار mutable / immutable هو الخيار الأكثر وضوحًا ، والذي يجب أن يكون واضحًا تمامًا للقادمين الجدد.

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

أنا أحب type و const type الأفضل ، لكن هذا لا يحرر الكلمة الرئيسية type . نظرًا لأنني لا أعرف ما هو مخطط لـ type ، فأنا لا أعرف حجم التكلفة.

ولكن نظرًا لأن الجزء type مضمن بالفعل في abstract ، فربما يكون استخدام mutable و immutable بأنفسهم هو الأكثر منطقية. وأقل كتابة ذلك immutable struct وتغيير صغير (اكتب -> قابل للتغيير).

إن بنية الكلمات (على الأقل بالنسبة لي كمواطن ألماني) أكثر تجريدية.

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

من -1 إلى struct . لا أستخدم هذا المصطلح لشرح ما هو تعريف النوع ما لم أتحدث إلى مبرمج سي ، وبعد ذلك فقط لأذكر أن التخطيط متوافق ومقارنة / تباين خصائصهم.

أشعر بهذه الطريقة بالضبط حول struct . أشعر أننا سنقدم مصطلحًا جديدًا لجوليا بدون سبب محدد.

من -1 إلى const . سارت C في هذا الاتجاه المتمثل في الحصول على الحد الأدنى من الكلمات الرئيسية تمامًا ، والآن نحن عالقون في العديد من الكلمات الرئيسية التي لها معاني حساسة للسياق. لا أعتقد حقًا أن const هي الخاصية الرئيسية لهذه الأنواع ، ولكنها بالأحرى أنواع قيم (على عكس أنواع المراجع).

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

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

IMO لا ينبغي علينا استخدام كلمات خيالية مثل "قابل للتغيير" و "ثابت" للحديث عن هذه الأشياء. يمكن أن يرتد شيء ما إلى كائن جديد ، أو يكون ثابتًا. إن إزالة الحاجة إلى كلمات اللغة الإنجليزية المعقدة مثل struct و immutable بالكامل من حديثنا حول Julia (وليس الرمز فقط) يجب أن يُنظر إليه على أنه شيء جيد (هدف ، حتى).

أشعر أيضًا أن كلمة "Structure" هي كلمتها الخاصة (بمعنى ما تعنيه في C) بينما كلمة "Structure" هي على الأرجح "بنية بيانات" - لأنك إذا كنت تقصد نوع السجل ، يمكنك أن تقول "Struct". لكنني أعرض جذوري C هنا.

كما أنها من القواسم المشتركة. defstruct .

ربما يكون هذا تافهًا أكثر من معظم النقاط الأخرى هنا ، ولكن طالما أننا نتعامل مع دراجات: عند التحدث بصوت عالٍ ، تبدو العبارات immutable object و a mutable object متشابهة بشكل مزعج. سيجعل الحديث عن نظام جوليا للكتابة أكثر صعوبة مما يجب أن يكون. تحرير: يبدو أن هذا قد تم طرحه بالفعل في هذا الموضوع .

+1 إلى type -> struct و immutable -> const struct . لا أعتقد أنني قابلت أي شخص قد يربكه هذا ، خاصة بعد شرح سريع.

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

أقترح ترك struct غير مستخدم. في C ، تعتبر البنية حاوية نحوية لتسلسل ثابت من الحقول من النوع الثابت. جوليا ليست C ، وجذب C-ism في الخطاب اليولياني من شأنه أن يدفع طبيعة جوليا المؤقتة بعيدًا عن المناقشة الجادة لأفضل استخدامات جوليا وأفضل الطرق لتصور جوانبها.

أيضًا ، "ثابت" و "قابل للتغيير" متطابقان بشكل مرئي للغاية. يمكننا أن نفعل ما هو أفضل.

  immutable ComplexNumber ... end

  alterable MethodTable   ... end

JeffreySarnoff جانبا ، وفقًا لمعايير المجتمع ، يُفضل الإشارة إلى جوليا على أنها "هي". فقط اعتقدت أن أذكر ذلك. 🙂

ararslan يبدو أن التوجيه المعياري للمجتمع على Julia قد تغير ، ويتجنب الآن تطبيق الضمير الأدبي. شكرا لجلب انتباهي الى هذا. :كريكيت:

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

شكرا

يوم الخميس ، 3 نوفمبر 2016 الساعة 4:29 مساءً ، Stefan Karpinski [email protected]
كتب:

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258264451 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABmqxopTX8oWKbwnLxfCBtIv-Ih7l-nXks5q6kRFgaJpZM4KkN_g
.

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

الكلمة الأساسية المستخدمة لبناء نوع هي في الواقع هيكلية وليست كتابة

لكن الكلمة الأساسية لا تتعلق حقًا بإنشاء الأنواع - على سبيل المثال ، يُنشئ التعبير Tuple{Int} أيضًا نوعًا. سيكون من الرائع أن تتم الإشارة دائمًا إلى الأشياء المحددة حاليًا بـ type على أنها struct s ، منذ ذلك الحين لن يكون هناك ارتباك فيما يتعلق بكيفية استخدام Real للنوع ، و Union{Int8,Int16} هو نوع ، إلخ.

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

يوم الخميس ، 3 نوفمبر 2016 الساعة 4:38 مساءً ، أليكس أرسلان [email protected]
كتب:

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258266857 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABmqxsZ_rXkn6GpVFxhd6TZnkkao9plWks5q6kZggaJpZM4KkN_g
.

سيكون من الرائع أن تتم الإشارة دائمًا إلى الأشياء المحددة حاليًا بـ type على أنها struct s ، منذ ذلك الحين لن يكون هناك أي لبس فيما يتعلق بكيفية استخدام Real للنوع ، و Union{Int8,Int16} هو نوع ، إلخ.

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

ararslan : المصطلح type هو مصطلح عام لما يتم إنشاؤه حاليًا. ما نقوم بإنشائه حاليًا باستخدام الكلمة الرئيسية type هو هيكل يتكون من أنواع مركبة. ولكن هناك العديد من الأنواع الأخرى داخل Julia التي لم يتم إنشاؤها باستخدام الكلمة الأساسية type .

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

حسنًا ، نقطة جيدة.

و Union {Int8، Int16} هو نوع

آه. لقد نسيت أن Union موجود أيضًا. مما يجعل وسيطة struct ( Struct ؟) أكثر إقناعًا ، IMO. ما زلت لا تحب mutable و immutable رغم ذلك.

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

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

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

a structure هو علاقة متبادلة ذات مغزى بين الأجزاء ، تكوين مستنير
يُعد construct هيكلاً مفيدًا للارتباطات وتصميمًا يعزز القيمة

structure هو مركب مؤلم
structure قابل للتغيير هو اختيار مسبق غير محدد
construct هو احتمال ثابت
construct قابل للتغيير هو قيد مقصود على السياق

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

ماذا عن class و immutable ؟

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

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

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

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

فيما يتعلق type مقابل struct ، أرى أنه يمكنني إنشاء أنواع بيانات مجردة باستخدام abstract ، Union{} ، typealias وهكذا ( في حالة Tuple{} ، يمكن الجدال إذا كان نوعًا جديدًا أو مجرد نوع ذي معلمات) ، ولكن أنواع الخرسانة الوحيدة التي يحددها المستخدم - يتم إنشاؤها بواسطة bitstype ، type و immutable . إن بناء الجملة لهذه التعريفات لا لبس فيه من خلال التعريفات المجردة من حيث أنها تحدد البيانات التي تحتوي عليها بطريقة أو بأخرى ، بينما التعريفات المجردة لا تفعل ذلك. يبدو أن تغيير immutable إلى const type يجعل الموقف واضحًا بالنسبة لي.

أنا قلق بشأن اللغة ونشر الكلمة التقنية struct والسبب الوحيد هو التقليد ، عندما تكون لدينا فرصة لإنشاء لغة برمجة تتم مناقشتها بمصطلحات عامة الناس. من الأمثلة التي أعتقد أنها لن تساعد في ذلك عندما أقوم بإنشاء نوع غلاف مثل Symmetric{Matrix{T}} - لا أريد أن تكون مناقشاتي ، "لقد أنشأت هذا struct بحقل واحد فقط الذي ... "عندما يمكنني القول" لقد صنعت غلافًا Symmetric type مقابل Matrix "(لاحظ أن نصف هذه الجملة عبارة عن بناء جملة فعلي). A "المجمع منظم"؟ يبدو نوعًا من السخف - ومن يصنع هيكلًا في مجال واحد؟ في هذا الصدد ، ماذا عن العزاب الذين ليس لديهم حقول؟ لم يتم تحديد جزء كبير من types و immutables لإنشاء أي بنية بيانات (غير تافهة) ولكن مع الغرض الصريح المتمثل في استخدام نظام الكتابة والإرسال الفعال مع أغلفة ومفردات. IMO هذا هو الجانب الأكثر إثارة للاهتمام والأقوى والتعبير في جوليا (بالإضافة إلى حقيقة أنه _ سريع_).

أشعر أن القوة الكاملة البالغة struct ستظهر على الفور فقط لمُصممي metaprogrammers ذوي الخبرة في C ++ الذين يعرفون أنهم يستطيعون تنفيذ السمات ، وما إلى ذلك ، باستخدام الهياكل ، وهذا أمر مخجل قليلاً.

"النوع" له معنى تقني محدد إلى حد ما في نظرية النوع.

إذا كان الهدف / الميزة هو تحرير type فما رأيك:

const datatype  # immutable
datatype        # type

إنها أنواع ملموسة لذا فهي تحتوي على الأرجح على بيانات ، وهي إحدى الطرق (من بين العديد) لإنشاء DataType .

"النوع" له معنى تقني محدد إلى حد ما في نظرية النوع.

تبدو مقدمة الويكي تمامًا مثل Type{} (الذي يقبل DataType و TypeConstructor ، Union ، إلخ) (تعديل: لا أعتقد أن مثل هذا التغيير يستحق التعطيل)

kind ليست الكلمة الصحيحة هنا.

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

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

نقطة عادلة ، جيف. يرجى ملاحظة أنني _do_ أعتقد أن const struct و struct سيكونان تحسنًا أكثر من immutable مقابل type (لكن هذا لا يعني أنه لا ينبغي علينا البحث عن شيء أفضل).

عندما تعتقد أن الهيكل هو أن الإدراك هو أكثر من مجرد هيكل أو بناء ، لا أو كلاهما؟

andyferris لا يعني const struct و struct سيكونان تحسنًا. كانت محاولة أخرى للبحث عن المصطلحات المحتملة عند الرغبة في تجنب "const" ، والحفاظ على "ثابت" والحفاظ على "الهيكل" (كان على دراية بالتنفيذ المذكور ولكن يعتقد ، إذا كان صحيحًا في 80 plus٪ من الحالات ، فلا بأس بذلك) .

ماذا عن fieldtype (أو fieldstype )؟ إنه موازي لـ bitstype ويتوافق مع fieldnames() .

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

class قد يكون جيدًا ؛ لقد رفضناه في الأصل بسبب ارتباطه بـ OO القائم على الفئة مع الطرق داخل الكائنات. أود أن أقول إن struct أكثر دقة.

لا أرى struct اختصارًا لأي شيء ؛ إنه بالضبط ما تسمى هذه الأنواع من هياكل البيانات في هذه المرحلة. من المضحك إلى حد ما أن Lisp لديه cons ، والذي ربما كان في الأصل اختصارًا لـ construct ، لكن الناس نسوا ذلك بسرعة كبيرة وبدأوا للتو في الحديث عن "الخلايا السلبية".

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

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

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

record T0
    f::A
    g::B
end

record T1
    const f::A
    g::B
end

record T2
    f::A
    const g::B
end

record T3
    const f::A
    const g::B
end

const record T4
   f::A
   g::B
end

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

يصف T3 و T4 هنا أنواعًا مكافئة - أي أن كتابة سجل ثابت هو مجرد اختصار لجميع الحقول التي تكون ثابتة.

إذا جعلنا const record يعني ما يعنيه immutable الآن ، فقد لا يكون هذا صحيحًا. سيصف const record نوع مرجع لا يمكن تغيير أي من الحقول فيه. في حين أن immutable هو نوع قيمة.

راجع https://github.com/JuliaLang/julia/issues/19157#issuecomment -257942059 والتعليق التالي لبعض المناقشات حول record .

vtjnash هذه نقطة جيدة ، لكنها مشابهة لما يحدث الآن عندما يصبح immutable نوع "مرجع" إذا كان يحتوي على أي مراجع.

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

ماذا عن nuple ؟ اختصار لعبارة "اسم المجموعة" ، بالطبع.

أنا أحب الاقتراح أعلاه من

const datatype  # immutable
datatype        # type

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

هل هناك أي خطط لتغيير المصطلحات أيضًا لشرح ذلك في الوثائق ، وتغيير عناوين فصول مثل هذه بشكل أكبر ؟ إذا لم يكن الأمر كذلك ، أعتقد أنني أفضل composite و immutable composite أو const composite . نظرًا لأن const يُستخدم أيضًا للثوابت العالمية ، فسأختار إما const أو immutable لكليهما ، مع تفضيل بسيط لـ const لأنه أقصر. على الأقل ، لن تبدو الكلمة مركب مألوفة لمعظم القادمين الجدد ، مما يفرض نظرة على الوثائق ويتجنب الافتراضات الخاطئة بسبب التشابه مع اسم C. تبدو الافتراضات الخاطئة بشأن const أقل احتمالًا ، لأن أي شخص اعتاد على ذلك في C ++ يعرف أنه لا يتحمل أي شيء.

كما أن ميزة استخدام كلمتين للإشارة إلى الثبات يحرر المستقبل المحتمل const abstract و const bitstype إذا دعت الحاجة.

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

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

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

ماذا عن nuple؟ اختصار لعبارة "اسم المجموعة" ، بالطبع.

قد يذهب كذلك مع record ، أليس كذلك؟ على سبيل المثال ، المجموعة المسماة هي ما يمثله record في Erlang. وأعتقد في عالم قاعدة البيانات أيضًا.

ولكن إذا كان لدى جوليا الكثير من التداخل مع الأشخاص الذين يعرفون أيضًا C ، فإن struct هو تغيير أكثر ملاءمة.

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

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

قادمة من Fortran ما زلت أعتقد أن الكلمة الرئيسية type جيدة ،
وأقل تغيير معقول سيكون immutable -> const type .

ولكن إذا كان على type أن يذهب فعلاً ،
يبدو أن الخيارين التاليين الأفضل هما composite و const composite .

immutable المؤكد أن const type يبدو قابلاً للتطبيق: فهو يتجنب الاضطراب في الوقت نفسه ويزيل كلمة رئيسية ويضيف وضوحًا للغة.

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

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

أي هل يمكننا التخلص من سلوك الكلمات الرئيسية مع الحفاظ على بناء الجملة لتعريف النوع؟

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

@ c42f :

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

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

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

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

_برغم من_

لأن الوضع الفعلي هو أن C

يجسد بشكل جيد لماذا ، من حيث شروط المرشح ، struct هو الأقل تفضيلاً لدي

ها هي القصة التي أبيعها: "في كل من C وجوليا ، فإن struct عبارة عن بنية بيانات تعيّن مجموعة ثابتة من أسماء الحقول إلى قيم من أنواع مختلفة. ولكن عند تمريرها ، يتم تمرير C -بالقيمة وجوليا تقاسم بالمرور ".

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

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

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

أعتقد أن immutable يجب أن تظل كلمة رئيسية مكونة من كلمة واحدة. لا أحب const type أو const struct أو immutable struct . أستخدم immutable كثيرًا وأعتقد أنه من المحرج حقًا أن تكون هذه الإعلانات عبارة عن كلمتين عندما يكون كل شيء آخر عبارة عن كلمة واحدة. ليس بمعنى الكتابة ، لأن هذا ليس مصدر قلق حقيقي ؛ ولكن بمعنى أن وجود غير قابل للتغيير مثل "علامة" يجعله يشعر بأنه من الدرجة الثانية.

TotalVerb لا أشعر أن هذا متوافق تمامًا مع حقيقة ذلك

type MyType
    const field::Int
end

يجب أن تتصرف تماما مثل

immutable MyType
    field::Int
end

يفعل الآن.

بالنظر إلى ذلك ، فإن وجود const type (أو const struct أو const composite أو أيًا كان) يبث const لكل حقل كاختصار يبدو مفيدًا (على الرغم من ليس ضروريًا تمامًا). آمل ألا يعرف المترجم في المستقبل أي واحد كتبته ( const type أو const أمام كل حقل - يمكن أن يتحول الأول إلى الأخير بواسطة المحلل اللغوي). في هذه المرحلة ، لماذا تحتفظ بـ immutable ؟

وجود ثابت مثل "علامة" يجعله يشعر بأنه من الدرجة الثانية.

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

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

في رأيي ، الأمر ليس مجرد "تحسين"

immutable Complex{T} ... end

بدلا من

type Complex{T} ... end

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

قبل أن يستقر المجتمع على const و struct ، أردت فقط صنع مقبس إضافي مقابل constant و structure .

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

من أجل المتعة فقط ، قد يتم الخلط بين الكلمات السخيفة التي يتم إنشاؤها من أجل:
عدم القابلية للتدمير
العرقلة
ما بعد البنيوية
البنية الفوقية (اهلا ماركس)

و const:
القسطنطينية
كوكبة
أفعى المضيقة
مخالف للدستور

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

نفس السؤال بعبارة أخرى:

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

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

بالتفكير أكثر في هذا الأمر ، فإن التغيير الوحيد الذي أعتقد أنه يستحق الانهيار هو bitstype -> primitive ، غالبًا بسبب إزعاج استدعاء شيء ما isbits .

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

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

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

أعتقد أن تغيير هذا السلوك سيكون حقًا تغييرًا أساسيًا للغة جوليا.

andyferris شكرًا لك على هذه الإجابة الواضحة.

هل هناك أي سبب لعدم استخدام fixed بدلاً من const أو constant ؟ بالنسبة لي على الأقل ، يبدو وصفًا أكثر وضوحًا.

كنت أتساءل عما إذا كان هناك شيء أفضل من const أو constant مما يعكس أن الربط الدائم ، وليس (بالضرورة) أن البيانات الموجودة داخل الكائن المرتبط غير قابلة للتغيير. fixed ذهب

ربما شيء مثل bind (على سبيل المثال bind x = 2 ) ... يقترح قاموس المرادفات glue ... هذا الحصول على تخمينات جميلة ...

فكرة استبدال const بشيء أكثر دقة هي فكرة جذابة. ومع ذلك ، نود أن يتم تطبيقه بشكل معقول على كل من تعريف النوع وإسناد المتغير الفردي. fixed struct يبدو منطقيًا ، لكن حقول البنية هي التي تم إصلاحها بدلاً من إعلان النوع. لسوء الحظ ، يبدو أن bound struct ( tied struct ؟) غير واضح إلى حد ما. لسبب ما ، يبدو لي const أكثر وضوحًا عند تطبيقه على نوع.

نود أن يتم تطبيقه بشكل معقول على كل من إعلان النوع وإسناد المتغير الفردي.

أشعر أنه سيكون من المفيد أن أهدف إلى ذلك

type A
    const x::Int  # fixed, bind, bound, tied, glue
end

من المنطقي. وجود اختصار أمام type أو struct أو أي شيء سيكون مجرد اختصار يعني ما سبق.

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

+1 لـ type -> composite ، على الرغم من أن أي تغيير من type يبدو رائعًا.

أتمنى أن يكون بإمكاني التصويت على مشكلات GitHub دون الحاجة إلى إضافة تعليق جديد إلى الموضوع ... تصويتي هو mutable و immutable ، إنه أنيق جدًا ونظيف. struct بشكل مفرط ولا يؤكد على جزء قابلية التغيير.

ملاحظة: هل يعرف أي شخص أو يمكنه المساهمة في GitHub وإضافة ميزة التصويت؟ سألتهم في صفحة "اتصل بنا" ، ولكن ربما فُقدت بريدي الإلكتروني.

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

كان توقعي الأولي في جوليا هو type بسيطًا ليتصرف بشكل مشابه لعنصر C-style struct أو كائن Python ، حيث يبدو أن Julia تدور حول أسلوب البرمجة الوظيفية والسرعة.
ما زلت أشعر بالارتباك بسبب عدم التناسق في صياغة type ... و immutable... ، لكنني أحصل على DataType من typeof(SomeType) ، أو المعنى الفعلي لـ "bitstype ، وضرورة وجود كلمة رئيسية typealias بدلاً من عبارة Alias = DataType .

وبالتالي ، سأصوت لـ datatype ، والذي سيكون متوافقًا مع typeof(SomeType) == DataType ، وسوف يكسر التشابه المزعج مع ::Type{} . يمكن أن يؤدي تزيين النوع القابل للتغيير بـ composite [datatype] إبراز طبيعته الخاصة وربما الأكثر تكلفة مقارنةً بـ "أنواع البت" الأساسية.

سحب جميع مشكلات التكرار المربكة في C / C ++

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

كان من الممكن أن يساعدني القصد من كونه نوع قيمة أو نوع مرجع مشترك بشكل كبير ، بدلاً من مجرد الإشارة إلى قابلية التغيير

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

datatype ليس اختيارًا سيئًا. لكن لا أعتقد أن datatype مقابل composite datatype طريقة جيدة للتعبير عن تمييز قابلية التغيير.

JeffBezanson ، مع const struct .

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

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

لقد وصلت إلى المكان الذي أتيت منه منmjw ، لقد كنت هناك ، لكن أعتقد أنه من الأفضل لك التخلص من كل ما تعرفه عن C / C ++. هنا ، فإن قيمة const هي التي لا يمكن تغييرها ، وما إذا كان الشيء مكدسًا أو مخصصًا ديناميكيًا ، وما إذا كان قد تم تمريره من خلال المرجع أو القيمة ، فهو حر في التغيير وسيكون اختيارات تحسين للمترجم. يمكنك إنشاء لغة يتم فيها تخصيص كل شيء ديناميكيًا وتمريره من خلال المرجع ، وهذه هي الطريقة الافتراضية لجوليا (للقيم المعبأة - فهي تنفذ "تمرير بالمشاركة" حتى إذا كان النوع غير معروف). تلاحظ أنت (وبقيتنا) أن العناصر الثابتة الصغيرة تكون أسرع بكثير لأن هذا هو المكان الذي يتم فيه تنفيذ التحسينات حاليًا. هذا هو نتيجة دلالات immutable مما يجعل التحسينات أسهل.

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

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

قصدت التوقع الضمني المحتمل لنوع جوليا أن يكون له نفس السلوك كما في C / C ++

قد يكون هذا سببًا جيدًا كافيًا في حد ذاته للنظر في const -> constant ، لنكون صادقين. أعتقد أن const قد تكون كلمتنا الرئيسية المختصرة الوحيدة في الوقت الحالي ، مما يجعلها غريبة على أي حال.

بيان بسيط Alias = DataType .

أنا متأكد من أن هذا جيد تمامًا حيث يكون منطقيًا ، لكنه لن يسمح بإجراء تعديلات أكثر تعقيدًا من النوع ، على سبيل المثال typealias RealMatrix{T<:Real} Matrix{T} ، ولا يجب أن يكون كذلك (إنه ربط بسيط ، وليس إنشاء Type جديد TypeVar s). ما لم ترغب في تحديده بطريقة أخرى: RealMatrix = Matrix{T <: Real} وقم بتعميم ما يفعله apply لـ TypeVar (أي يجعل TypeConstructor ) ... في الواقع هذه فكرة مثيرة للاهتمام (لكنها تحتوي على مشكلات في بناء الجملة ، وهذا هو السبب في أن typealias جميل ...).

andyferris ، لقد "لم

mjw رائع ، وأنا أتفق مع كل ذلك. :)

أخبرك بماذا ، دعنا نجرب أقرب شيء يمكننا فعله لاستطلاع الرأي باستخدام أفضل وظائف GitHub: ردود الفعل emojis.

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

| type | immutable | تتفاعل مع |
| : -: | : -: | : -: |
| struct | const struct | 👍 (+1) |
| mutable | immutable | 👎 (-1) |
| type | immutable | 😄 (ضحك) |
| composite | const composite | : تادا: (الصيحة) |
| datatype | const datatype | 😕 (مرتبك) |
| type | const type | ❤️ (قلب) |

يتوافق عدم التصويت مع التصويت الضمني لـ nuple ، بالطبع. :وجه القزم:

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

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

أنا شخصياً لا أعتقد أنني أحب وجود كلمتين جمالياً ( const type ). كما أنه يشعر ببعض التنافر المعنوي. عندما نقول const x = 1 . نعني أن x ثابت. عندما نقول const type; x; end فإننا نعني أن مثيلات من هذا النوع لا تتغير بعد البناء. من الاستيفاء المباشر ، يبدو أن قول شيء ما هو نوع ثابت يعني أن النوع نفسه لا يتغير (وهذا هو الحال بالفعل الآن). أنظر أيضا:

type foo
end
const bar = foo

لذا فإن bar هو ثابت ودائمًا ما يكون foo ، ولكنه مع ذلك ليس const type . يبدو الأمر كما لو أنه تم كتابة الدلالات الحالية لـ const (تنطبق على الروابط) ، أسماء الأنواع ثابتة بالفعل.

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

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

immutable T
    a::Int
    b::Float64
    ...
end

t = Vector{T}(10)
t[2].a = 5    # error here
# instead
c = t[2]
t[2] = T(5, c.b, ...)   # works  

تنشئ الشفرة مصفوفة أنيقة من أنواع القيم sizeof(T) * 10 ، ولكن لتغيير بعض الحقول ، يحتاج المرء إلى إعادة تعيين T(...) بالكامل ، والذي يتكون عادةً من 3-5 حقول.
إذن ، 5 سنتات خاصة بي:
type - مرجع GC المُجمع
immutable - نوع القيمة (المكدس المخصص) الذي يستحيل تغييره
mutable - نوع القيمة الذي يمكن تغييره ، خاصة في المصفوفات

نوع القيمة الذي يمكن تغييره

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

ربما ترغب في اتباع هذا الأسلوب بدلاً من ذلك: # 11902

باستثناء فصل mutables وimmutables، فإنه ينبغي أن يكون أفضل إذا كان لنا أن تقسيم القيم والمراجع.

abstract Node{T}
immutable Link{T} <: Node{T}
    value :: T
    next :: ref{Link{T}} # next :: Link{T} will be an error: Recursive type
end

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

@ كينو يشير إلى نقطة جيدة

أنا شخصياً لا أعتقد أنني أحب وجود كلمتين جمالياً (نوع ثابت). كما أنه يشعر ببعض التنافر المعنوي. عندما نقول const x = 1. فإننا نعني أن x ثابت. عندما نقول const اكتب ؛ العاشر ؛ النهاية ، فإننا نعني أن مثيلات من هذا النوع لا تتغير بعد البناء. من الاستيفاء المباشر ، يبدو الأمر وكأن قول شيء ما هو نوع ثابت يعني أن النوع نفسه لا يتغير (وهذا هو الحال بالفعل الآن)

كما ذكرت سابقًا ، أعتقد أن الدلالات "الصحيحة" قد أعطيت من قبل

type Complex{T}
    const re::T
    const im::T
end
z = Complex(1,2)

هنا z.re يتصرف تمامًا مثلما نكتب شيئًا قريبًا من const z.re = 1 ، لذلك لا يوجد تشويش دلالي حول أي الربط هو const بالضبط.

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

<strong i="19">@const</strong> type Complex{T}
   re::T
   im::T
end

بالطريقة الحالية التي يتم بها تنفيذ ذلك ، يمكن للماكرو تغيير type إلى immutable في AST. في المستقبل ، إذا تم تنفيذ البنى الثابتة جزئيًا ، فلا يزال بإمكان الماكرو إجراء عمليات التلاعب إلى AST عن طريق إضافة const إلى كل حقل ، وسيكون من الواضح للجميع ومتنوعين أنها ارتباطات الحقل وهي ثابتة. من الناحية الجمالية ، إنها أفضل من كلمتين رئيسيتين متتاليتين - نقوم بأشياء مماثلة للوظائف ( @generated ، @inline ، @proagate_inbounds ، إلخ).

@const يمكن بسهولة أن يكون @immutable أو شيء مشابه ( <strong i="31">@immutable</strong> type Val{T}; end يقرأ جيدًا ، IMO) وفكرة الماكرو متوافقة مع struct ، composite ، وهلم جرا.

@ be5invis نعم ، هذه طريقة معتادة في العديد من اللغات ، على سبيل المثال في C # يوجد struct ، والذي يتصرف بطرق عديدة مثل immutable : يتم تمريره عن طريق نسخة إلى الوظائف ، ويتم تخصيصه بشكل صريح في المصفوفات (ليست مراجع للكائنات المُدارة بواسطة GC كما في حالة class | type ). ومع ذلك فهو _mutable_ ويمكن تعديله في المصفوفات بواسطة حقل واحد.
ما أعتقد أنه في حالة immutable هناك مزيج من خاصيتين:

1. الثبات (للقيام بالبرمجة الوظيفية المناسبة)
2. التصرف كنوع قيمة في المستوى الأدنى

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

johnmyleswhite أشكرك على # 11902 ، ما زلت أعتقد أنه لا ينبغي أن يكون ذلك القبيح

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

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

لست متأكدًا مما إذا كان هذا يستحق الذكر ؛ ولكن في لغة C / C ++ ، تشير كلمة "Struct" أيضًا إلى شيء يتعلق بتخطيط البيانات. من ناحية أخرى ، من المفيد في كثير من الأحيان إعادة ترتيب أعضاء البنية للحصول على تخطيط ذاكرة أفضل. إذا كنت تفكر في إجراء تغيير جذري في بناء الجملة ، فقد يكون من المفيد أن يكون لديك آلية للتمييز بطريقة ما بين "البنيات" (مرتبة -> C interop) و "غير قابلة للتغيير" (يمكن طلبها بأي طريقة).

أنا جديد تمامًا على جوليا ، لذلك أنا آسف إذا فاتني شيء واضح.

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

لإضافة اقتراح آخر ، يبدو أن ما يلي هو الأفضل بالنسبة لي:

• استخدم struct بدلاً من immutable .

• استخدم struct! بدلاً من type . عند التحدث باللغة الإنجليزية ، يجب الإشارة إلى هذا باسم "بنية متغيرة".

  • (ربما) تسمح بوجود بعض الحقول داخل struct! ليتم تمييزها على أنها const .

بعض المبررات والأفكار:

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

2) أعتقد أنه يجب تفضيل الأنواع غير القابلة للتغيير بشكل عام على الأنواع القابلة للتغيير ، نظرًا لأنها تخضع لمزيد من التحسينات ولديها سلوك أكثر قابلية للتنبؤ للمبرمج.

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

تحديث : اعتدت أن أحصل على record بدلاً من struct ، لكن record! يشبه الفعل كثيرًا. بعض الخيارات الأخرى التي تتبادر إلى الذهن: newtype ، typedef (والتي ستربك مبرمجي لغة C لمدة 10 ثوانٍ) ، أو composite ، أو concrete كما اقترح أحد الأشخاص أعلاه .

هل من المحتمل أن يحدث شيء ما في هذه المساحة قبل تجميد ميزة v0.6؟

ربما لا ، نظرًا لأنه لم يتم اتخاذ أي قرار (على الأقل علنًا) ونحن على بعد 10 أيام فقط من التجميد.

لم أتابع هذا الأمر بعناية ، لكن هناك تعليقًا واحدًا هو أنه إذا / عندما يتغير هذا ، أود أن أطلب منك أولاً الإبلاغ جيدًا عن الملف / رقم السطر المخالف. أو على الأقل الوحدة ؛ في 0.5 لا يزال من الصعب أحيانًا حتى معرفة الحزمة التي تحتوي على @deprecate d _binding .

xref https://github.com/JuliaLang/julia/pull/20418#issuecomment -277475415