Hiding FlatSharp internal properties on generated classes

[thomas-t1]

I've been using FlatSharp for years now for internal company tooling. I'm using PowerShell 7 cmdlets to expose and manipulate flatbuffers through FlatSharp. This has the downside of also exposing the FlatSharp internal properties to the shell.

We are moving to expose this to external users so I need to find a way to hide these unexpected (for the user) properties.

My first thought was to inject custom attributes (i.e. that will cause PS to hide these properties by default) on the internal FlatSharp properties, is there a way to achieve this today?

Are there other ways to solve this. I could try to contribute but some guidance on how to implement it would be appreciated.

[thomas-t1]

After looking at the code, the issue is the properties of the IFlatBufferDeserializedObject interface.

The implementations seem to be generated in DeserializeClassDefinition.ToString().

A solution would have to add a reference to an assembly containing the attribute implementation and emit the attribute on the interface members.

Emitting the attributes would apparently be possible in the above ToString() function, but introducing an assembly reference would have to be specified somehow as well as the attribute. In my case the assembly would be System.Management.Automation and the HiddenAttribute

Any pointers on how this could be implemented in a generic way, that does not interfere with the plain generator, would be appreciated.

[jamescourtney]

Hello -- apologies for my late response; I've been out of the country on vacation. Are you worried about all members of the FlatSharp.Internal namespace, or just IFlatBufferDeserializedObject?

Regarding System.Management.Automation.HiddenAttribute, I don't think it's appropriate for FlatSharp.Runtime to take a dependency on the System.Management.Automation package. Does powershell look at the interface definition or the implementation to determine whether or not to hide members?

Here are a few questions at the top of my mind:

• If you're using this from powershell performance may not be critical, so perhaps the easiest thing would just to be to use the copy constructor to convert the derserialized object back to the base type:

      MyType type = MyType.Serializer.Parse(buffer);
      return new MyType(type);

  This ensures that the returned value doesn't implement IFlatBufferDeserializedObject.

• Does powershell's hidden attribute respect duck typing? If I define my own System.Management.Automation.HiddenAttribute, will PS respect that even if I'm not referencing the real package?

• We could add a new attribute to suppress the implementation of IFlatBufferDerserializedObject from the FBS file:

    table MyTable (fs_implementDeserializedObject:"false") { ... }

  While this is generic, it makes me feel a bit squeamish.

• We could add a command line switch to the Flatsharp compiler to suppress implementation of IFlatBufferDeserializedObject. Similar feeling as the above for me.

[thomas-t1]

Thanks for getting back to me. Performance is probably not an issue for me, so I will try the convert method you suggest.

Regarding a more generic solution of adding attributes; I did a quick test in PowerShell and the value is hidden if the implementation has the [Hidden] attribute. I'm assuming that the reason for the question is to verify that adding the attribute to the generated code will work, and it does 👍

I would be interested in all properties from FlatSharp that are exposed, I just mentioned IFlatBufferDerserializedObject since that is the one that I can see in my particular case. Here is an example

I agree that adding a new assembly reference to FlatSharp itself is not appropriate and why I suggested above that this would have to be provided to the codegen somehow and only present in the generated code.

DeserializeClassDefinition.ToString() seems to be where the interface implementation code is generated?

But the main issue is how to specify and dynamically add an assembly reference to the generated code? I guess the fully qualified attribute name would have to be specified somewhere in the .fbs, but where that happens in FlatSharp is currently beyond my understanding.

Maybe something like this would be possible;

table MyTable (fs_internalPropertyAttribute: "System.Management.Automation, System.Management.Automation.HiddenAttribute") { ... }

Ideally this would be a global setting but I'm not sure if that is possible?

[jamescourtney]

How did the "convert" approach go? I think your approach is worth a prototype if the converting wasn't good for you. I still feel a bit squeamish about this whole thing, but I'm sympathetic to the issue.

We probably only need to update the Compiler project and not the "FlatSharp" project. The history is that FlatSharp originally supported attribute-based schemas, so the "FlatSharp" project is reflection based, and the "Compiler" project just emits the correct definitions with the correct attributes for the reflection code to run. I'd ideally rewrite everything to use only the compiler, but there's no time for that :)

Anyway, I don't think you need to worry about assembly reference since the new attributes need only be emitted in the last phase of the operation. You should be good with a fully-qualified type name.

Another option would be to make this a command line switch and move it out of the FBS schema. I'm not sure which I prefer to be honest.

[thomas-t1]

I implemented the workaround you suggested by using the "copy constructor", that removes a lot of clutter, thanks!
The only property left is then Serializer which ideally I would like to remove. I guess the more complicated attribute route is my only options for that one?

[jamescourtney]

I've actually given this a bit more thought. I think the better way would be to have some equivalent of a .ToPlainObject() method that is just the basic class definition with no adornments. It would be a one-way conversion from proper object to plain object. I'm still not super thrilled with the idea, but I like it better than injecting C# attributes into FBS attributes.

Another option would be to remove the .Serializer property all up from the class definitions and re-introduce FlatBufferSerializer, which would have knowledge on all the compiled types. This would be a pretty monumental breaking change, however. It's something I will add to the "potential breaking change" backlog, but I prefer to aggregate those into one periodic major release instead of a trickle of them.

Finally, the last option is for you to solve this in your application and not in FlatSharp, since I'm not sure this really fits in with FlatSharp's domain. You could do a version of .ToPlainObject() yourself in your own application code. If you have a huge schema this will be cumbersome, but it seems like something you could do with a source generator or other tooling outside of FlatSharp, such as AutoMapper. Since this is a powershell-specific issue, then you could also just create dynamic objects with the properties you want copied over, no? It also seems like a roundtrip through a JSON serializer might solve your problem as well.