Newest at the top
| 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 |
| 2025-05-03 18:37:34 +0200 | Square | (~Square@user/square) Square |
| 2025-05-03 18:36:32 +0200 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-05-03 18:32:51 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-05-03 18:32:21 +0200 | Square3 | (~Square@user/square) (Remote host closed the connection) |
| 2025-05-03 18:32:20 +0200 | acidjnk_new3 | (~acidjnk@p200300d6e71c4f76fc5d8daab5a27dee.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-05-03 18:23:14 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-05-03 18:18:10 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-03 18:15:35 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 244 seconds) |
| 2025-05-03 18:11:57 +0200 | traxex | (traxex@user/traxex) (Quit: Lost terminal) |
| 2025-05-03 18:09:14 +0200 | sajenim | (~sajenim@user/sajenim) (Ping timeout: 252 seconds) |
| 2025-05-03 18:08:57 +0200 | Pozyomka | (~pyon@user/pyon) (Quit: WeeChat 4.6.1) |
| 2025-05-03 17:59:40 +0200 | ttybitnik | (~ttybitnik@user/wolper) (Remote host closed the connection) |
| 2025-05-03 17:56:26 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |