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

Wed Nov 15 14:37:11 EST 2017

Forget the exact signature but

class feature_track_set : public ...
{
   ...
   static std::string type_string() { return "feature_track_set,track_set";
}
}

Is one way to do it, just turn the name into a list of (permissible)
names.  This creates coupling issues but there can be an early runtime
check to ensure that given "A,B", B is actually a base of A.

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

> Yes, exactly.  That what I was getting at with the earlier idea of
> substring processing on the type strings, but there is probably a better
> way to implement it than that.
>
> On Nov 15, 2017, at 2:23 PM, Matt Phillips <matt.phillips at kitware.com>
> wrote:
>
> 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/9cba4a6d/attachment-0001.html>