On Sun, Jun 3, 2012 at 3:49 AM, Cédric Beust ♔ <[email protected]> wrote: > On Sun, Jun 3, 2012 at 12:30 AM, Casper Bang <[email protected]> wrote: >>> >>> As for type safety, I would argue that Android's API's are "more" type >>> safe than usual in the sense that they make resource look ups type safe (if >>> a resource gets removed or renamed, your code won't compile until you adjust >>> it). >> >> >> The R thing is... special, and only doable because of how Android extends >> the tool-chain with source-code generation. What bugs me the most is all the >> casting when accessing elements of a layout. Although the runtime penalty is >> probably neglectable, it's inherently typeless at compile-time to the >> author. Android's remedy here again is in tooling, but it still reeks of a >> type-system mismatch between XML and Java, and makes it hard to pick up >> other development tools which are not "hardwired" for this ad-hoc way the >> Android SDK does things. > > > Yup. Note that theoretically, you could get rid of these casts by generating > smarter code, but it seems to me that it might not be worth it (in my > experience, class cast exceptions hardly ever happen during that look up).
Wouldn't have to be that much smarter. Make the keys something generic on what you are looking up, and you can basically use the "hetereogeneous container pattern", right? Question then is simply if there is a major penalty for doing this instead of just using primitives. And, I should say I agree with you. Not sure this is worth it. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
