[Smtk-developers] Resource and ResourceComponent Types

[Bob Obara]

We discussed having Attribute Definitions also be a Resource Component (like Attribute).  After some thought I think this is not a good idea for the following reasons:

Definitions would have a UUID assigned to them as well.  The complication this introduces is that currently all attribute template files are written by hand and would not initially have one
Technically an attribute template is for the creating of a new attribute system so what would it mean for definitions to a a UUID that is the same for different attribute systems.


Comments?

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 5:48 PMEDT, Bob Obara <bob.obara at kitware.com> wrote:
> 
> 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 <mailto: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/a19a7628/attachment.html>