3 ms·

Your joking. I have a hundred food items and a hundred animal items. Cows produce milk. Chickens produce eggs. Eggs produce chickens. It makes 100 percent sens

Your joking. I have a hundred food items and a hundred animal items. Cows produce milk. Chickens produce eggs. Eggs produce chickens. It makes 100 percent sense to make two folders. Food and animals. ‘I suspect your “domain model” is ill conceived’??? You buy into that? Don’t follow what those idiots tell you. You realize that we use these actual separations between food and animals in the real world? And now because of some design philosophy the domain model is ill conceived? The result is a more convoluted domain model to make things flow. Actually I think this is an easier way to explain it to you. The “domain model” or aka categorization of food and animals works in reality and every other language because it’s not a bad design decision. The reason why it doesn’t work in go is because go is the bad design decision.

9rx 2y ago
> You realize that we use these actual separations between food and animals in the real world? The distinction between "animal" and "food" isn't necessarily faulty, but an egg considered to be for food and an egg considered to be for hatching are deemed distinct types in the real world. An egg from the grocery store is not going to hatch no matter how hard you coddle it. This is not the same type of egg that will hatch a chicken. Reusing the same model for both types of eggs does not work in the real world, and thus it stands to reason that it doesn't work in software either. Revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear.
- ninetyninenine 2y ago
  Who said it has to be a grocery store. I’m in a farm. Some eggs I eat, some eggs I hatch. I have a food bin and an animal pen. Two different boxes for two different things. Makes sense in the real world. Why doesn’t it make sense in go? You literally think there’s some elegant underlying principle here having to do with categorization do you? It’s mind boggling to me how arbitrary decisions made by the designers of go are thought of as fundamental design rules. When people use the word “domain model” I know the complex nomenclature has actually led them astray. These are just folders and categories. The term domain model doesn’t change a thing other than making it sound smarter.
  - 9rx 2y ago
    > Some eggs I eat, some eggs I hatch. Exactly. Like you describe, this domain model has at least two different types of eggs. This matches what was described in the original comment. But, in the original comment, the author was trying to shoehorn all functionality into a single egg type. And, unsurprisingly, it didn't work for him. It wouldn't work in the real world either. Revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear.
    - ninetyninenine 2y ago
      Come on. Think about it. The egg hatches or is eaten. Now you have HatchingEgg, and EatableEgg types. Let's be real about where the shoe horning is happening.
      - 9rx 2y ago
        Essentially. More likely, without straying too far from the original, you would have something like `animal.Egg` and `food.Egg` (although it is likely that you would want to stray from the original in an actual setting). You are going to do that type of thing regardless of the language (and especially in languages with more advanced type systems!), even where circular imports and other code structure methodologies are supported. You wouldn't want your `scrambleEgg` function to accept an egg intended to be hatched. The bones are unpleasant.
        ninetyninenine 2y ago
        >You're going to do that type of thing regardless of the language No I'm not. I'm going to make one Type and it's going to be called EGG. You're going to make an Egg interface and divide it into two subtypes EatableEgg and HatchableEgg. I don't think you picked up on it but I have one thing, you created 3. And you created 3 just to avoid an orthogonal issue of dependencies. You aren't getting it. In my statement above I was implying that YOU are shoehorning things, NOT me. Also you have to create a new package now called Types and that's where you put your Egg interface. So go forces you to create a third meta category while other languages I can choose whether I want that or not. Or I just don't use folders at all in go. Then this issue doesn't even exist. It only exists because I happened to want to use folders, but I can get rid of circular dependencies simply by organizing everything by files.
- imp0cat 2y ago
  Actually, eggs bought in a grocery store absolutely can hatch. https://www.youtube.com/watch?v=bMQ99Y64t90 https://www.youtube.com/watch?v=bMQ99Y64t90 and many more such examples
  - 9rx 2y ago
    That is an unusual looking chicken egg.
    - ninetyninenine 2y ago
      Doesn't this break your entire model of the universe? Doesn't it allow you to see that your model above doesn't even work?

9rx 2y ago

> You realize that we use these actual separations between food and animals in the real world? The distinction between "animal" and "food" isn't necessarily faulty, but an egg considered to be for food and an egg considered to be for hatching are deemed distinct types in the real world. An egg from the grocery store is not going to hatch no matter how hard you coddle it. This is not the same type of egg that will hatch a chicken. Reusing the same model for both types of eggs does not work in the real world, and thus it stands to reason that it doesn't work in software either. Revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear.

ninetyninenine 2y ago
Who said it has to be a grocery store. I’m in a farm. Some eggs I eat, some eggs I hatch. I have a food bin and an animal pen. Two different boxes for two different things. Makes sense in the real world. Why doesn’t it make sense in go? You literally think there’s some elegant underlying principle here having to do with categorization do you? It’s mind boggling to me how arbitrary decisions made by the designers of go are thought of as fundamental design rules. When people use the word “domain model” I know the complex nomenclature has actually led them astray. These are just folders and categories. The term domain model doesn’t change a thing other than making it sound smarter.
- 9rx 2y ago
  > Some eggs I eat, some eggs I hatch. Exactly. Like you describe, this domain model has at least two different types of eggs. This matches what was described in the original comment. But, in the original comment, the author was trying to shoehorn all functionality into a single egg type. And, unsurprisingly, it didn't work for him. It wouldn't work in the real world either. Revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear.
  - ninetyninenine 2y ago
    Come on. Think about it. The egg hatches or is eaten. Now you have HatchingEgg, and EatableEgg types. Let's be real about where the shoe horning is happening.
    - 9rx 2y ago
      Essentially. More likely, without straying too far from the original, you would have something like `animal.Egg` and `food.Egg` (although it is likely that you would want to stray from the original in an actual setting). You are going to do that type of thing regardless of the language (and especially in languages with more advanced type systems!), even where circular imports and other code structure methodologies are supported. You wouldn't want your `scrambleEgg` function to accept an egg intended to be hatched. The bones are unpleasant.
      - ninetyninenine 2y ago
        >You're going to do that type of thing regardless of the language No I'm not. I'm going to make one Type and it's going to be called EGG. You're going to make an Egg interface and divide it into two subtypes EatableEgg and HatchableEgg. I don't think you picked up on it but I have one thing, you created 3. And you created 3 just to avoid an orthogonal issue of dependencies. You aren't getting it. In my statement above I was implying that YOU are shoehorning things, NOT me. Also you have to create a new package now called Types and that's where you put your Egg interface. So go forces you to create a third meta category while other languages I can choose whether I want that or not. Or I just don't use folders at all in go. Then this issue doesn't even exist. It only exists because I happened to want to use folders, but I can get rid of circular dependencies simply by organizing everything by files.
imp0cat 2y ago
Actually, eggs bought in a grocery store absolutely can hatch. https://www.youtube.com/watch?v=bMQ99Y64t90 https://www.youtube.com/watch?v=bMQ99Y64t90 and many more such examples
- 9rx 2y ago
  That is an unusual looking chicken egg.
  - ninetyninenine 2y ago
    Doesn't this break your entire model of the universe? Doesn't it allow you to see that your model above doesn't even work?