getproperty for a SumType about sumtypes.jl HOT 10 CLOSED

Yeah I'll do it like this in case someone gets an old version of your package but a new version of SumTypes.

from sumtypes.jl.

No, accessing data through getproperty is a bad idea here and should not be done. You should only use the @cases macro to access the contents of a sum type.

from sumtypes.jl.

I've now explicitly disabled this: #59

If you really need to access the internals without @cases, you should use getfield.

from sumtypes.jl.

Hello, we use SumTypes for our tag system in QuantumSavory.jl and there's a lot indexing there, which causes a lot of breakage with the new release. Would you suggest replacing it with getfield, as in can we expect it to be a stable part of the api for SumTypes ?

from sumtypes.jl.

Ah crap, sorry for breaking your code @Abhishek-1Bhatt, can you explain what you were using getproperty for? The package was not really designed for one to be interacting with the insides of a sum type other than by using @cases. I considered the internals of a SumType to be package internals that can change anytime depending on the implementation needs of the package. But in practice they'll probably be somewhat stable.

There is a function SumTypes.unwrap though whose job is to open up a sumtype and return the thing it had stored inside, so if you really need to get inside, I'd recommend using that function.

The problem is that accessing the insides of a sumtype is inherently type unstable, but @cases is specifically designed to be able to provide a type stable access pattern that the compiler is able to understand.

from sumtypes.jl.

We use tags to store information about which node we're entangled with in a network of nodes. This information is updated when an EntanglementSwap happens and the nodes is now connected to another node, hence it requires querying the nodes about tag data at a lot of places. This functionality is implemented using SumTypes. SumTypes.unwrap seems to be a good fix for it, thanks!

from sumtypes.jl.

So why are you doing that update using getproperty and not using @cases? I'm just trying to figure out if there's some functionality missing from @cases here...

from sumtypes.jl.

We have all the possible cases for tags implemented as a sumtype:
https://github.com/QuantumSavory/QuantumSavory.jl/blob/fdcbe418f7bcba5956e1db1cbf629ff76f21ebf1/src/tags.jl#L1-L19

but then, an individual tag, lets say this EntanglementCounterpart tag would be just one of the types declared as a sumtype, which contains the entanglement information in the tag, which we need to query. The problem is that SumTypes perfectly fits the application here, but the way we use it isn't how it was intended to be used, I guess 😅 . Using @cases doesn't really work directly as we need the flexibility for it to work with any type of network topology and that way, the possible node ids can't be known or coded in advance

from sumtypes.jl.

Hm, I don't really get it, but I really don't want to break your stuff, I didn't realize people were using getproperty on sumtypes already.

How about I switch getproperty to emitting a deprecation warning?

from sumtypes.jl.

Thanks, but I have switched to using unwrap , so no worries from my side now, although its always a good idea if you have the time

from sumtypes.jl.