Newest at the top
| 2025-05-03 19:50:14 +0200 | <EvanR> | I'm not sure what use as objects means |
| 2025-05-03 19:49:27 +0200 | <[exa]> | EvanR: probably an entity then. I'm not trying to dodge IDs, more like trying to find what name and type the functions that "do it" should be so that I'm preferably separating the objectness and entityness of the things as well as possible. I want to use these things as objects when they get deserialized. |
| 2025-05-03 19:48:31 +0200 | <EvanR> | if you just have a set of unique tuples the tuple itself can be the ID |
| 2025-05-03 19:48:22 +0200 | <monochrom> | Alternatively if it turns out RDF = prolog but in XML syntax, I can work with that too. >:) |
| 2025-05-03 19:48:04 +0200 | <[exa]> | yes datalog is prolog without actual computation |
| 2025-05-03 19:48:01 +0200 | <EvanR> | if object = entity, then you need IDs, to name the entity |
| 2025-05-03 19:47:53 +0200 | <monochrom> | I don't know datalog. May I think in prolog instead? |
| 2025-05-03 19:47:25 +0200 | <monochrom> | Then you hash (the value and a serial number). |
| 2025-05-03 19:47:12 +0200 | <[exa]> | monochrom: imagine datalog where all facts are `sompredicate(somesubject, someobject).` |
| 2025-05-03 19:46:29 +0200 | <[exa]> | monochrom: yes (in the future they might differentiate by people attaching stuff to either identifier) |
| 2025-05-03 19:46:13 +0200 | <monochrom> | Frankly I don't know RDF. |
| 2025-05-03 19:46:12 +0200 | michalz | (~michalz@185.246.207.221) |
| 2025-05-03 19:45:43 +0200 | <monochrom> | Do you have a scenerio where there are two objects, all their fields have the same value, but you would prefer to call them 2 objects rather than 1 object? This question determines whether you can just hash the values. |
| 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 |