3 ms·

> 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 fa

by 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.
        9rx 2y ago
        > No I'm not. Enjoy your scrambled bones, then, I guess. But even if you want to model the world as having only one egg type, that type decidedly does not cleanly fit into "animal" or "food", so your taxonomy doesn't work. > You're going to make an Egg interface and divide it into two subtypes EatableEgg and HatchableEgg. This seems like a poor assumption. In the real world, if an "EatableEgg" is fertilized into a "HatchableEgg" there will be a type conversion. What was an "EatableEgg" is now a "HatchableEgg" and the "EatableEgg" no longer exists. What do you need the interface for? > I don't think you picked up on it but I have one thing Right, but we're talking about types, not things. Things can come in many different types. You even told us a story about how you consider eggs, which are the same thing, to be of different types, so this didn't go unnoticed by you earlier. > Also you have to create a new package now called Types and that's where you put your Egg interface. If you were to have a such a thing, wouldn't it go in something like "reproductive structure"? "types" is a strange fit alongside "animal" and "food". Revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear.
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?

by 9rx 2y ago

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.
      - 9rx 2y ago
        > No I'm not. Enjoy your scrambled bones, then, I guess. But even if you want to model the world as having only one egg type, that type decidedly does not cleanly fit into "animal" or "food", so your taxonomy doesn't work. > You're going to make an Egg interface and divide it into two subtypes EatableEgg and HatchableEgg. This seems like a poor assumption. In the real world, if an "EatableEgg" is fertilized into a "HatchableEgg" there will be a type conversion. What was an "EatableEgg" is now a "HatchableEgg" and the "EatableEgg" no longer exists. What do you need the interface for? > I don't think you picked up on it but I have one thing Right, but we're talking about types, not things. Things can come in many different types. You even told us a story about how you consider eggs, which are the same thing, to be of different types, so this didn't go unnoticed by you earlier. > Also you have to create a new package now called Types and that's where you put your Egg interface. If you were to have a such a thing, wouldn't it go in something like "reproductive structure"? "types" is a strange fit alongside "animal" and "food". Revisit the model in a way that actually reflects the real world and your circular dependencies are bound to disappear.

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?