[Smtk-developers] Resource and ResourceComponent Types

Haocheng Liu haocheng.liu at kitware.com
Wed Aug 16 09:29:19 EDT 2017


Hi David,

On Wed, Aug 16, 2017 at 9:18 AM, David Thompson <david.thompson at kitware.com>
wrote:

> > I’ve started modifying the existing Resource class and have a question
> as to how SMTK should return the Resource’s Type (model, mesh, attribute,
> etc..) - The class currently uses an enum which is fast and does enforce
> uniformity  but will require new types of resources to modify the base
> class to add new enum (like VTK) .  We also could just return a string
> which would be more flexible but is a bit slower to compare.
>
> At the resource level, strings seem to make a lot more sense because it
> doesn't feel like we've finished the list of resource types yet (candidates
> might be: simulation, job, view, workflow template).
>
> > The same question pertains to the type of ResourceComponents.
>
> Can we use dynamic casting of the parent resource or some other formalism
> to avoid the string comparison at the component level? That way things in
> tight loops would be fast but we would still be flexible. I worry that if
> we start with an enum and then add cases all the pre-existing switch
> statements would add fragility; people seem to deal with strings a little
> more defensively than enums.
>
> How about using C++11 strong type enum? I've already started using them in
smtk for the past months. It's type-safe, fast and flexible.

>         David
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>



-- 
Best regards
Haocheng

Haocheng LIU
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4421 <(518)%20881-4421>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20170816/61e4cfed/attachment.html>


More information about the Smtk-developers mailing list