Hi,<br><br><div><span class="gmail_quote">2008/3/2, Jussi Kukkonen <<a href="mailto:jhkukkon@cc.hut.fi">jhkukkon@cc.hut.fi</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br>Using a dictionary for position data is somehow compelling, but I am<br> worried about the "heaviness" and somehow it feels conceptually wrong: a<br> Position is latitude/longitude (and possibly altitude) in WGS-84, not a<br> varying collection of values like Address... That said, it is an<br> interesting idea, one that I hadn't thought of.</blockquote><div><br> Let me expand on that, using your code example:<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">    pos.get_position (&time, &lat, &lon, &alt, &accuracy)</blockquote> <div><br> What alt receives here if the provider lacks altitude data? How to tell if it does?<br><br> Then, if we consider Python bindings, a straightforward binding would turn the above into:<br> (time, lat, lon, alt, accuracy) = pos.get_position()<br> </div><br> Not very convenient if you need only some of those values.<br> <br> I would prefer some kind of a compound value returned, which then could be mined for data as necessary. It'd also be better, perhaps, for dynamic language bindings. I can't see where data structure overhead would become a performance concern, until there's an API that calls for passing massive position lists. Maybe, separate types for 2D and 3D positions could be helpful too, if the freeform dictionary approach looks undesirable.<br><br>Best regards,<br>  Mikhail<br><br></div>