Timeline for Are arrays -as data structures- suitable for constructors?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 2, 2023 at 7:52 | history | edited | Laiv | CC BY-SA 4.0 | added 4 characters in body |
| Sep 21, 2019 at 7:31 | history | edited | besc | CC BY-SA 4.0 | fixed typo |
| Jul 24, 2017 at 6:58 | history | edited | Laiv | CC BY-SA 3.0 | spellcheck revision |
| Jul 23, 2017 at 19:31 | vote | accept | Laiv | ||
| Jul 23, 2017 at 19:31 | comment | added | Laiv | I decided to check this answer because I think It express better my fail at stating my question and at the same time provide me with useful and meaningful insights. Thank you besc. | |
| Jul 23, 2017 at 8:54 | comment | added | besc | They reasoned that a strongly typed data structure is less flexible and prone to type conversion errors. Their reasoning is correct, but those properties are usually exactly what you want. It took me a while to realize but now I see the type system as a safety net. I want it to complain loudly and immediately if I do something weird with types. Things like in Javascript 1 == "1" returning true instead of complaining about a type mismatch, scare me. It’s mindbogglingly error prone. If you can circumvent the type system in such a way, what’s the point in having one at all? | |
| Jul 22, 2017 at 22:45 | comment | added | user148298 | A few years ago, I read a book about object modeling, I think the title was "Head First: Object Modeling." The book was well written and worked through several design problems by creating data structures and then refining them as more requirements were added. The author(s) solved every data design problem with a dictionary instead of a strongly typed data structure. They reasoned that a strongly typed data structure is less flexible and prone to type conversion errors. I'm glad that I am not the only one who found the book's design strategies ill-advised. | |
| Jul 22, 2017 at 22:17 | comment | added | Laiv | True. I come to realise that I understated the importance of the lack on meaningful param names in the former question. I would like to check your question, but looks like the likely probable answer is that "It depends" and "I rushed into the solution without enough and meaningful info". Your answer, alongside with Robert and JaquesB comments, Ewan and juhist are partally right. The answer could be perfectly a sum of all them. I will think if I summarize It into a own answer or just check yours. Hope you don't mind. | |
| Jul 22, 2017 at 22:01 | comment | added | besc | Maybe what you’re getting at is the question of “How to decide when to use general built-in types and when to create custom types?” Though, imo, that warrants its own question – and a bunch of article-long answers. :) | |
| Jul 22, 2017 at 9:49 | comment | added | Laiv | Reading this answer, I come to realise that maybe the title of my question doesn't reflect my concern. Would you mind to suggest a better way to do It? | |
| Jul 22, 2017 at 9:44 | comment | added | Laiv | This is the sort of answer I was expecting. I also suggested in my answer encapsulation, which indeed, contribute to type our model far beyone from the primitive types. Despite my examples don't reflect this point. However, your point around typing the concept ID has make me realise that I often fail in modeling this elements. I like your question and hence the Up vote. If you don't mind I would like see If I'm missing something else. | |
| Jul 22, 2017 at 9:24 | history | answered | besc | CC BY-SA 3.0 |