code logs -> 2013 -> Tue, 04 Jun 2013< code.20130603.log - code.20130605.log >
--- 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
code logs -> 2013 -> Tue, 04 Jun 2013< code.20130603.log - code.20130605.log >

[ Latest log file ]