5 ms·

This makes me sad and confused. Isn't "Data" the worst possible name one could use for anything in programming? I am not exaggerating; it is literally the exam

by otikik 4y ago

This makes me sad and confused. Isn't "Data" the worst possible name one could use for anything in programming? I am not exaggerating; it is literally the example I have always used. If Data is an immutable struct, call it ImmutableStruct. If that's too long, there's ImmuStruct or IStruct. Any of those names is better than Data. They are all more concise.

corytheboyd 4y ago
Hell, Struct already accepts keyword argument options (keyword_init), they could have just added a new one (immutable: true) IMO ImmutableStruct is exactly as verbose as BasicObject, something that has been in Ruby for a long time now. ImmutableStruct is a massively better name for this.
- knodi123 4y ago
  > Struct already accepts keyword argument options (keyword_init), they could have just added a new one (immutable: true) The article explains the reason they didn't do that: Ruby maintainers decided that Struct could not be made to suit the requirements of a value object. The core Struct class is a “somewhat alike” value-object; it is compared by value and is, mutable collection-alike (defines to_a and is Enumerable) dictionary-alike (has [] and .values methods)
inopinatus 4y ago
See https://bugs.ruby-lang.org/issues/16122 https://bugs.ruby-lang.org/issues/16122 for lengthy deliberation of the justification (in particular, of the relative utility vs merely enhancing Struct), and discussion of the naming options, but let's crucially note that Data itself is not an immutable struct, it is a factory for classes when the instances of those classes are intended to be immutable structs. Hence Product = Data.define(:name, :price) creates a Product class, most likely during initialisation; then in application code we could subsequently write cheese = Product.new("Wensleydale 200g", 499) and here it's cheese that is immutable; the point being, we're still naming our domain objects purposefully. In that light, I think it's appropriate for a language to use generic terms for fundamental elements. For example, almost everything is descended from Object and we're fine with it.
- otikik 4y ago
  Thank you for the link and the explanation. I still think Data should not have been used
cratermoon 4y ago
https://wiki.c2.com/?DontNameClassesObjectManagerHandlerOrData https://wiki.c2.com/?DontNameClassesObjectManagerHandlerOrDa...
djur 4y ago
"ImmutableStruct" does not communicate the key detail that these are compared by value, not identity. "Data class" is a common term for this in other languages, including Java, Kotlin, and Python. "Data" is definitely more concise (almost by definition) and I would argue it's more precise as well.
- nayuki 4y ago
  In Java, "data class" might be a common term that existed for a long time. But a language-level feature was introduced in SE 14 as "records": https://docs.oracle.com/en/java/javase/14/language/records.html https://docs.oracle.com/en/java/javase/14/language/records.h...

by otikik 4y ago

corytheboyd 4y ago

Hell, Struct already accepts keyword argument options (keyword_init), they could have just added a new one (immutable: true) IMO ImmutableStruct is exactly as verbose as BasicObject, something that has been in Ruby for a long time now. ImmutableStruct is a massively better name for this.

knodi123 4y ago
> Struct already accepts keyword argument options (keyword_init), they could have just added a new one (immutable: true) The article explains the reason they didn't do that: Ruby maintainers decided that Struct could not be made to suit the requirements of a value object. The core Struct class is a “somewhat alike” value-object; it is compared by value and is, mutable collection-alike (defines to_a and is Enumerable) dictionary-alike (has [] and .values methods)

inopinatus 4y ago

See https://bugs.ruby-lang.org/issues/16122 https://bugs.ruby-lang.org/issues/16122 for lengthy deliberation of the justification (in particular, of the relative utility vs merely enhancing Struct), and discussion of the naming options, but let's crucially note that Data itself is not an immutable struct, it is a factory for classes when the instances of those classes are intended to be immutable structs. Hence Product = Data.define(:name, :price) creates a Product class, most likely during initialisation; then in application code we could subsequently write cheese = Product.new("Wensleydale 200g", 499) and here it's cheese that is immutable; the point being, we're still naming our domain objects purposefully. In that light, I think it's appropriate for a language to use generic terms for fundamental elements. For example, almost everything is descended from Object and we're fine with it.

otikik 4y ago
Thank you for the link and the explanation. I still think Data should not have been used

cratermoon 4y ago

https://wiki.c2.com/?DontNameClassesObjectManagerHandlerOrData https://wiki.c2.com/?DontNameClassesObjectManagerHandlerOrDa...

djur 4y ago

"ImmutableStruct" does not communicate the key detail that these are compared by value, not identity. "Data class" is a common term for this in other languages, including Java, Kotlin, and Python. "Data" is definitely more concise (almost by definition) and I would argue it's more precise as well.

nayuki 4y ago
In Java, "data class" might be a common term that existed for a long time. But a language-level feature was introduced in SE 14 as "records": https://docs.oracle.com/en/java/javase/14/language/records.html https://docs.oracle.com/en/java/javase/14/language/records.h...