Timeline for Is circular reference with Typescript array properties bad design?
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 11, 2019 at 13:23 | comment | added | Ray | How do we move to a chat? Your examples while I appreciate them, appear to make a case that very simple things that are done eloquently in other languages are a very bad idea. You would instantiate the ocean first, then load in your boats. This is how OOP works. Your comment on, "what if theres only one boat, memory overhead" That doesn't matter because in the way you're providing as a solution you would still need an ocean which would be the same memory usage. You wouldn't have to fetch all boats to use the ocean for a single boat. | |
| Jun 11, 2019 at 5:04 | comment | added | Andy | @Abstract I have answered your comments in the question. | |
| Jun 11, 2019 at 5:04 | history | edited | Andy | CC BY-SA 4.0 |
added 2487 characters in body
|
| Jun 10, 2019 at 22:30 | comment | added | Ray | Whats even more funny is this would still cause a circular dependency problem because you've type scripted the ocean variable causing the import on boat.ts. | |
| Jun 10, 2019 at 21:26 | comment | added | Ray | And even then, a boat doesn't have to have an ocean. It could be being built at the moment. | |
| Jun 10, 2019 at 21:20 | comment | added | Ray | I would argue this isn't the chicken or the egg problem. A ocean doesn't have to be created for a boat but a ocean has to be created for a boat. Does it not seem redundant to pass through a variable ocean when you intend your boat to be in only one ocean at a time? If it changes ocean, you would change it within its property, that makes real world sense. | |
| Jun 10, 2019 at 17:58 | history | answered | Andy | CC BY-SA 4.0 |