Right; I’m saying that attaching properties to each endpoint of an edge isn’t fundamentally different from having edges with different weights in each direction. Mathematically speaking, they’re isomorphic.
It might be clearer to call them directional edge weights, but it’s not a concept that’s alien to graph theory.
They both have a hole, but right. Donuts and coffee cups are both objects, and you presumably have a base object class. They’re both (probably) movable, and you probably have a subclass of object for that. The coffee cup is a container, and you probably have a class for containers, but not all containers are portable and not all portable things are containers, so you presumably have container-specific properties and methods on the container class, rather than on the general object class or on the portable object class. And so on.
One of the things I love about IF is the idea that you can create something that seems perfect, but if you look under the covers you realize there are a lot of smoke and mirrors.
As an established application architect, I also understand that perfection is not only impossible, it’s a net-negative in software engineering. I can’t count how many over-engineered systems I’ve come across in my 38 years in IT.
Your comments triggered warning bells because I started thinking about ILocationNode and IThingsWithHolesNode and realized that abstractions are just really bad ideas. It may help you think things through, but it’s a rathole you should avoid at all costs.
Flat, simple, reusable patterns are better served without complex object-oriented abstractions.
I’m using C# and a graph (which is just a List of Lists) because of Linq, which allows me to query the graph in any way I choose. I don’t need abstractions because Linq gives me a lens into everything in the graph. Here’s an example, though I’m not sure I’d ever use it:
Well, that’s pretty strong. And in the end it’s your code, and I’m (still) not trying to talk you out of anything.
But what you’re saying is mostly true of application design (and almost all game design)…but as I understand it you’re not trying to write a game, you’re trying to write a game engine, a framework. That is, you’re not hammering a nail, you’re trying to design a hammer. Those are two different things, particularly if you’re expecting a lot of people other than you to use the hammer, and you want to accommodate them attempting to use the hammer in a variety of different ways.
Back in the late '79s implementing Zork by first designing a virtual machine would’ve been “over-design” if all they wanted to do was implement Zork. But I think it’s only because Joel Beres and Marc Blank decided to dive into that particular rathole that we’re even having this discussion.