Newest at the top
| 2025-05-03 19:45:27 +0200 | <[exa]> | again with RDF you more like "prove that something exists by finding all its bits in the heap" instead of deserializing per se |
| 2025-05-03 19:45:04 +0200 | <EvanR> | if it's not objects but just values with nested structure, a classic serialization is lisp expressions |
| 2025-05-03 19:44:44 +0200 | <[exa]> | ok so maybe serialization is not the right thing to even say here |
| 2025-05-03 19:44:20 +0200 | <[exa]> | it's super effective! |
| 2025-05-03 19:43:43 +0200 | <EvanR> | plays the rainbow table card |
| 2025-05-03 19:43:26 +0200 | [exa] | ties EvanR in a loop! hash out of that! |
| 2025-05-03 19:43:03 +0200 | <EvanR> | hides |
| 2025-05-03 19:43:00 +0200 | <EvanR> | [exa], ID = hash of the value! |
| 2025-05-03 19:42:20 +0200 | <EvanR> | like IORefs |
| 2025-05-03 19:42:16 +0200 | <EvanR> | maybe all your objects actually be expressions (often, they're not) |
| 2025-05-03 19:42:05 +0200 | <[exa]> | I'm literally trying to find the above abstraction that would make the identifiers somewhat manageable |
| 2025-05-03 19:41:52 +0200 | bilegeek | (~bilegeek@2600:1008:b01a:5c24:8c91:aa31:8c9:aaf) bilegeek |
| 2025-05-03 19:41:33 +0200 | <[exa]> | it's not an object, instead it is _____ ? |
| 2025-05-03 19:41:26 +0200 | <monochrom> | Hell, object = record = data = data structure = ... |
| 2025-05-03 19:41:16 +0200 | <[exa]> | good we're getting somewhere |
| 2025-05-03 19:41:11 +0200 | <monochrom> | Oh I just define "object = record". :) |
| 2025-05-03 19:40:53 +0200 | <monochrom> | haha |
| 2025-05-03 19:40:52 +0200 | <EvanR> | if it's a document with nested records then maybe it's not "an object" |
| 2025-05-03 19:40:42 +0200 | tromp | (~textual@2001:1c00:3487:1b00:31c9:5f27:18bf:4d4e) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-05-03 19:40:32 +0200 | <int-e> | EvanR: how to troll efficiently by ignoring context? |
| 2025-05-03 19:40:10 +0200 | <EvanR> | but what's the original subject |
| 2025-05-03 19:40:10 +0200 | <monochrom> | Yeah in practice, one writes in Haskell and compile by MicroHs! |
| 2025-05-03 19:40:03 +0200 | <EvanR> | unless the database has json support |
| 2025-05-03 19:39:50 +0200 | <EvanR> | if the original subject was "a json value" then yeah, you would have to make up artificial and irrelevant IDs to store it in a database |
| 2025-05-03 19:39:44 +0200 | <monochrom> | "How do I serialize objects?" "Use SKI so it's /dev/null when you deserialize!" |
| 2025-05-03 19:39:34 +0200 | <int-e> | (I'm too weak for combinatory logic; the only way I've ever been able to write combinatory logic programs is using abstraction elimination.) |
| 2025-05-03 19:39:24 +0200 | <[exa]> | monochrom: ofc the IDs are a technical necessity but I thought more of the data model layer. Esp. for RDF when you want the IDs to be somewhat stable and carry some mild meaning |
| 2025-05-03 19:39:02 +0200 | <int-e> | I escaped identifiers but at what cost! |
| 2025-05-03 19:38:43 +0200 | <monochrom> | Oh well I guess that's another solution, by having no objects at all! |
| 2025-05-03 19:38:17 +0200 | <int-e> | :P |
| 2025-05-03 19:38:16 +0200 | <int-e> | No ids, just two combinators and application. |
| 2025-05-03 19:37:56 +0200 | <monochrom> | And especially if your object graph is not a tree, all the more important to use IDs so n objects do not become a tree of 2^n nodes, or even worse, an infinite tree just because there is a cycle. |
| 2025-05-03 19:37:55 +0200 | <int-e> | monochrom: just do combinatory logic |
| 2025-05-03 19:36:29 +0200 | <monochrom> | One can never escape IDs. High-level languages deceive you into thinking that you can, by not telling you that pointers and addresses look like 0xdeadbeef which are totally IDs. |
| 2025-05-03 19:36:01 +0200 | <EvanR> | instead of the main model |
| 2025-05-03 19:35:46 +0200 | <EvanR> | and in that perspective, objects nested inside each other is just one way to view the entities and relations |
| 2025-05-03 19:35:21 +0200 | <[exa]> | hm good point |
| 2025-05-03 19:34:56 +0200 | <EvanR> | so not sure if it's not part of the model |
| 2025-05-03 19:34:45 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 248 seconds) |
| 2025-05-03 19:34:37 +0200 | <EvanR> | ID is what makes entities entities and not values, making the rows not redundant (and illegal in relational algebra) duplicates |
| 2025-05-03 19:34:13 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-05-03 19:32:25 +0200 | <[exa]> | Possible complication: objects contain more objects and serialization has to invent sensible identifiers for these. |
| 2025-05-03 19:31:27 +0200 | <[exa]> | "exist" without knowing their "name" (URI), byt the name has to be present in all triples that describe the object.) |
| 2025-05-03 19:31:25 +0200 | <[exa]> | Are there any good approaches to serializable objects (think like aeson-style serialization) where the serialization has to contain "externally resolvable" identifiers? (Typically in databases, the ID should not be a part of object model because it's more of a reference that should be transparent and/or held by others, but has to be present in row operations. Similarly with RDF, haskellish objects |
| 2025-05-03 19:24:32 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-05-03 19:23:27 +0200 | acidjnk_new3 | (~acidjnk@p200300d6e71c4f76bcfd7e139b6b957f.dip0.t-ipconnect.de) acidjnk |
| 2025-05-03 19:07:50 +0200 | ttybitnik | (~ttybitnik@user/wolper) ttybitnik |
| 2025-05-03 19:04:50 +0200 | Buliarous | (~gypsydang@46.232.210.139) Buliarous |
| 2025-05-03 19:04:22 +0200 | Buliarous | (~gypsydang@46.232.210.139) (Read error: Connection reset by peer) |
| 2025-05-03 18:41:43 +0200 | __jmcantrell__ | (~weechat@user/jmcantrell) jmcantrell |