#SerializedTuples

1 messages · Page 1 of 1 (latest)

versed valley
#

Hey, nicely done, some clever coding!

I understand the uses for it as listed in the readme. I can't help but feel that 1. It is breaking the point of tuples, to be light weight temporary. And 2. Most of the reasons listed I thinking have better ways of solving them.

#

The only minor thing that comes to mind is I would remove the nested folders inside of Editor and Runtime as they are redundant (both Editor and Runtime area already in a SerializedTuples folder) and jut add another layer to go though. But again, really minor and some what of a preference thing.

fallow moss
#

First of all thank you for actively browsing thread and reviewing stuff!.

#

For point 1:
I actually couldnt come up with a better name, Tuple was one thing that came to mind as it already represents being a tuple in a table ? ig? But I didnt knew they were designed to be temporary since they are classes, I designed SerializedTuple with minimal memory footprint as there is no extension to any kind of unity object. But do enlighten if there is any better naming 🙂

#

For point 2. Most of the reasons listed I thinking have better ways of solving them
I really would love a discussion on this. Either I'm missing something very obvious or I am unclear in description, Do let me know :D.

versed valley
#

Yeah, the main thing tuples are made for is to pass data, commonly for returning multiple values from a method, or passing data in linq methods.

public (int min, int max) GetRange() { return (5, 10); } // Bad example, but shows the concept.
versed valley
# fallow moss For point 2. *Most of the reasons listed I thinking have better ways of solving ...

For using data across assemblies, this should be solved at the assembly level. So if you know assembly A needs something from Assembly B, then you need to either make a generic assembly C that both A and B can reference or need to otherwise change the structure. So this is really more of a organization/structure/design thing.

I am not sure I understand the use-case of passing data to non Unity systems. As nothing prevents you from just creating a struct/class and passing that around.

And if you need to set values of a POCC that is not serializable, chances are you will need to do it in multiple places, so it is best to either make a wrapper, inheritor, or 'data only copy' of it that you convert to it.

#

(There may be exceptions to these cases, but I am talking like +90% of the time)

#

Basically, if you are going to be referencing the same set of data multiple places or need to make it a field, it should probably be a struct or a class, and not a tuple.

fallow moss
#

(There may be exceptions to these cases, but I am talking like +90% of the time)
I understand fully, Only reason to discuss is to broaden my understanding thats all. I very well know there is no silver bullet for all case.

versed valley
#

(You can put > with a space after it in front of text to quote it btw)

#

Yeah, as I said, it looks well written! Just giving my thoughts. And if it works for you, thats great! 😄

fallow moss
#

For using data across assemblies, this should be solved at the assembly level. So if you know assembly A needs something from Assembly B, then you need to either make a generic assembly C that both A and B can reference or need to otherwise change the structure. So this is really more of a organization/structure/design thing.

So I usually design my systems this way, Where each Runtime Assemblies are unaware of Editor code and Editor assemblies simply utilise the runtime code, Which is usually the 99% of times how system are designed.
Now problem occures when there is a need to Invoke from Runtime.
For eg, I have a Physics.OverlapQueryDrawer for drawing all kinds of overlap code, Now I have to place the drawer code in Runtime though it possess an editor context. but it needs to be during runtime as any code which wants to display an overlap query will need to access the OverlapQueryData object to pass it to the drawer.
Now it is possible to shift all of them to Runtime, but I really wish to avoid that. Instead I would prefer inversion in a way I can pass data without worrying about that. Enters SerializedTuples. Yes the caveat is that all other assemblies need to reference the Tuple, But I have a CommonDS assembly (like System) which every assembly inherits thus providing the inversion while avoiding cyclic dependency problem.
Would love to know your takeway 😄

image.png
#

Also I use reflection heavily so that there is no leak of Editor requirement context in Runtime code. But this was something bugging me for long time as there was not anything which can be used as an IOC-DO. which is what my primary intent was behind the design.

versed valley
#

Not sure I quite understand what Physics.OverlapQueryDrawer is or how you are using it. I take it it draws gizmos in the scene view like the Gizmos class? But if it is, then I would say it should be moved to runtime assembly.
One thing you can do is basically invoke a event, or put a command in a list or someting in runtime, and then have the editor code listen to the event or iterate over the list if the editor needs to handle the actual drawing.

fallow moss
#

Yes it a wrapper over Gizmo drawers, nothing fancy.

versed valley
#

Yeah if it is just Gizmo drawing, then it should be in the runtime assembly like Gizmos is.

fallow moss
#

Yes I can simple invoke an event or command in list but it seems a leakage in context between editor code and actual runtime. like an extra to the original design.

#

which is what i wanted to avoid

versed valley
#

I don't see it as a leakage of context. Not anymore than Debug or Profiler is. And not any worse than the tuple approach imo

fallow moss
fallow moss
versed valley
fallow moss
fallow moss
#

Nothing prevents you from just creating a struct/class and passing that around.
And if you need to set values of a POCC that is not serializable, chances are you will need to do it in multiple places, so it is best to either make a wrapper, inheritor, or 'data only copy' of it that you convert to it.

True nothing prevents from designing a class and passing that around and as number of systems increase. You need equal number of classes to pass data in an out. So with SerizTuple that extra part of definitions can be avoided.
Also there is nothing wrong with making them serializable but having only fields in tuple helps avoid serialization of entire classes.
Second these allow me to pass data in constructors of POCO as data objects connected with inspector which allows tweaking values in inspector at runtime, Sure I can use normal classes to propogate data but this helps not reinventing the wheel. Thats all ! Also it also helps as I dont have to worry about the inspector accessibility and Object/class explosion.

fallow moss
#

Hope im making some sense ig XD, Any thoughts @versed valley

versed valley
fallow moss
#

Agreed agreed, Thanks for insights.

versed valley
#

Sure thing, and best of luck! 😄

fallow moss
#

Thank you 😄

warped compass
#

When I want to bridge runtime and editor code I usually use an interface

#

and I define the interface implementation with #if UNITY_EDITOR

fallow moss
#

@warped compass Earlier I had a similar approach, but as the codebase expanded there were too many interfaces and #if defs and it felt quite redundant to me.

warped compass
#

I have large line count in my code in some of my systems and I just do 1 or 2 bridging interfaces.

# 
                    if (suppressException)
                        throw new System.Exception($"Trying to insert {array[i].v2} while key {array[i].v1} is already present");
                    else
                        continue;``` btw, shouldn't it be `!suppressException`?
fallow moss