graydon has quit [Read error: 110 (Connection timed out)]
smkl has quit [Remote closed the connection]
smkl has joined #ocaml
Florent has joined #ocaml
Florent has quit [Read error: 104 (Connection reset by peer)]
awwaiid has quit [Read error: 110 (Connection timed out)]
engstad has joined #ocaml
<engstad>
Greets. I'm confused. I'm trying to make an octtree of objects, but I can't seem to find a way to store pointers to data polymorphicly.
<jemfinch>
and octtree?
<jemfinch>
type 'a octtree = Empty | Node of 'a * 'a * ' a * 'a * 'a * 'a * 'a * 'a
<jemfinch>
or, rather than use a tuple, you can use an 8 element array and enforce the invariant (that it has 8 elements) separately.
<engstad>
jemfinch still there?
<jemfinch>
yep, technically.
<engstad>
See, I have groups of different things, but they are all "mappable", meaning that they can be displayed on a map.
<jemfinch>
then you'll need to create a sum type for them.
<engstad>
I.e.: I have an array of 500 planets, 500 ships and so on.
<jemfinch>
type mappable = Planet of planet | Ship of ship | ...
<jemfinch>
and then you can use it with your octtree.
<engstad>
Hmmm.. I thought of that. But isn't the point of inherting that you don't have to do that?
<jemfinch>
do they all maintain exactly the same class interface?
<engstad>
No, only a subset of each. I.e.: there is a class positioned that encompasses the needed information in order to draw them.
<engstad>
I C++ I would use virtual functions for this.
<jemfinch>
for putting them into an octtree?
<engstad>
Yes.
* jemfinch
doesn't see how virtual functions would have anything to do with putting a class into a container.
<jemfinch>
but anyway...
<jemfinch>
your container, your octtree, if you decide to put classes in there, will "downcast" all the classes to the smallest interface, and when you get them out of the octtree, you'll lose whatever other public methods they provided.
<jemfinch>
so if you want to maintain those, you'll need to use a sum type like I mentioned.
<engstad>
You can't upcast them again?
<jemfinch>
no, you can't.
<jemfinch>
such wouldn't be safe.
<engstad>
I see...
<engstad>
I've heard that argument before. Why isn't it safe?
<jemfinch>
because you can't prove that a certain class had the interface to begin with.
<engstad>
Ok, here's my naive take on that..
<jemfinch>
that's why you use a sum type -- because then you keep track of what interface a class has, and can use all its features.
<jemfinch>
you *know* when you get a Ship or a Planet out, that you've got the whole interface available.
<engstad>
But, shouldn't that information be hidden in its type?
<jemfinch>
no, definitely not.
<engstad>
sorry, not type, but it's "magic".
<jemfinch>
one of the advantages of static typing is that you don't need to carry type information around at runtime.
<engstad>
An object needs to know what it really "is".
<jemfinch>
then use a sum type to give it that knowledge.
<engstad>
Now, I do see that that is good, but it is terribly awkward.
<jemfinch>
you can add the tags that would be there in a dynamically typed language if you want -- it's as easy as a sum type. But ML doesn't carry them around unless you tell it to.
<jemfinch>
it's not terribly awkward -- it's safer and more efficient.
<engstad>
;-)
<engstad>
It means that for every new type of "mappable" you create, you have to update the sum type, _and_ all of the functions where you use the sum type.
<jemfinch>
so?
<jemfinch>
such is the cost of provable safety.
<engstad>
That's what I mean with awkward. :-)
<jemfinch>
it's not awkward, really.
<jemfinch>
do it once or twice and you'll see.
<engstad>
I will.
<jemfinch>
it's very much an advantage that the compiler tells you every place that you need to update for your new sum type.
<engstad>
That is true.
<engstad>
Except for when you use the _ pattern, I guess.
<jemfinch>
um, if you use the _ pattern, you're not using the value, and there's nothing for the compiler to tell you.
<engstad>
I was thinking in terms of: match elem with Planet(p) -> do_planet p | Ship(p) -> do_ship p | _ -> ()
<jemfinch>
oh.
<jemfinch>
don't use that.
<engstad>
ok..
<jemfinch>
unless you truly don't want to do anything except with planets and ships -- in which case adding to your sum type shouldn't change that fact.
<engstad>
Good point.
<jemfinch>
as a note, I don't like using classes in O'Caml :)
<engstad>
jemfinch: why is that?
<engstad>
jemfinch: in my case, there's a lot of plain data for each object, and I'd hate to use records for it.
graydon has joined #ocaml
engstad has quit [Read error: 113 (No route to host)]
smkl has quit [carter.openprojects.net irc.openprojects.net]
jemfinch has quit [carter.openprojects.net irc.openprojects.net]
Taaus has quit [carter.openprojects.net irc.openprojects.net]