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

[Brian Clipp]

Would we allow down-casting?

-B

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

> I would prefer a string the makes the derivation order explicit rather
> than just an arbitrary list, like “track_set.feature”, but I could be
> convinced otherwise.  This way you can just match substrings from the front
> until you find a match.
>
>
> On Nov 15, 2017, at 2:37 PM, Matt Phillips <matt.phillips at kitware.com>
> wrote:
>
> 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/2b441c9b/attachment-0001.html>