<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 11, 2017 at 11:08 AM Greg Clayton <<a href="mailto:clayborg@gmail.com">clayborg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Jan 11, 2017, at 10:36 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="gmail_msg" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="m_1005218309610047010Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">Would it make sense to push the value retrieval down into DWARFFormValue to separate getting the value from a DIE from getting the value into some particular type - they seem pretty orthogonal & it's odd that DWARFDie handles the type handling side of that rather than an attribute/form abstraction.<br class="gmail_msg"><br class="gmail_msg">Perhaps it'd be a bit abusive, but we could even overload op[](dwarf::Attribute) on DWARFDie for easy map-like attribute lookup. Maybe 'find' would be a better name, though.<br class="gmail_msg"><br class="gmail_msg">I'm OK omitting the 'attribute' part of the name entirely if everyone's OK with overloading in this context & if the callsites tend to be pretty self documenting. (mostly if you're searching for a particular attribute you've probably got the attribute name in a literal at the callsite anyway, right?)<br class="gmail_msg"><br class="gmail_msg">So code like this, perhaps:<br class="gmail_msg"><br class="gmail_msg">  x = Die.find(DW_AT_name).asString();<br class="gmail_msg"><br class="gmail_msg">or perhaps:<br class="gmail_msg"><br class="gmail_msg">  x = asString(Die.find(DW_AT_name));<br class="gmail_msg"><br class="gmail_msg">(so that find/findAttr/[] whatever we call it can continue to return Optional<DWARFFormValue> which asString can pass along as NOne if it's passed None (or passed a non-string value), and otherwise decompose into a string, etc)<br class="gmail_msg"><br class="gmail_msg"></div></div></blockquote></div><div class="gmail_msg"><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg">We basically have find already in:<div class="gmail_msg"><span style="font-size:11px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="font-size:11px" class="gmail_msg">Optional<DWARFFormValue> </span>DWARFDie::<span style="font-size:11px" class="gmail_msg">getAttributeValue(dwarf::Attribute);</span></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">We can easily rename it.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg">If find returns an optional then your first code example would need to be:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">x = Die.<span style="font-size:11px" class="gmail_msg">find</span>(DW_AT_name).getValueOr(DWARFFormValue()).asString();</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The second form could be made to work b<span style="font-size:11px" class="gmail_msg">ut it doesn’t look as natural IMHO. </span></div><div class="gmail_msg"><span style="font-size:11px" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg">Because of the first is awkward and the second seems less clear than just asking the DIE for the value I do think there is value in having the calls on DWARFDie. Let me know what you think.</div></div></div></blockquote><div><br></div><div>I'd still probably go towards the second - for orthogonality of features. Means a DWARFFormValue can be passed around and its value retrieved later, etc.<br><br>But would be good to hear from Adrian too. <br><br>Another option that Adrian might have thoughts on, would be to remove the Optional wrapper around the DWARFFormValue from getAttributeValue. It's not something I'd be totally happy with - Optional's nice and explicit about the fact that there might not be a value, but if DWARFFormValue already has a "not present" state in it, we could arguably use that state to indicate that.<br><br><br></div></div></div>