[HN Gopher] Representing Heterogeneous Data
       ___________________________________________________________________
        
       Representing Heterogeneous Data
        
       Author : grep_it
       Score  : 43 points
       Date   : 2023-10-01 03:25 UTC (19 hours ago)
        
 (HTM) web link (journal.stuffwithstuff.com)
 (TXT) w3m dump (journal.stuffwithstuff.com)
        
       | skybrian wrote:
       | A bit surprising that this shows up here even though Bob
       | apparently hasn't figured out a good answer yet. Maybe someone
       | will know a good solution?
        
         | eska wrote:
         | The relational db/DOD/ECS solution would be to just not force
         | things into a single type.
         | 
         | We don't have one melee fighter, but usually multiple, so
         | design for that case. Normalize your data (split data that's
         | optional into own types) and have multiple tables/arrays for
         | each of these components. Then create another table for the
         | possible combinations, e.g. a melee fighter table. You then
         | iterate over the melee fighter table with your melee code
         | rather than the component tables
        
           | angra_mainyu wrote:
           | This. ECS is an extremely powerful approach that makes adding
           | new features ridiculously easy but it does require somewhat
           | of a conceptual readjustment at first from the usual "a class
           | to rule them all" approach.
        
           | skybrian wrote:
           | How about if the melee fighter switches weapons to a bow and
           | arrow?
           | 
           | In games, things often transform into other things, and we
           | want to still consider them the same entity.
        
             | angra_mainyu wrote:
             | If I'm understanding your question correctly (how do I
             | change some of the components of the entity and still know
             | it's the same entity) the answer is that usually in ECS
             | entities have an ID assigned to them, so as long as the
             | entity ID is the same it doesn't matter if the associated
             | WeaponComponent records change.
        
         | j-pb wrote:
         | I feel like RDF/TripleStores and ECS both offer nice solutions
         | to this problem.
         | 
         | With both you kinda separate your application into a control-
         | plane (functions and other code) and a data-plane (in-memory
         | database). With the control-plane referencing entities from the
         | data-plane via opaque identifiers.
         | 
         | Conjunctive queries over the database are then equivalent to a
         | structural type system with literal types, and allow for
         | accepting potentially every entity in the system at every point
         | in the system so long as the types match.
        
           | civilitty wrote:
           | Anyone know of any good books about or introductions to RDF
           | triples that cover practical applications? I've been meaning
           | to look into it for representing data about US laws and
           | regulations but ChatGPT isn't really helping.
        
             | cloogshicer wrote:
             | I'd also be really interested in something like this.
        
             | j-pb wrote:
             | "Semantic web for the working ontologist" by Dean Allemang
             | and James Hendler might be a good starter if you want to go
             | proper Rdf/RDFS/OWL.
             | 
             | TBH I would probably take a look at terminusDB though. They
             | do things a bit differently, and are def. more opinionated
             | (more closed world, more databasey) but that
             | opinionatedness helps provide a bit saner/stable foundation
             | than the very grown rest of the ecosystem imho.
        
       | elcritch wrote:
       | > This is a real trade-off. The feature I have here provides
       | strictly less static safety than using sum types. There is a
       | slight performance cost to checking the type tag when accessing
       | case-specific fields. In return, you get simpler, more familiar
       | syntax for working with case-specific fields, including mutable
       | ones.
       | 
       | Interesting post! Nim uses variant/case objects as well.
       | Generally they're pretty handy and more flexible than sum types
       | as you can access non-variant fields as regular objects. Though
       | it means you can't use the same field name twice, however on the
       | other hand you can bring common fields out of the case portion.
       | Also, a single object can have multiple case variants which can
       | be handy.
       | 
       | There's a PR for adding the stricter sum types and pattern
       | matching as well. https://github.com/nim-lang/RFCs/issues/525
       | Currently I just use a library for sum type syntax on top of
       | object variants: https://github.com/andreaferretti/patty
        
       ___________________________________________________________________
       (page generated 2023-10-01 23:01 UTC)