[Smtk-developers] Resource and ResourceComponent Types

[Bob Obara]

My main question concerning ResourceComponent::type is should it be a superset of all the model entity types along with Attribute, Attribute Definition, Mesh Field, Mesh PointSet, Mesh Cell Set?  This would mean needing to conform to SMTK Models’ bit encoded pattern.

I think for now we could just use a enum class for Resource::Type.

Bob

Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




> On Aug 16, 2017, at 9:29 AMEDT, Haocheng Liu <haocheng.liu at kitware.com> wrote:
> 
> Hi David,
> 
> On Wed, Aug 16, 2017 at 9:18 AM, David Thompson <david.thompson at kitware.com <mailto: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 <mailto:Smtk-developers at smtk.org>
> http://public.kitware.com/mailman/listinfo/smtk-developers <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 <tel:(518)%20881-4421>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20170816/2490e2b8/attachment.html>