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

[Brian Clipp]

Yeah, I'm not a fan of calling every flavor of track_set a track_set.  That
could allow us to connect object_track_set ports to feature_track_set
ports.  We could catch that when constructing the graph.

-B


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

> I’d rather not tell sprokit to ignore type checking on some subset of
> types, but not others.  However, equivalently you could define all
> track_set types to be “track_set” regardless of the specific derived
> class.  Then each process would need to check at run time if the track_set
> it got can be down cast to the type it was expecting.  That approach is
> equivalent, but probably less of a hack.  It’s still not ideal.
>
> —Matt
>
> On Nov 15, 2017, at 2:01 PM, Brian Clipp <brian.clipp at kitware.com> wrote:
>
> Agreed.  Matt P. had an interesting suggestion.  What if Sprokit's graph
> type checking would allow some potentially wrong graphs through to allow
> for up-casting?  It could catch really egregious issues, e.g. int passed
> into a port expecting a string, but not subtle issues like a track_set
> passed into a feature_track set port where the track set is in fact an
> object_track_set.
> Basically, the type checker would consider up-casts and down-casts as
> being equivalent types.  Most errors would be caught at pipeline
> construction time but a few might only be caught at run-time.
>
> -Brian
>
>
> 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/kwiver-users/attachments/20171115/dc1f398e/attachment.html>