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

Wed Nov 15 14:23:31 EST 2017

So this new idea is simpler but more permissive than it needs to be.
feature_track_set is a track_set but isn't a object_track_set.  Only the
former would be allowed, so Sprokit's type-checking system would have to be
made to understand the inheritance relationships somehow, but what you just
described Brian would be prohibited.

Matt

On Wed, Nov 15, 2017 at 2:15 PM, Brian Clipp <brian.clipp at kitware.com>
wrote:

> 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
>>>
>>>
>>>
>>
> _______________________________________________
> 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/69b24027/attachment-0001.html>