[Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline

[Linus Sherrill]

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.

On Wed, Nov 15, 2017 at 1:53 PM, Matthew Leotta <matt.leotta at kitware.com>
wrote:

> 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.
>
> 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.
>
> —Matt
>
> On Nov 15, 2017, at 1:22 PM, Brian Clipp <brian.clipp at kitware.com> wrote:
>
> Pushing the tread over to kwiver-users.  I attached the original ppt.
>
> -Brian
>
> ---------- Forwarded message ---------
> From: Matthew Leotta <matt.leotta at kitware.com>
> Date: Wed, Nov 15, 2017 at 1:08 PM
> Subject: Re: [Kwiver-announce] Best practices for passing inherited types
> through Sprokit Pipeline
> To: Matt Phillips <matt.phillips at kitware.com>, Brian Clipp <
> brian.clipp at kitware.com>
> Cc: <kwiver-announce at public.kitware.com>
>
>
> Guys,
>
> 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.
>
> 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.
>
> Thanks,
> Matt
>
>
> On Nov 15, 2017, at 12:56 PM, Matt Phillips <matt.phillips at kitware.com>
> wrote:
>
> 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.
>
> Matt
>
> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp <brian.clipp at kitware.com>
> wrote:
>
>> Hi All.
>>
>> 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.
>>
>> Thoughts?
>>
>> Brian
>>
>> _______________________________________________
>> Kwiver-announce mailing list
>> Kwiver-announce at public.kitware.com
>> http://public.kitware.com/mailman/listinfo/kwiver-announce
>>
>>
> _______________________________________________
> Kwiver-announce mailing list
> Kwiver-announce at public.kitware.com
> http://public.kitware.com/mailman/listinfo/kwiver-announce
>
>
> <Inherited Types in Sprokit Pipelines.pptx>_______________
> ________________________________
> Kwiver-users mailing list
> Kwiver-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/kwiver-users
>
>
>
> _______________________________________________
> Kwiver-users mailing list
> Kwiver-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/kwiver-users
>
>


-- 
*Linus Sherrill - *Staff R&D Engineer
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065-8662
E: linus.sherrill at kitware.com
P: 518.881.4400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/kwiver-users/attachments/20171115/1d41c608/attachment.html>