Comments (10)
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.
Related Issues (20)
- Symbols not accessible in modules using only `using SumTypes: @sum_type` HOT 1
- StackOverflow in show_sumtype usage HOT 1
- Allow specifying a supertype
- Document allowing field names
- `@cases` on tuples HOT 1
- Using parametric struct and only defining the top level type makes it errors out HOT 1
- sum types are not `isbits` HOT 2
- default in `@cases` when unpacking is not necessary HOT 5
- mutable sum types? HOT 4
- Support for kwdef constructors HOT 1
- SumType becomes less memory efficient with non-isbits fields HOT 9
- Error when creating SumType in an untyped vector HOT 2
- Strange error when sum_type macro is used inside a begin block HOT 2
- Docstring for `@sum_type` HOT 1
- Memory corruption in 0.9.3 HOT 3
- `@sum_type` doesn't work with constrained type parameter in variant HOT 7
- Adding the package installs version 5.5 instead of 5.7 HOT 1
- Can constructors of a sum type be alias of variants? HOT 1
- Support const decorator for fields HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sumtypes.jl.