--- Log opened Tue Jun 04 00:00:31 2013 |
00:19 | < RichyB> | Ugh, don't work with Zope if you can avoid it. |
00:21 | < RichyB> | The central, mostly strongly recommended mechanism for making things like search features that don't vomit and die on O(n) entire-DB walks is a bundle of modules and eggs called ZCatalog. |
00:22 | < RichyB> | ZCatalog is kind of nice in a Zope-centric system... but it contains code that swallows exceptions without aborting the current transaction. |
00:23 | < RichyB> | Bleh. If you have random or transient failures inside code that ZCatalog touches then you can get the damn thing to write incorrect information into your database. :| |
00:23 | < RichyB> | "Transient failures" can include "/tmp was full for a few seconds." :( |
00:34 | < RichyB> | All y'all are reading the Codeless Code, right? http://thecodelesscode.com/case/96 |
00:36 | <~Vornicus> | ahaha, that's a good one |
00:37 | <@gnolam> | Heh |
00:37 | | Turaiel[Offline] is now known as Turaiel |
00:55 | <@froztbyte> | RichyB: nice |
01:09 | | * Vornicus goes to see Vash off to work, et al |
01:10 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
01:22 | | Derakon [Derakon@31356A.8FA1FE.CF2CE9.D6CF77] has quit [Ping timeout: 121 seconds] |
01:23 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
01:23 | | mode/#code [+ao Derakon Derakon] by ChanServ |
01:32 | | himi [fow035@D741F1.243F35.CADC30.81D435] has joined #code |
01:32 | | mode/#code [+o himi] by ChanServ |
01:35 | | Harlow [Harlow@Nightstar-a784d8b0.hfc.comcastbusiness.net] has joined #code |
02:01 | | Harlow [Harlow@Nightstar-a784d8b0.hfc.comcastbusiness.net] has left #code ["Leaving"] |
02:30 | | Turaiel is now known as Turaiel[Offline] |
02:54 | | RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has quit [[NS] Quit: Gone.] |
02:56 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
02:58 | | RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has joined #code |
03:11 | <@Alek> | can someone explain that koan to me? |
03:12 | <@Tamber> | Mu. |
03:12 | | * Alek smacks Tamber with a cow. |
03:12 | <@Tamber> | What's your beef, man? ;) |
03:13 | <&ToxicFrog|W`rkn> | Alek: stateless services, as the name implies, do not preserve any state between requests. They forget everything as soon as the current request is completed. |
03:13 | | ToxicFrog|W`rkn is now known as ToxicFrog |
03:13 | <&McMartin> | And for the first part, "Ten thousand guests fed from a single grain of rice" - a stateless protocol does not need to track anything per-user, so the number of users does not[*] increase the server load. |
03:14 | <&McMartin> | To extend the metaphor, the ten thousand guests need somewhere to sit, but in a stateful protocol the chef also needs to know all their names. |
03:14 | <&ToxicFrog> | And preferred dishes and dietary restrictions. |
03:14 | <&McMartin> | That one is really less "koan" and more "teaching-riddle" |
03:17 | <&ToxicFrog> | Also http://xkcd.com/869/ |
03:17 | <@Alek> | a |
03:17 | | * Alek is enlightened. |
03:24 | <&McMartin> | Also, I'm kind of behind on my codeless code |
03:24 | <&McMartin> | http://thecodelesscode.com/case/93 is pretty great |
03:32 | | * Alek eyes Java. |
03:33 | <@Alek> | so, a class. two sub-classes. and another sub-class whose objects must also belong to both of the other sub-classes. |
03:34 | <&ToxicFrog> | :enterprise: |
03:34 | <&McMartin> | Java explicitly forbids this thing. |
03:34 | | Vorntastic [Vorn@A2BA3E.078E56.87954D.35CEB0] has joined #code |
03:35 | <&McMartin> | That is in part because the problem has no actual correct general solution. |
03:35 | <&McMartin> | Your class and its two median subclasses must one or both be purely abstract, and declared as interfaces instead of classes. Furthermore, these subclasses must not share any method names. |
03:35 | <&McMartin> | There is a trivial syntactic way to not require that last thing, but Java does not do it. (C# does.) |
03:36 | <@Reiv> | What is this thing? |
03:36 | <&McMartin> | Multiple inheritance. |
03:37 | <&McMartin> | Let's call the "a class" there A, the two subclasses B and C and final subclass D. |
03:37 | <&McMartin> | You want B and C to extend A and you want D to extend both B and C and be castable to either. |
03:37 | < Vorntastic> | Hooray, diamond inheritance |
03:38 | <&McMartin> | The decision to make is whether or not to do diamond inheritance or not. |
03:38 | <&McMartin> | You may either say "the implementation of the B parts have their own inner A that they extend, and the C does similarly" |
03:38 | <&McMartin> | Or you may say "Because of this shared inheritance, B and C are both modifying the same underlying A that underlies the D itself" |
03:39 | <&McMartin> | Neither of these answers is in itself sufficient. |
03:39 | <&McMartin> | Java cuts this knot by demanding at the syntactic level that in such circumstances only one line of descent actually carry any state. |
03:40 | <&McMartin> | Because inheritance does not in fact add raw power to a language - there is nothing inheritance in a language gives you that you cannot fake with structures and function pointers - one can get the ultimate result with some level of manual intervention regardless. |
03:40 | <&McMartin> | "Views" are one way - let D have methods that return B and C objects that reference the D appropriately |
03:40 | <&McMartin> | But now every time you use this you must perform a cast. |
03:41 | < Vorntastic> | I can't remember the last time I inherited from an object. |
03:41 | <&McMartin> | Composition is the other; let the D have two inner fields that are a B and a C and forward the method calls to them as needed. |
03:41 | < Vorntastic> | Er, yeah, brain missing |
03:41 | <&McMartin> | Views get you the "single shared A" semantics, composition gets you the "each superclass its own internal parent" semantics. |
03:42 | <&McMartin> | When languages must choose, they appear to invariably select the one that involves behaving like composition. |
03:42 | <&McMartin> | That is because it is the one that lets B and C maintain internal invariants without having to know about one another. =P |
03:43 | < Vorntastic> | Reminds me I have a c++ problem. |
03:43 | <&McMartin> | On this very problem, mind you: http://thecodelesscode.com/case/83 |
03:44 | < Vorntastic> | I have factory function that i wish to use as an initializer. |
03:44 | | Kindamoody[zZz] is now known as Kindamoody |
03:47 | < Vorntastic> | I know that I'm supposed to avoid Foo a = Foo() but this is a factory function. |
03:47 | < Vorntastic> | So Foo a() doesn't do it. |
03:48 | <&McMartin> | You cannot do this |
03:48 | <&McMartin> | This is literally why factory functions exist; to work around the inferiority of OO languages in that constructors may not be virtual |
03:48 | <&McMartin> | If your Foo() function always returns a Foo and just a Foo, never a subclass, then you could pass in a function pointer as an argument to Foo's constructor. |
03:50 | < Vorntastic> | I guess I misnamed it as factory |
03:50 | <&McMartin> | Foo a(delegate) should be fine, modulo C++'s absurd function pointer syntax |
03:51 | <@Reiv> | Foo a = Foo() is bad? |
03:52 | < Vorntastic> | It does construct and return a foo but I can't add more constructors to foo anyway (it's a typedef of builtin) and it's also a method on a different object. |
03:52 | <&McMartin> | It's semantically equivalent to "Foo a;" |
03:52 | <@Reiv> | This is not Java, is it |
03:52 | <&McMartin> | No, it is C++ |
03:52 | < Vorntastic> | With arguments it's somewhat different. |
03:52 | <@Reiv> | Ho, yez. |
03:53 | < Vorntastic> | But with the = you get it running a spurious copy constructor et al |
03:53 | <&McMartin> | Right |
03:53 | < Vorntastic> | So usually you actually do Foo a(); |
03:54 | <&McMartin> | In that case I don't see a way around this beyond using pointers instead |
03:56 | < Vorntastic> | In my case though I have a function that returns a Foo and I want it to init to that, and I'm stuck. |
04:02 | | Vornlicious [Vorn@Nightstar-ff8fe4e3.sub-70-211-4.myvzw.com] has joined #code |
04:02 | < Vornlicious> | Don't think vector<Bar*> is too dire there though. |
04:04 | | Vorntastic [Vorn@A2BA3E.078E56.87954D.35CEB0] has quit [Ping timeout: 121 seconds] |
04:09 | | Turaiel[Offline] is now known as Turaiel |
04:39 | | Vorntastic [Vorn@Nightstar-221158c7.sd.cox.net] has joined #code |
04:39 | | Vorntastic [Vorn@Nightstar-221158c7.sd.cox.net] has quit [Client closed the connection] |
04:40 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
04:40 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
04:42 | | Vornlicious [Vorn@Nightstar-ff8fe4e3.sub-70-211-4.myvzw.com] has quit [Ping timeout: 121 seconds] |
04:45 | < Turaiel> | Syloq, what time zone? |
04:53 | | Kindamoody is now known as Kindamoody|afk |
--- Log closed Tue Jun 04 05:03:56 2013 |
--- Log opened Tue Jun 04 05:04:00 2013 |
05:04 | | TheWatcher[zZzZ] [chris@Nightstar-3762b576.co.uk] has joined #code |
05:04 | | Irssi: #code: Total of 38 nicks [17 ops, 0 halfops, 0 voices, 21 normal] |
05:04 | | mode/#code [+o TheWatcher[zZzZ]] by ChanServ |
05:04 | | Kindamoody|afk is now known as Kindamoody |
05:04 | | Irssi: Join to #code was synced in 35 secs |
05:16 | | Kindamoody is now known as Kindamoody|out |
06:43 | | Netsplit *.net <-> *.split quits: @gnolam, AverageJoe, @Reiv, @PinkFreud |
06:43 | | gnolam_ [lenin@Nightstar-b2aa51c5.cust.bredbandsbolaget.se] has joined #code |
06:43 | | Netsplit over, joins: AverageJoe |
06:43 | | gnolam_ is now known as gnolam |
06:55 | | himi [fow035@D741F1.243F35.CADC30.81D435] has quit [Ping timeout: 121 seconds] |
07:57 | | Turaiel is now known as Turaiel[Offline] |
08:19 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code |
08:22 | | gnolam is now known as NSGuest47577 |
08:32 | | NSGuest47577 is now known as gnolam |
08:32 | | mode/#code [+o gnolam] by ChanServ |
09:14 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
09:25 | | You're now known as TheWatcher |
10:56 | | AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has quit [[NS] Quit: Leaving] |
11:44 | < Xon> | <RichyB> ZCatalog is kind of nice in a Zope-centric system... but it contains code that swallows exceptions without aborting the current transaction. |
11:44 | < Xon> | holy crap that is evil |
11:51 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
11:51 | | mode/#code [+o himi] by ChanServ |
12:46 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
12:47 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
12:47 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
12:50 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
12:51 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
12:51 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
13:35 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
14:29 | | EvilDark1ord is now known as EvilDarkLord |
14:29 | | mode/#code [+o EvilDarkLord] by ChanServ |
14:43 | | * iospace kicks her code |
16:05 | | * Azash watches it catch on fire |
16:53 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has joined #code |
16:53 | | mode/#code [+o celticminstrel] by ChanServ |
16:56 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
16:56 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has joined #code |
16:56 | | mode/#code [+o celticminstrel] by ChanServ |
17:08 | | EvilDarkLord is now known as Maze |
17:47 | | Turaiel[Offline] is now known as Turaiel |
18:38 | | Turaiel is now known as Turaiel[Offline] |
19:25 | | * ToxicFrog successfully despiders the dependency graph |
19:53 | | Kindamoody|out is now known as Kindamoody |
20:31 | < [R]> | RE: not being able to compare NaN with NaN usefully. |
20:31 | < [R]> | > typeof NaN |
20:31 | < [R]> | "number" |
20:31 | | Kindamoody is now known as Kindamoody[zZz] |
20:31 | < [R]> | D: |
20:31 | < Syka> | what language is this in |
20:32 | < [R]> | JS |
20:32 | < Syka> | https://www.destroyallsoftware.com/talks/wat |
20:32 | < Syka> | related |
20:34 | <@gnolam> | [R]: http://thecodelesscode.com/case/90 |
20:37 | < [R]> | wat |
20:37 | < [R]> | Why am I being linked to the diary of an insane person? |
20:43 | <@TheWatcher> | ... not only is that extremely geeky, that's a godawful pun, I approve. |
20:43 | <&ToxicFrog> | If by "diary of an insane person" you mean "collection of amusing stories, most of them containing lessons about CS and software design", the answer is "because it is worth reading" |
20:43 | <&ToxicFrog> | And funny. |
20:44 | <@gnolam> | TheWatcher: the NaaN bread? :) |
20:44 | <@TheWatcher> | Yes. |
20:45 | < [R]> | The layout is midly confusing. |
20:45 | < [R]> | Half the story looks like it's not part of the story and then it switches to two other stories. |
20:48 | <@TheWatcher> | The structure is inspired by The Gateless Gate |
21:16 | <&ToxicFrog> | Most of the stories are simple linear narrative things; #90 is unusual. |
21:19 | <@TheWatcher> | I keep meaning to go through all of them, I've only read a handful. |
21:20 | <&ToxicFrog> | It doesn't take long, there's only 90-something and most of them are quite short |
21:31 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
21:39 | <&McMartin> | My favorite is still the brawl over class structure design |
21:40 | <&McMartin> | Also entertaining because I then look at that battle, and then duck-typed languages |
21:40 | <&McMartin> | And I hear the voice of the Datalinks in my head, quoting Sun-Tzu |
21:40 | <&McMartin> | ("The ideal military deployment approaches the formless") |
22:14 | <@froztbyte> | McMartin: did you ever see that freenode channel I mentioned to you in pm once? |
22:15 | <@froztbyte> | (I'm not sure how other people treat their IRC clients, but I know sometimes PMs go missing due to bouncers etc) |
22:17 | <&McMartin> | froztbyte: I've forgotten the incident if so |
22:36 | | Harlow [Harlow@Nightstar-a784d8b0.hfc.comcastbusiness.net] has joined #code |
22:38 | | Reiv [NSwebIRC@Nightstar-95746c1f.kinect.net.nz] has joined #code |
22:38 | | mode/#code [+o Reiv] by ChanServ |
22:45 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
22:45 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
22:51 | | Harlow [Harlow@Nightstar-a784d8b0.hfc.comcastbusiness.net] has quit [[NS] Quit: Leaving] |
22:52 | < AnnoDomini> | gnolam: Neato! |
22:58 | | Turaiel[Offline] is now known as Turaiel |
23:09 | <@Reiv> | This. So very this. http://thecodelesscode.com/case/83 |
23:10 | <@Reiv> | Is why I am interested by Entity Systems. |
23:11 | <@Reiv> | In fact that is almost precisely the use case that makes me want them~ |
23:12 | <&McMartin> | It's also why you shouldn't use Inheritance to do it~ |
23:13 | <&McMartin> | That is the most useful tale on the site, I think. |
23:13 | <&McMartin> | http://thecodelesscode.com/case/45 is my favorite one, though. |
23:13 | <@Reiv> | If not inheritance, then what /is/ the better way to do it, without screeds of repitition? |
23:13 | <&McMartin> | And not merely for the illustration |
23:14 | <@Reiv> | ha yes |
23:14 | <&McMartin> | Inheritance is not the sole form of code reuse |
23:14 | <&McMartin> | It's not even the *major* form of code reuse |
23:14 | <&McMartin> | The major form of code reuse is *function definitions* |
23:14 | <@Reiv> | OK |
23:15 | <&McMartin> | Inheritance is a way of recycling those declarations and of enforcing capability contracts on data structures, and sometimes (Python, Objective-C, Smalltalk, Ruby) not even the latter |
23:15 | <&McMartin> | Entity Systems are a way of grouping together functions that Do A Thing and applying them more freely to processing |
23:15 | <&McMartin> | But they're also AFAIK tied to a specific engine design |
23:16 | <&McMartin> | Otherwise you end up with "advice" systems, which are awesome until you have to use them |
23:16 | <&McMartin> | Since once you say "when you say 'call this function', actually call this other function first/after/instead", it becomes impossible to understand any piece of code anywhere in the system without looking at every line of code everywhere in the system. |
23:17 | <&McMartin> | This is occasionally sold as a feature ("You no longer have cross-cutting concerns!") but it totally is not. |
23:17 | <@celticminstrel> | #45 sounds like multiple inheritance, at least at first glance. |
23:18 | <@celticminstrel> | Uh, sorry, #83 |
23:18 | <&McMartin> | #83 is exactly the problem of stateful multiple inheritance. |
23:19 | <&McMartin> | And stateful multiple inheritance is problematic even outside of a programming context. |
23:19 | <&McMartin> | Imagine these elite horse archers, for instance. |
23:19 | <&McMartin> | We have postulated that they are horsemen and archers in every respect. |
23:19 | <&McMartin> | Where then, shall they be deployed whent he general says "array all my archers on yonder hill, and prepare all the horsemen to charge at them from the flank?" |
23:20 | <@celticminstrel> | Not sure if I get #45. |
23:20 | <&McMartin> | There are several things going on in #45 |
23:21 | <@celticminstrel> | A good point on the MI... |
23:21 | | * AnnoDomini looks at 83. This is actually sortakinda relevant to one of his project. |
23:21 | <&McMartin> | The highlights of #45 are: |
23:21 | <&McMartin> | - The line "In which instance variable did I hit you" |
23:22 | <&McMartin> | - The closing line on the Invisible Hierarchy, which is twee but pretty fair |
23:22 | <@celticminstrel> | twee? |
23:22 | <&McMartin> | The topic of the fight of the students is philsophy of design |
23:22 | < AnnoDomini> | And my solution would be: "unsigned int flags" in the struct of Soldier, and #define SOLDIER_FLAG_ARCHER 1, #define SOLDIER_FLAG_HORSEMAN 2, etc. |
23:23 | <&McMartin> | "Overly quaint, dainty, cute or nice." |
23:23 | <&McMartin> | The fight is whether class structure should reflect the structure of the computation or the structure of the thing being simulated |
23:24 | <&McMartin> | AnnoDomini: That actually fails to solve the stated problem, but the stated problem is bad in the way I noted |
23:24 | <@Reiv> | ... it is? |
23:24 | <&McMartin> | Your system can be realized in inheritance systems with careful class design or with abstract interfaces, at which point the "in all ways" |
23:24 | <@Reiv> | I mean, it's a pretty /common/ problem. |
23:25 | < AnnoDomini> | I'm not sure I understand. |
23:25 | <&McMartin> | The stated problem says that a Horse Archer is an Archer *in all ways* |
23:25 | <&McMartin> | Status flags don't enforce that |
23:25 | < AnnoDomini> | So? |
23:25 | < AnnoDomini> | Right. |
23:26 | <&McMartin> | It's entirely possible to define a Soldier struct that has ARCHER set but does not use space for arrows. |
23:26 | <&McMartin> | It is not possible to define an Archer that doesn't. |
23:26 | <&McMartin> | And, indeed, if you were to write code that tried to execute my general's orders, you'd first deploy the horse archers to the hill and then move them off to the flank. |
23:27 | < AnnoDomini> | Right. |
23:28 | <&McMartin> | What your system does is permit Soldiers to be named with traits. |
23:28 | <&McMartin> | That's not really the part where the spiders live |
23:28 | <&McMartin> | The spiders live in the part where you are attaching functions to traits. |
23:28 | <~Vornicus> | On the other hand: Soldier has an attribute called archerness, which has an Archer object. NULL there means soldier isn't an archer; you ask him to tell you how many arrows, and he says "what are you talking about I'm not an archer" |
23:29 | <&McMartin> | And that's (close to) the views approach, yeah |
23:30 | <&McMartin> | And that sort of design also makes it more inconvenient to do grouping-by-type |
23:30 | <&McMartin> | Which is good, because that's a thing you don't want |
23:30 | <&McMartin> | Because of the general's issue |
23:30 | <&McMartin> | At a coding level, in C++, you hit a different problem |
23:30 | <&McMartin> | Soldiers have a number called their HP |
23:30 | <&McMartin> | Taking damage or being healed modifies it |
23:31 | <&McMartin> | If you inherit from Archer and Horseman in the usual way, this results in you having two HP counters, one specific to the Archer-self and one specific to the Horseman-self. |
23:31 | <&McMartin> | (To disable that behavior, one declares the inheritance "virtual") |
23:31 | <@Reiv> | So wait, the solution to making Soldier work is to give it IsAnArcher, IsAHorseman, and an arbitary number of extra objects as well? |
23:32 | <&McMartin> | *a* solution is to do that. |
23:32 | | * Reiv ponders. |
23:32 | < AnnoDomini> | Reiv: There are many solutions. |
23:32 | <&McMartin> | They don't have to be "real" extra objects. |
23:32 | <&McMartin> | One can imagine an asArcher() routine that gives you an Archer object for archery-related things, even if you are not, yourself, an archer. |
23:33 | < AnnoDomini> | Heck, I'm not even using classes or inheritance, just methods I have to patch when I detect that things go wrong. :P |
23:33 | <&McMartin> | (and then asArcher fails in some way if you feed it something that isn't one) |
23:33 | <@Reiv> | Surely better would be to have an IsSpecial, and then declare IsSpecial= new Archer(arrows), or Horseman, and then HorseArcher, which is an object which itself declares newArcher, newHorseman, an EmperorsCharge function, and some clever type code so that it can be registered as distinct from an archer proper, |
23:33 | <@Reiv> | Basically, a fork. |
23:34 | <@Reiv> | Well, not better. Let me rephrase: Would that work? |
23:34 | <&McMartin> | Solutions I personally would design indeed would not allow HorseArcher to be cast to Archer or Horseman. |
23:35 | <@Reiv> | It worries me because I can't see a good way to pass arbitary requests through to the child objects, though. |
23:35 | <&McMartin> | That's because you're working in C++ and not Python here. |
23:35 | <&McMartin> | In Python any method may be called legally on any object. |
23:35 | <&McMartin> | That's what a method call *is* |
23:36 | <&McMartin> | It's syntactically clearer in Objective-C, which has similar semantics but fails to quite reach them. |
23:36 | <&McMartin> | In those, instead of object.method(arg1, arg2) |
23:36 | <@Reiv> | Right, but... hn |
23:36 | <&McMartin> | It's [object method arg1 arg2] |
23:36 | <&McMartin> | More or less |
23:36 | <@Reiv> | I guess I can't see how it'd be coded. |
23:36 | <@Reiv> | This sort of problem always hurts my head. |
23:36 | <&McMartin> | Well, OK |
23:36 | <&McMartin> | Let's do this in C |
23:36 | <&McMartin> | let's also pretend that C has Python style dictionaries |
23:37 | <&McMartin> | Objects then are dictionaries. |
23:37 | <&McMartin> | Methods are functions within that dictionary. |
23:37 | <@Reiv> | And is kind of a big deal, because my Protogame Project has Spaceships (Which are in space, move, and fight), Stations (Which are in space, hold people, and fight), Planets (Which are rocks, and hold people), and Outposts (Which are rocks, and fight) |
23:38 | <&McMartin> | Right |
23:38 | <@Reiv> | ... isn't that then headed toward Entity Programming? |
23:38 | <&McMartin> | It can be, yeah |
23:38 | <&McMartin> | But Entity Programming is a super-high-level concept. |
23:38 | <&McMartin> | You're asking "how do you realize that in a general language" |
23:39 | <&McMartin> | And the most general way to do it is to have a generic Thing, a generic List of Things, and some kind of way of naming methods and properties |
23:39 | <@Reiv> | Hum. |
23:39 | <&McMartin> | And then your One Function is Thing DoAThing(object, nameofMethodorProperty, ListOfThingsThatAreArguments) |
23:39 | <@Reiv> | Remind me to try and learn Python, and learn enough to solve this problem. |
23:40 | <&McMartin> | (libobj is basically this) |
23:40 | <&McMartin> | Er |
23:40 | <&McMartin> | (libobjc) |
23:40 | <@Reiv> | I don't care if I end up with "Bricks, not houses" here. I'm just kinda wanting to solve the sucker enough to make my head hold it. |
23:40 | <&McMartin> | Except it's called objc_msgSend |
23:40 | <&McMartin> | Yeah |
23:40 | <&McMartin> | Python "pretends" to be function calls |
23:41 | <&McMartin> | You may be better off poking at Smalltalk or Objective-C, which explicitly replaces "Call this method on this object" with "Send this object this message" as its core form |
23:41 | <&McMartin> | I don't recommend *actually using* either one, but discussions of them might help you get into that headspace |
23:41 | <&McMartin> | Then the last step is "this is more or less how Python rolls even though it uses the C++/Java syntax" |
23:42 | <@Reiv> | I see. That could be wise. |
23:42 | <@Reiv> | Which of those two languages has the fewest spiders whilst hack-learning? |
23:42 | <~Vornicus> | Why don't planets get to fight? They're great spots to hide obscene numbers of missiles. |
23:43 | <@TheWatcher> | ^-- |
23:43 | <@Reiv> | Vornicus: That was actually the point I never got to write. |
23:44 | <@Reiv> | In that I don't /want/ to have each of these things written out in some longhanded way, because then "But now I want my planets to fight" becomes a pain in the ass, and so does "And now I want to have Worldships"... |
23:44 | <@TheWatcher> | Strap enough engine on, and hey~ |
23:46 | <@Reiv> | Right. |
23:47 | <@Reiv> | And I'd feel a right fool if I had to go to great lengths to marry Planet and Ship together to make it behave nicely. |
23:47 | <@Reiv> | Far better to have stuff which is fungible, even if you have to pause a moment and write special-case stuff at the intersections (eg, the Archer vs Horse HP bar thing) |
23:54 | | VirusJTG [VirusJTG@2B12AA.572255.206A2A.901581] has joined #code |
23:57 | <&McMartin> | Reiv: So, my area of Actual Expertise is the lower level |
23:58 | <&McMartin> | It's worth noting that in the general case, the Archer and the Horseman having separate HP bars is actually the "default" right answer |
23:58 | <&McMartin> | However, for game sims like this one it's almost always wrong |
23:59 | <&McMartin> | Anyway |
23:59 | <~Vornicus> | Entity Programming is something I've never really gotten around to understanding |
23:59 | <~Vornicus> | But I should learn it |
23:59 | <&McMartin> | Learn implies there are real answers |
23:59 | <&McMartin> | I can see a couple of ways to do it |
23:59 | <&McMartin> | One of them looks suspiciously like one of the classic Don't Do This You Fool techniques in Python |
23:59 | <&McMartin> | One looks like reimplementing COM >_< |
23:59 | <@Reiv> | McMartin: I suspect that via inheritance, the correct answer is "The soldier had it, so the others inhereted /that/ HP bar." Which is reasonable enough. |
--- Log closed Wed Jun 05 00:00:03 2013 |