<div dir="ltr">Passing polymorphic data in sprokit is becoming more desirable. Ports on processes declare a logical type (as a string) for the data being passed, and a concrete type that is in the actual data packet which is passed as a boost::any (or equivalent). The intent of the kwiver_type_traits is to provide a baseline association between the two. The logical types are checked when the pipeline is built. the concrete types are checked by the boost::any when the value is retrieved. There may be something that could be done through the type traits to define a polymorphic type and do the type-casting and error handling. </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 1:53 PM, Matthew Leotta <span dir="ltr"><<a href="mailto:matt.leotta@kitware.com" target="_blank">matt.leotta@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">This has been a long standing issue with sprokit, from what I recall. It seems to me that we need a mechanism for allowing sprokit type checking to allow for casting up the inheritance hierarchy. A feature_track_set is a track_set, so any process that can process a track_set should also be able to process a feature_track_set. I’m not sure if there is an easy way of checking this because I think sprokit just does string name comparison for type checking. Maybe the type name strings could be “track_set”, “track_set.feature”, “track_set.object” and we could do substring comparison? Anyway, that is probably a discussion for another day. In your case, the issue is more challenging because there is also down casting involved. Ideally you want to encode that the input and output types for this process must be 1) the same exact type and 2) a track_set or some derivative of it. I’m not sure that we can do that in sprokit yet.<div><br></div><div>I mostly agree with the best practices rules in the PPTX, except that I’d like to see sprokit improved so that the first rule is not needed. For now, I think your Option 2 (slide 4) makes the most sense.<div><br></div><div>—Matt</div><div><br><div><blockquote type="cite"><div><div class="h5"><div>On Nov 15, 2017, at 1:22 PM, Brian Clipp <<a href="mailto:brian.clipp@kitware.com" target="_blank">brian.clipp@kitware.com</a>> wrote:</div><br class="m_-1986329448857955068Apple-interchange-newline"></div></div><div><div><div class="h5"><div dir="ltr">Pushing the tread over to kwiver-users. I attached the original ppt.<div><br></div><div>-Brian<br><br><div class="gmail_quote"><div dir="ltr">---------- Forwarded message ---------<br>From: Matthew Leotta <<a href="mailto:matt.leotta@kitware.com" target="_blank">matt.leotta@kitware.com</a>><br>Date: Wed, Nov 15, 2017 at 1:08 PM<br>Subject: Re: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline<br>To: Matt Phillips <<a href="mailto:matt.phillips@kitware.com" target="_blank">matt.phillips@kitware.com</a>>, Brian Clipp <<a href="mailto:brian.clipp@kitware.com" target="_blank">brian.clipp@kitware.com</a>><br>Cc: <<a href="mailto:kwiver-announce@public.kitware.com" target="_blank">kwiver-announce@public.<wbr>kitware.com</a>><br></div><br><br><div style="word-wrap:break-word">Guys,<div><br></div><div>Let’s take this discussion to the kwiver-users list rather than kwiver-announce. kwiver-annouce is supposed to be for major announcements, like new versions.</div><div><br></div><div>Of course this make me wonder if we really need kwiver-announce anymore. Is there anyone on this mailing list who is not also on kwiver-users and who only wants to receive very infrequent notifications about KWIVER releases and other major announcements? If this describes you, please send me a response privately. If I get no responses in a week or so, I think we should retire this list and use only kwiver-users. That pattern aligns better with what our other open source projects do for mailing lists.</div><div><br></div><div>Thanks,</div><div>Matt</div></div><div style="word-wrap:break-word"><div><br></div><div><br><div><blockquote type="cite"><div>On Nov 15, 2017, at 12:56 PM, Matt Phillips <<a href="mailto:matt.phillips@kitware.com" target="_blank">matt.phillips@kitware.com</a>> wrote:</div><br class="m_-1986329448857955068m_7155049012537094721Apple-interchange-newline"><div><div dir="ltr">Is the issue here just slicing when derived class objects are passed to Keyframe selector? I'm not familiar off the top of my head with how sprokit does serialization/deserialization but might making that 'slice-proof' be the answer? By e.g. storing type information and using factory methods at construction.<div><br></div><div>Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp <span dir="ltr"><<a href="mailto:brian.clipp@kitware.com" target="_blank">brian.clipp@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi All.<div><br></div><div>I ran into a case yesterday where I had a process that output a child class and a process that expected an input from it of the parent class. Sprokit's type checking fails in that case. It lead me to spend some time thinking about what types to pass between processes. After some discussion with Aaron and Matt B. these are some suggestions I've arrived at. </div><div><br></div><div>Thoughts?</div><span class="m_-1986329448857955068m_7155049012537094721HOEnZb"><font color="#888888"><div><br></div><div>Brian</div></font></span></div>
<br>______________________________<wbr>_________________<br>
Kwiver-announce mailing list<br>
<a href="mailto:Kwiver-announce@public.kitware.com" target="_blank">Kwiver-announce@public.<wbr>kitware.com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/kwiver-announce" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-<wbr>announce</a><br>
<br></blockquote></div><br></div>
______________________________<wbr>_________________<br>Kwiver-announce mailing list<br><a href="mailto:Kwiver-announce@public.kitware.com" target="_blank">Kwiver-announce@public.<wbr>kitware.com</a><br><a href="http://public.kitware.com/mailman/listinfo/kwiver-announce" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-<wbr>announce</a><br></div></blockquote></div><br></div></div></div></div></div>
</div></div><span id="m_-1986329448857955068cid:15fc0eaed97bfec7ed31"><Inherited Types in Sprokit Pipelines.pptx></span>_______________<wbr>______________________________<wbr>__<br>Kwiver-users mailing list<br><a href="mailto:Kwiver-users@public.kitware.com" target="_blank">Kwiver-users@public.kitware.<wbr>com</a><br><a href="http://public.kitware.com/mailman/listinfo/kwiver-users" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-users</a><br></div></blockquote></div><br></div></div></div><br>______________________________<wbr>_________________<br>
Kwiver-users mailing list<br>
<a href="mailto:Kwiver-users@public.kitware.com">Kwiver-users@public.kitware.<wbr>com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/kwiver-users" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font color="#888888"><b>Linus Sherrill - </b></font><font color="#888888">Staff R&D Engineer<br></font><font color="#888888">Kitware, Inc.<br>28 Corporate Drive<br>Clifton Park, NY 12065-8662<br>E: <a href="mailto:linus.sherrill@kitware.com" target="_blank">linus.sherrill@kitware.com</a><br>P: 518.881.4400<br></font></div></div></div></div></div>
</div>