Update to VFW 1.3.5 : Serialize generic List and UnityEvent<> display

[YacineFenina]

Hi,

I'm trying to update my project with your new update but I come across some difficulties as pointcache :

=> In generic class I have some List with generic argument that are determined in inherited class

public class SingleElement<KComponent> where KComponent : Component {}

public class SingleElement_AudioSource : SingleElement<AudioSource> {}

public class BaseClass<KComponent>
where KComponent : Component
{
      public List<SingleElement<KComponent>> list;
}

public class Class_AudioSource : BaseClass<AudioSource>{}

Then if I try to hit play after adding some SingleElement_AudioSource to my "list", it vanish. With your previous system, it worked. I heard about Unity serialization and generic list. If that's possible, I don't want to create a List for each new SingleElement class. Is there any way to make it work again ?

=> I'm trying to change uAction to UnityEvent<T0,T1,T2,T3> but I can't display it on editor. I don't want to add delegate in editor, but with your previous version, I was able to change call order in delegate stack. Is there anyway to continue to do that ?

Thanks for your help ! Yacine

[vexe]

Did you read my latest posts in VFW thread? Support for complex serialization is deprecated (the code is still there though).

Are you inheriting Base or Better Behaviour?

What are you trying to achieve here? why do you need all those generic parameters and inheritance? Looks like it could be solved in a simpler fashion.

[YacineFenina]

Actually, I don't know what do you mean by VFW thread ? this : http://forum.unity3d.com/threads/open-source-vfw-135-drawers-save-system-and-full-exposure.266165/

I was thinking that if it was deprecated, it means, it's better to stop to use it.

Actually I want that when I add a new class that inherit from BaseClass ( which actually inherit from BaseBehaviour as recommend by you), my List will accept only a specific component type.

[vexe]

Yes that thread. And yes you're right, deprecated means it's better to stop using it if you can help it.

What you're doing seems it should work, just remember since you're dealing with Unity serialization now to mark your classes with [Serializable] and make sure the generic parameters to List are serializable types too.

I'm not sure what you're trying to do, why can't you just hardcode what the list has? i.e. public class MyClass : Whatever { public List list1; public List list2; }

etc?

[YacineFenina]

All my generic class are mark with [serializable] but it doesn't work ;(

Actually, my BaseClass is like an extension of component. I want that each of them own a list of class that depend of the Component Type to make some specific action on it.

If I do what you say, I will have component extension with a lot of list that will be useless.

Is there any reason for deprecate your serialization tool ? It was so useful for me !

[vexe]

I've ranted a ton about why I did this. If you read the last post, I reference two other posts where I talk in detail about why it's such a bad idea. But in short: it's super bad for performance, super slow, unstable, unreliable and unusable for large scale projects and encourages people do practice bad programming practices (OOP, virtual, polymorphisim, etc) that make their code so complex, hard to read and impossible to use. In theory it might sound useful, but in practice it falls burning down short in real life complex projects, things just break everywhere. At work, we developed our own data format, we keep Unity serialization out of our way completely, we don't have any serializable class or field. That's pretty much the way to go in Unity it seems, for any system X, if you want X to work well, implement it yourself. At that point, what's the point of even using Unity if everything they make and advocate is garbage, and I have to write everything again myself? might as well make my own engine...

If you're in the middle of your project and you're heavily reliant on VFW serialization features, you could stick to 1.3.4, it's reasonably stable. Or still use 1.3.5, the serialization stuff is still there, just marked with 'obsolete' (in the VFW Deprecated folder).

How many concrete types will you have of this thing? Why can't you just go concrete on the types and cut down the complexity of having to deal with generics instead? I don't see why can't you just go:

public class MyClass_Audio { public List< AudioSource > TheList; }

public class MyClass_Image { public List< Image > TheList; }

[vexe]

Show me your actual code, paste a small snippet that you expect it to work but not working.

[YacineFenina]

Well .. I hope I don't offend yourself ... I'm reading now your posts. I may do some bad practice... I think I want to complicate life ! :p

I will think about concretised component extension. I will do it easier with concrete class.

As you say, I've done things complicate that I can't explain in a few lines. I'm going to do it easier !

[vexe]

You didn't offend nobody dude. All I wanted in my framework is to help ease development on myself, and other people. Some aspects of the framework did do that genuinely (the editor/drawers stuff), while other aspects did the exact opposite. When I wrote that stuff I had no idea it was bad, I was inexperienced back then thinking that all this stuff is 'cool', but it is really not.

So I apologize to you and all users who had to go through the bullshit parts of my 'framework'

There's a point in our lives where we all fall into the lies and traps of object-oriented programming and write lots of shitty codes, but eventually if you program long enough you'll see through the lies. I encourage you to checkout Handmade Hero by Casey Muratori https://hero.handmadedev.org/jace/guide/ - and watch this sample video on oop https://www.youtube.com/watch?v=IRTfhkiAqPw

If you come across any problems, or have any questions, even if it's not VFW related, don't hesitate to contact me.

[vexe]

And just to give an example, here's something I wrote a long back. This is by far the WORST code I ever wrote in my life. It's super embarrassing to that point that I actually requested a disassociation of the question from my account, cause that's just NOT the way I program anymore. But it just gives you an idea of what could happen if you follow these nonsensical object oriented principles and methodologies... http://codereview.stackexchange.com/questions/35807/comparison-between-two-design-battle-approaches

I wanted to delete the question but decided to keep it as an example to show others how NOT to write code. So I moved from the simple code that did: inventory.Swap(...) to inventory.swapper.Swap< SnapSwap >(new SnapSwapArgs(1, 2, 3, etc)); LMFAO...

[vexe]

From my experience, I can guarantee you 99.99% that ANY problem that you use virtualizim/inheritance/whatever to "solve" can be solved in MUCH more simpler and even powerful means. All you have to do to see those means, is to get oop out of your head and think of: Data and Functions. That's all a program is, you have data, and functions that does transformations on the data. It's never about objects and how they live and interact with each other. If you understand your problem, understand what data you're dealing with, you will be able to come up with much better and simpler solutions that solve exactly that problem. Specific solutions are almost always better than general ones (for that I refer you to a talk by Jon Blow https://www.youtube.com/watch?v=JjDsP5n2kSM)

[YacineFenina]

That's a lot of things to see ! Anyway, thank you for your work. I'm learning a lot with your plugin, even that's a misstake ! I have a lot to learn !

Your sentences remember me this music : https://www.youtube.com/watch?v=XdM2pD-oGZk :p