Can Silver generate .NET fields instead of properties?

Elements Silver
, ,
1

Probably a long shot, but is it possible to get Silver to generate fields instead of properties when targeting .NET?

Compare CSharpClass.PublicField and SwiftClass.PublicStoredProperty in the code and assemblies below:

C# class

public class CSharpClass
{
    public string PublicField;
    public string PublicProperty { get; set; }
}

Resulting C# assembly

public class CSharpClass
{
  //
  // Fields
  //
  public string PublicField;

  //
  // Properties
  //
  public string PublicProperty {
    get;
    set;
  }

  // ...

Swift Class

public class SwiftClass {
    public var PublicStoredProperty = ""

    private var _privateString = ""
    public var PublicComputedProperty: String {
        get {
            return _privateString
        }   
        set(newValue) {
            _privateString = newValue
        }
    }
}

Resulting Swift assembly

public class SwiftClass
{
  //
  // Properties
  //
  internal virtual string _privateString {
    get;
    set;
  }

  public virtual string PublicComputedProperty {
    get;
    set;
  }

  public virtual string PublicStoredProperty {
    get;
    set;
  }

// ...
2

Not currently, Swift’s vars are more like properties than fields. What do you need this for?

3

Thanks for the reply Carlo! That makes sense.

I might not need it now that I understand more of what’s going on, but my I think my issue ultimately around serialization.

I’m attempting to use Swift/Silver with Unity3D (which uses a Mono runtime for scripting). Yesterday I started this thread as the Unity editor uses public fields to generate UI fields. I have since solved that issue by using their support for customizing GUI logic.

Unfortunately, I think I’m now running into serialization issues. They use custom serialization which seems to handle/prefer fields without issue. I tried a couple simple things yesterday that didn’t work, but I’ll be looking deeper into it tonight to see if I can work around it without anything too complex.

4

:tada:

I actually found a hack using Aspects. I added one that will change the property’s underlying field’s visibility to public. So far this seems to properly expose and serialize my object in Unity’s editor. Not ideal, but enough for me to continue along to see how this works.

Unity has a SerializeField attribute which is probably the better way to do this (keeping the field private), but I couldn’t figure out how to add that to the field via Aspects.

5

I’m thinking, maybe we could expose a @Field aspect/attribute to apply to vars to hint the compiler at generating plain fields? Carlo, what do you think?

6

Yeah that’s an option.

@tnydwrds alternatively, if you have a field (IField) and cast it to IFieldDefinition if needed. That should have an AddAttribute you can use to add that attribute.

7

Wow. You guys are super responsive. Thanks a lot.

I tried using AddAttribute last night, but ran into some difficulty. Likely just due to unfamiliarity. I’ll play with it some more this weekend.

8

Played around with aspects/attributes a bit more tonight and I’m good. They weren’t as scary as I thought they were and I was able to work out something using suggestions from both @mh and @ck.

Thanks again.

2 Likes