| 00:28:33 | * | exebook_ joined #nim |
| 00:32:23 | * | exebook quit (Ping timeout: 260 seconds) |
| 00:51:27 | * | yglukhov quit (Remote host closed the connection) |
| 01:05:40 | * | jaco60 quit (Ping timeout: 250 seconds) |
| 01:18:15 | * | Demon_Fox joined #nim |
| 01:36:02 | * | rektide quit (Ping timeout: 246 seconds) |
| 01:42:17 | * | rektide joined #nim |
| 01:51:00 | * | pregressive quit (Remote host closed the connection) |
| 01:51:55 | * | yglukhov joined #nim |
| 01:57:49 | * | yglukhov quit (Ping timeout: 276 seconds) |
| 02:16:27 | * | brson quit (Quit: leaving) |
| 02:16:58 | * | brson joined #nim |
| 02:19:11 | * | brson quit (Client Quit) |
| 02:38:34 | * | awsteele joined #nim |
| 02:44:35 | * | awsteele quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 02:47:15 | * | awsteele joined #nim |
| 02:54:20 | * | yglukhov joined #nim |
| 02:58:35 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 03:04:23 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 03:10:23 | * | bigfondue_ joined #nim |
| 03:11:39 | * | bigfondue quit (*.net *.split) |
| 03:11:40 | * | cyraxjoe quit (*.net *.split) |
| 03:11:40 | * | mlitwiniuk quit (*.net *.split) |
| 03:11:40 | * | huonw quit (*.net *.split) |
| 03:14:12 | * | Jesin joined #nim |
| 03:22:11 | * | mlitwiniuk joined #nim |
| 03:22:11 | * | cyraxjoe joined #nim |
| 03:22:11 | * | huonw joined #nim |
| 03:25:26 | * | biscarch quit (Ping timeout: 260 seconds) |
| 03:26:43 | * | biscarch joined #nim |
| 03:58:38 | * | ^aurora^ joined #nim |
| 04:20:28 | * | awsteele quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 04:24:01 | * | ^aurora^ quit (Read error: No route to host) |
| 04:29:03 | * | pregressive joined #nim |
| 04:56:03 | * | yglukhov joined #nim |
| 05:00:05 | * | yglukhov quit (Ping timeout: 246 seconds) |
| 05:23:57 | * | darkf joined #nim |
| 05:30:48 | * | pregressive quit (Remote host closed the connection) |
| 05:44:58 | * | bjz joined #nim |
| 05:45:22 | * | bjz quit (Client Quit) |
| 06:13:03 | * | nsf joined #nim |
| 06:57:27 | * | yglukhov joined #nim |
| 07:01:49 | * | yglukhov quit (Ping timeout: 245 seconds) |
| 07:07:29 | nsf | https://gist.github.com/nsf/466640dd541ed71f5479 - slightly updated the coroutines, now it shows how one returns values from "await" |
| 07:07:51 | nsf | now that's when memory management becomes tricky |
| 07:08:16 | nsf | if you want for multiple coroutines, you have to gather values from different threads |
| 07:08:24 | nsf | no way to do that without some form of shared memory |
| 07:08:37 | nsf | well.. there is always a way, but |
| 07:45:50 | ldlework | My finalizer doesn't seem to get called |
| 07:55:33 | ldlework | I don't really understand either |
| 07:55:52 | ldlework | anyone around that understands them? |
| 07:57:59 | * | yglukhov joined #nim |
| 08:02:34 | * | yglukhov quit (Ping timeout: 272 seconds) |
| 08:20:18 | * | Gonzih joined #nim |
| 08:32:40 | * | pregressive joined #nim |
| 08:33:52 | * | pregress_ joined #nim |
| 08:33:53 | * | pregressive quit (Read error: Connection reset by peer) |
| 08:37:16 | nsf | is there a reason why channels don't use deepCopy? is it because they were written before deepCopy? |
| 08:38:52 | * | pregress_ quit (Ping timeout: 276 seconds) |
| 08:40:05 | nsf | or is it because they pack things into a manually managed memory chunk first? |
| 08:40:14 | nsf | just wondering what would it take to implement channels myself |
| 08:40:38 | nsf | or even simply get custom features running like passing coroutine result between threads via copy |
| 08:45:53 | nsf | or is the channel does a custom implementation of deepCopy because it has to copy everything into its internal buffer first and then unpack in a different thread? |
| 08:45:55 | nsf | hm |
| 08:46:50 | nsf | perhaps would be nice to have some sort of thread-safe boxing instead |
| 08:47:12 | * | yglukhov joined #nim |
| 08:47:20 | nsf | i.e. take tree of objects box them via deepCopy into a chunk of memory |
| 08:47:27 | nsf | then you can pass it around and unbox at some point |
| 08:47:33 | nsf | into GCed memory again |
| 08:48:11 | nsf | on top of that primitive you would be able to implement all sorts of message passing that suits your needs I guess |
| 08:53:25 | * | yglukhov quit (Remote host closed the connection) |
| 09:06:16 | Araq_ | ldlework: it's a finalizer. there is no guarantee it will run when the thing goes out of scope |
| 09:06:31 | Araq_ | a finalizer is not a destructor. |
| 09:06:49 | ldlework | Araq_: right its a garbage collector event |
| 09:07:26 | ldlework | is 'pointer' a keyword? |
| 09:07:41 | Araq_ | nsf: channels indeed predate deepCopy, but I don't know if they can use deepCopy, I would need to dig into its internals just like you |
| 09:08:37 | Araq_ | ldlework: no it's in system.nim |
| 09:08:42 | nsf | Araq_: I see |
| 09:10:00 | ldlework | Araq_: with regards to SDL2 texture cdata, do you recommend deconstructors or finalizers? |
| 09:10:20 | ldlework | Or should I just track all my loaded assets and just loop through them and "destroy" them when the application is exiting? |
| 09:10:48 | ldlework | I've been taking the later approach until I understand a better Nim approach |
| 09:11:41 | ldlework | like if I write finalizers will they all be called when my program terminates? |
| 09:11:53 | ldlework | do I even care about resource clean up on program exit? |
| 09:17:54 | nsf | ldlework: if you target PC and making a 2d game, maybe not |
| 09:18:01 | Araq_ | bbl |
| 09:18:04 | nsf | just load everything into memory |
| 09:18:10 | nsf | plenty of memory on PCs :) |
| 09:22:07 | ldlework | Araq_: when I want to pass a ptr to a Rect tuple I just created, do I just pass r.addr ? |
| 09:34:16 | * | desophos quit (Read error: Connection reset by peer) |
| 09:34:41 | * | vendethiel joined #nim |
| 09:40:04 | ldlework | I dislike that you have to specify member names for structural types |
| 09:40:09 | ldlework | it should just be the order.. |
| 09:41:37 | * | zepolen joined #nim |
| 09:44:15 | ldlework | how the hell do I instantiate a type that is defined as a tuple O_O |
| 09:45:18 | ldlework | Araq_: how do I instantiate an SDL2 Rect? |
| 09:46:52 | ldlework | idgi |
| 09:47:05 | ldlework | object constructor requires object type |
| 09:47:07 | ldlework | ?! |
| 09:50:06 | ldlework | I'm totally clueless... |
| 09:51:42 | ldlework | type Rect* = tuple[x, y: cint, w, h: cint] |
| 09:51:49 | ldlework | how do I instantiate this, #nim ? |
| 09:52:27 | ldlework | man lojban has better support than Nim lol |
| 09:55:13 | ldlework | var dst: Rect |
| 09:55:15 | ldlework | dst.x = cint x |
| 09:55:17 | ldlework | dst.y = cint y |
| 09:55:19 | ldlework | dst.w = cint texture.width |
| 09:55:21 | ldlework | dst.h = cint texture.height |
| 09:55:23 | ldlework | ?! |
| 09:55:32 | ldlework | really? |
| 09:57:36 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 10:00:01 | dom96 | Maybe you need to read the Nim tutorial? :P |
| 10:00:14 | dom96 | (x, y, texture.width, texture.height) |
| 10:00:19 | dom96 | Same as in Python |
| 10:00:25 | dom96 | ldlework: |
| 10:00:39 | ldlework | that doesn't work |
| 10:01:01 | ldlework | dom96: I assume you mean "let r: Rect = ..." |
| 10:02:06 | dom96 | you likely also need to convert to cint |
| 10:02:20 | dom96 | so: (x.cint, y.cint, texture.width.cint, texture.height.cint) |
| 10:02:23 | dom96 | and yeah, it sucks |
| 10:03:26 | ldlework | Rect(...) would be nice |
| 10:03:57 | ldlework | dom96: Now that I have created this tuple, how do I send a ptr to it over to sdl2? addr doesn't seem to work on it |
| 10:04:28 | ldlework | expression has no address |
| 10:04:43 | ldlework | is it because I need to allocate the Rect on the heap as an untraced reference? |
| 10:05:18 | dom96 | it's because you're using 'let' |
| 10:05:22 | dom96 | use 'var' |
| 10:05:42 | ldlework | dom96: does var imply the heap? |
| 10:05:52 | dom96 | var implies mutable |
| 10:05:55 | * | vendethiel joined #nim |
| 10:06:06 | dom96 | nothing to do with heap vs stack AFAIK] |
| 10:06:09 | ldlework | hmm |
| 10:06:30 | ldlework | It seems strange to send a pointer to the stack over to some cffi interface |
| 10:06:33 | dom96 | is Rect actually defined like that in sdl2? |
| 10:06:43 | ldlework | dom96: its defined as a tuple in Araq_'s wrapper |
| 10:06:54 | ldlework | but he also has procs where I need to send a ptr of that type |
| 10:07:16 | ldlework | that worked though |
| 10:10:26 | dom96 | cool. Ideally there would be a module which exposes a nice idiomatic Nim API. I guess you're stuck dealing with the C ffi directly for now though. |
| 10:20:32 | ldlework | It seems like... Araq_ has a function defined to return a uint32 |
| 10:20:42 | ldlework | But its supposed to return a `ptr PixelFormat` |
| 10:20:49 | ldlework | And Nim wont let me cast it |
| 10:20:55 | ldlework | Am I out of luck? |
| 10:21:09 | dom96 | Have you tried cast[ptr PixelFormat](foo)? |
| 10:21:19 | dom96 | which function is it? |
| 10:21:54 | ldlework | dom96: getPixelFormat |
| 10:22:05 | federico3 | https://news.ycombinator.com/item?id=10869694 lot of talk about Nim here |
| 10:22:39 | * | dom96 just commented :) |
| 10:22:53 | ldlework | dom96: that worked |
| 10:23:00 | dom96 | I wouldn't say there is "a lot of talk" though. |
| 10:23:25 | federico3 | well, compared to the average |
| 10:24:00 | dom96 | ldlework: Looks like the wrapper is correct: https://wiki.libsdl.org/SDL_GetWindowPixelFormat |
| 10:24:12 | dom96 | but perhaps the type could be made stronger |
| 10:26:48 | ldlework | ooc looks nice |
| 10:27:14 | ldlework | the generics look ok |
| 10:29:45 | * | BitPuffin|osx joined #nim |
| 10:29:47 | dom96 | I don't think it's as actively developed as Nim is now. |
| 10:43:05 | ldlework | i wasn't comparing it |
| 10:51:27 | * | yglukhov joined #nim |
| 11:19:12 | * | yglukhov quit (Remote host closed the connection) |
| 11:22:10 | * | Demon_Fox quit (Quit: Leaving) |
| 11:24:30 | ldlework | Araq_: you around? |
| 11:24:48 | ldlework | How the heck are you supposed to get concrete Event types out of SDL2? |
| 11:25:25 | ldlework | Araq_: I tried to cast[WindowEventObj](event) I get back from pollEvent() but no luck |
| 11:25:56 | ldlework | (After checking its .kind of course) |
| 11:26:17 | ldlework | so many hangups today |
| 11:27:31 | dom96 | Why doesn't that work? |
| 11:29:20 | ldlework | no idea |
| 11:29:28 | ldlework | says it can't be cast |
| 11:30:23 | ldlework | oh huh |
| 11:30:28 | ldlework | I just access .window on the structure |
| 11:30:31 | ldlework | and magic |
| 11:30:37 | ldlework | something something unions? |
| 11:52:17 | * | irrequietus joined #nim |
| 12:08:54 | * | vqrs quit (Ping timeout: 245 seconds) |
| 12:12:30 | * | vqrs joined #nim |
| 12:28:00 | * | gokr quit (Quit: Leaving.) |
| 12:39:50 | * | jaco60 joined #nim |
| 12:56:53 | * | thotypous quit (Quit: WeeChat 1.3) |
| 12:57:12 | * | thotypous joined #nim |
| 12:59:37 | dom96 | Some more Nim discussion here https://news.ycombinator.com/item?id=10870488 |
| 13:09:15 | * | BitPuffin|osx quit (Ping timeout: 240 seconds) |
| 13:30:14 | nsf | I'm not sure whether I like nim or not, lots of positive sides: macros, generics with "static if" aka "when", nice syntax |
| 13:30:36 | nsf | but the memory management bothers me |
| 13:30:42 | nsf | works great on a single thread |
| 13:33:04 | nsf | and on multiple threads you essentially get processes and sockets |
| 13:33:32 | nsf | multiple GCs, who's gonna win, unclear |
| 13:56:05 | * | xet7 quit (Ping timeout: 276 seconds) |
| 14:01:10 | dom96 | nsf: pretty sure shared memory is planned in some shape or form |
| 14:02:56 | nsf | well in the mean time I'll keep doing what I'm doing with boehmgc |
| 14:03:05 | nsf | it's not like I have choice anyway |
| 14:03:13 | nsf | my alternatives are F# and C++17 :) |
| 14:03:49 | nsf | with F# I have to deal with all the .NET quirks, C++17 isn't there yet and it is manual memory management there |
| 14:04:25 | nsf | although if we compare it to nim, maybe in manual memory management area it's slightly better in a sense of well established rules, ctors/dtors, copy/move semantics and all that |
| 14:04:58 | nsf | but I don't think it's very helpful as I need to model many-to-one relationships across different threads |
| 14:09:47 | * | SirCmpwn quit (Remote host closed the connection) |
| 14:12:01 | * | SirCmpwn joined #nim |
| 14:13:11 | * | xet7 joined #nim |
| 14:39:27 | * | zepolen quit (Remote host closed the connection) |
| 14:58:11 | * | pregressive joined #nim |
| 15:02:39 | * | pregressive quit (Ping timeout: 245 seconds) |
| 15:30:39 | * | exebook_ quit (Remote host closed the connection) |
| 15:33:14 | * | yglukhov joined #nim |
| 15:40:19 | * | yglukhov quit (Remote host closed the connection) |
| 15:43:41 | * | yglukhov joined #nim |
| 15:53:57 | * | zepolen joined #nim |
| 16:01:15 | * | yglukhov quit (Remote host closed the connection) |
| 16:13:42 | * | yglukhov joined #nim |
| 16:17:08 | * | yglukhov quit (Remote host closed the connection) |
| 16:30:34 | * | zepolen quit (Remote host closed the connection) |
| 16:34:04 | * | exebook joined #nim |
| 16:35:08 | * | zepolen joined #nim |
| 17:15:30 | * | exebook quit (Remote host closed the connection) |
| 17:18:27 | * | zepolen quit (Remote host closed the connection) |
| 17:20:00 | * | zepolen joined #nim |
| 17:23:07 | * | mal`` quit (Ping timeout: 244 seconds) |
| 17:26:19 | * | gokr joined #nim |
| 17:31:57 | * | mal`` joined #nim |
| 17:40:29 | * | pregressive joined #nim |
| 17:44:32 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 18:02:46 | * | vendethiel joined #nim |
| 18:05:10 | * | Jesin quit (Quit: Leaving) |
| 18:36:58 | * | Jesin joined #nim |
| 19:00:32 | * | desophos joined #nim |
| 19:07:25 | * | vendethiel quit (Ping timeout: 276 seconds) |
| 19:18:14 | * | pregressive quit (Remote host closed the connection) |
| 19:18:47 | * | pregressive joined #nim |
| 19:23:40 | * | pregressive quit (Ping timeout: 276 seconds) |
| 19:41:18 | * | darkf quit (Quit: Leaving) |
| 19:52:24 | * | HakanD joined #nim |
| 19:56:31 | * | Trustable joined #nim |
| 20:19:50 | niv | hello. is it possible to extend a enum? i'd like to patch the logging to have a "notice" level (for better syslog support) |
| 20:19:56 | niv | .. the logging module .. |
| 20:27:24 | * | vendethiel joined #nim |
| 20:33:16 | dom96 | niv: not without editing the definition directly |
| 20:33:29 | niv | understood |
| 20:45:22 | * | Jesin quit (Quit: Leaving) |
| 20:46:40 | * | perturbation joined #nim |
| 20:48:00 | niv | dom96: do you think it might be good idea to make logging syslog compatible? it'd just involve adding a bunch more logging levels and their respective templates. |
| 20:48:14 | niv | then we could just add a newSyslogLogger() proc that would log to syslog |
| 20:48:19 | onionhammer | i <3 F# |
| 20:48:31 | * | vendethiel quit (Ping timeout: 260 seconds) |
| 20:48:56 | dom96 | niv: I'm not sure. I'm not familiar with syslog. |
| 20:49:29 | niv | http://pubs.opengroup.org/onlinepubs/7908799/xsh/syslog.h.html check at the bottom. thats the levels we'd need so we can make a 1:1 mapping of events |
| 20:49:53 | niv | most are there anyways, what's missing the most is "notice" |
| 20:51:59 | dom96 | Do we need to support all of them*? |
| 20:52:33 | niv | if you want to keep to the spec yes. im just asking because im missing "notice" myself when adding logging to a program. |
| 20:52:48 | niv | emerg/alert isnt that important unless you're writing system services |
| 20:53:07 | niv | notice is something that you usually want to know about; info is for passive logging |
| 20:55:18 | * | Demon_Fox joined #nim |
| 20:56:23 | dom96 | niv: Please make an issue on Github so that everyone can discuss it. |
| 20:56:33 | niv | got it |
| 20:58:32 | dom96 | thanks |
| 21:04:59 | * | perturbation quit (Remote host closed the connection) |
| 21:06:46 | niv | dom96: https://github.com/nim-lang/Nim/issues/3701 |
| 21:14:07 | * | perturbation joined #nim |
| 21:24:11 | * | mat4 joined #nim |
| 21:24:14 | mat4 | hello |
| 21:24:24 | ldlework | hi mat4 |
| 21:36:08 | * | vendethiel joined #nim |
| 21:40:21 | mat4 | hi ldlework |
| 21:40:49 | ldlework | mat4: what up? |
| 21:41:47 | mat4 | not much, working on some low-level stuff |
| 21:42:27 | ldlework | mat4: like what |
| 21:43:25 | mat4 | processor design, code formats and instruction bundling |
| 21:44:02 | ldlework | mat4: that sounds intense |
| 21:44:06 | mat4 | it is |
| 21:44:20 | ldlework | mat4: can I ask what you do? I forget everyone around here every couple of months :( |
| 21:47:06 | mat4 | dynamic native-code compiler and environment (for which a new Nim backend is needed to be usable at current) |
| 21:47:44 | mat4 | however I can't spend much free time on it at current |
| 21:56:44 | * | perturba_ joined #nim |
| 21:56:44 | * | perturbation quit (Read error: Connection reset by peer) |
| 21:58:34 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 22:02:13 | * | perturba_ is now known as perturbation |
| 22:05:56 | * | perturbation quit (Remote host closed the connection) |
| 22:12:56 | * | HakanD quit (Quit: Be back later ...) |
| 22:28:27 | * | mat4 quit (Quit: Verlassend) |
| 22:43:11 | * | Demon_Fox quit (Ping timeout: 255 seconds) |
| 22:44:29 | * | zepolen quit (Remote host closed the connection) |
| 22:44:56 | * | Demon_Fox joined #nim |
| 22:49:42 | * | kas_ joined #nim |
| 23:16:08 | * | cyraxjoe_ joined #nim |
| 23:16:32 | * | irrequietus quit () |
| 23:17:41 | * | cyraxjoe quit (Ping timeout: 246 seconds) |
| 23:21:40 | * | vendethiel joined #nim |
| 23:33:35 | ldlework | What is the opposite of a reference type called? |
| 23:37:33 | dom96 | value type |
| 23:39:33 | ldlework | nice |
| 23:39:43 | ldlework | dom96: I pushed some new code to dadren |
| 23:40:16 | ldlework | We now have a texture abstraction, a resource manager, and a texture atlas abstraction |
| 23:40:22 | ldlework | also content scaling |
| 23:40:48 | ldlework | I'm working on a Tilemap abstraction over the Atlas, then I'll make a Tileset abstraction over Tilemaps |
| 23:42:15 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 23:44:58 | * | kas_ quit (Ping timeout: 276 seconds) |
| 23:45:42 | dom96 | ldlework: awesome! Did you make those tilesets? |
| 23:45:52 | ldlework | dom96: no they are from Cataclysm |
| 23:45:58 | ldlework | I made a couple of the tiles |
| 23:46:12 | ldlework | But the tilesets have an open license so |
| 23:46:22 | dom96 | I see. What are your plans in regard to art btw? |
| 23:46:36 | dom96 | ahh. So you'll just use Cataclysm's? |
| 23:46:38 | ldlework | dom96: use retrodays20 + customizations as needed |
| 23:46:54 | ldlework | yeah. the engine supports custom tilesets so other people can make new ones |
| 23:47:03 | ldlework | or we can steal other tilesets from cataclysm etc |
| 23:47:08 | dom96 | I always found art to be the biggest obstacle when creating games :) |
| 23:47:18 | ldlework | dom96: hence tilebased roguelike :) |
| 23:47:38 | ldlework | retro tiles at that |
| 23:47:50 | ldlework | this is turning out to be so fun |
| 23:48:04 | ldlework | I hope I don't run into some fucked limitation when I get to implementing the actual entity component system |
| 23:48:17 | dom96 | I'm glad to hear that. |
| 23:48:38 | dom96 | Your code is beautiful. |
| 23:48:46 | ldlework | wow, thanks |
| 23:49:19 | ldlework | dom96: which file inspired you to say that |
| 23:49:53 | dom96 | all of it really, but was looking at application.nim at the time |
| 23:50:03 | * | vendethiel joined #nim |
| 23:50:35 | ldlework | dom96: I like how this application abstraction doesnt know anything about your gamestate, or how you handle drawing or event handling. |
| 23:50:58 | ldlework | if you look at dadren.nim |
| 23:51:00 | ldlework | the last line |
| 23:51:14 | ldlework | I'm getting better at avoiding inheritance |
| 23:51:24 | ldlework | but I wonder what would happen if someone wanted to extend application to do something unique |
| 23:51:40 | ldlework | In python they would just subclass and override some stuff |
| 23:51:53 | ldlework | But I can't think about that kind of stuff. This is an ENGINE!!!! |
| 23:52:02 | ldlework | You feed it data, not code >: |
| 23:52:45 | ldlework | Everytime I get hung up in trying to offer nice base-class library type stuff in static languages I always run into strange limitations in the type systems of the languages I use |
| 23:53:03 | dom96 | I'm glad you're not using inheritance, it always feels dirty in Nim for me. |
| 23:53:19 | ldlework | dom96: but how would someone extend App to say, handle the main loop differently? |
| 23:53:29 | ldlework | like how would you go about extending run()? |
| 23:53:54 | dom96 | question is in what situation would you want to extend run() |
| 23:53:56 | ldlework | Adding new attributes to AppObj or AppSettings |
| 23:54:13 | ldlework | dom96: well if I was writing a game-library instead of a data-only engine |
| 23:54:24 | ldlework | and I was offering this application functionality as game-loop boilerplate |
| 23:54:31 | ldlework | how would they extend what I offer? |
| 23:54:46 | ldlework | I think in that case it is the wrong contract |
| 23:54:56 | dom96 | Good question, and one which I cannot answer. |
| 23:55:00 | ldlework | Here App says, "Give me what I need, and call me and I'll take it from there." |
| 23:55:07 | ldlework | Wherein, in a library situation |
| 23:55:11 | dom96 | Araq_ should be able to though ;) |
| 23:55:29 | ldlework | You would have to provide smaller components, that allow the app writer to easily build their own loop... |
| 23:55:39 | ldlework | Or maybe the answer is that the user just writes their own run()... |
| 23:55:54 | ldlework | and uses the data types and other procs |
| 23:55:57 | ldlework | maybe thats it.. |
| 23:56:00 | ldlework | KISS |
| 23:56:14 | ldlework | If run was longer though |
| 23:56:18 | dom96 | that sounds good. |
| 23:56:22 | ldlework | and you wanted to say, override one of the functions it calls.. |
| 23:56:27 | dom96 | How would this be done in non-OO languages? |
| 23:56:37 | ldlework | dom96: just subclass App, and override methods. |
| 23:56:43 | ldlework | then instantiate the subclass |
| 23:56:46 | ldlework | then when you call run |
| 23:56:55 | ldlework | if you've overriden some function that run calls |
| 23:56:58 | ldlework | you've changed run's behavior |
| 23:57:00 | dom96 | is inheritance not an OO feature? |
| 23:57:07 | ldlework | oh sorry |
| 23:57:12 | ldlework | I thought you said "in an OO-language" |
| 23:57:31 | ldlework | I have no idea how you do it |
| 23:57:40 | ldlework | other than reimplementing run |
| 23:57:47 | ldlework | to change one line |
| 23:57:53 | ldlework | to call a different version of some proc dependency |
| 23:58:11 | ldlework | in the engine situation |
| 23:58:20 | ldlework | you can only pass in the things you can change |
| 23:58:29 | ldlework | like the two procs that handle frame drawing and event handling |
| 23:58:44 | ldlework | and the state structure that will be blindly handed to those handlers |
| 23:58:53 | ldlework | but everything else is set in stone |
| 23:59:52 | dom96 | Might be something worth looking into. Time to step out of the comfort zone of OO ;) |
| 23:59:54 | ldlework | dom96: thanks for the compliment |