In Obj, there are now deprecation warnings all over (except on t and magic?)
I use Obj.t as a signifier of “typeless” object references in exceptions regularly. To me, it’s an ergonomic way to store “any value” in a var with some level of correctness (vs. Obj.magic which is basically throwing everything out the window). For debugging purposes, storing Obj.repr(whatever) as the “relevant exception source object” works well.
Apparently Obj.repr is now deprecated. I mean it’s trivial to roll my own, I’m just curious why this was done and if there’s anything else in the stdlib that I could use.
this is how i use it. it’s a convenient way of say “some object/value” which is ok for debugging/errors. I don’t want to use JSON.t because JSON.t definitely isn’t “any object”
well, unfortunately for now you’d still have to use Obj.magic for this, or an identity external. I’d like to have coercion of all types to unknown, hopefully this will be added in v12.
Great, looking forward to it. I usually end up sprinkling Obj.magic throughout the code which I don’t really appreciate. They work as a sort of “this stuff is unsafe” greppable marker, but transforming to unknown is rather safe. :]
The semantics of Obj.t is close to JavaScript’s Object, which is actually the top type. So the belief that unknown is safer than Obj.t is a myth, because there’s very little the compiler can do about top types.
If it’s something for logging or display, it’s better to convert to JSON.t (or BSON.t in your case) early, because it really should be serializable.
In all other cases, it’s better to box values early, or to coerce at least your own abstract type. There’s no good reason to turn a well-known type into “unknown”.
right, what I’m saying is that transforming to any top-type (unknown or something else) is safe, and that’s why I want to avoid use Obj.magic, which I use as a “this stuff is not safe” marker. that’s why I’m using Obj.repr instead, which gives off a safer vibe (from a grep perspective, because it doesn’t signify anything dangerous, only Obj.obj or Obj.magic does that). which is why I was a bit put off by it being deprecated. makes sense?
I have my own MessagePack decoder for TypeScript written in ReScript.
And there is result instead of Obj.repr, but it is never used for value type. Because they have different semantics and different sources.
The conversion to the top type is safe, but other codes that receive that type must handle it structurally.
That is not healthy from a language perspective, but it is allowed for FFIs.
If your decoder doesn’t allow partial errors, the value type should be the same as the input. Suppose you used Result instead of an exception. The decoder already knows the input type 'a, so it shouldn’t need to coerce at all.
Then the compiler’s approach is to improve the type inferences on exceptions.
Thanks for your feedback, it’s valid but it also addresses things beyond my question. I would change to BSON.t but they’re unfortunately different from BSON.value. The codec is rather hacky atm, but I’ll address it later and incorporate your feedback.
Either way, is Obj being deprecated? Why isn’t Obj.t being deprecated, but everything else (except Obj.magic) is? I would like to see some 'a => unknown converter because I dislike using Obj.magic - I want to put it only where “absolutely needed” so I can grep for stupid stuff in my code base.
Either way, is Obj being deprecated? Why isn’t Obj.t being deprecated, but everything else (except Obj.magic) is?
Obj is a name from OCaml, so I think yes. I wanted to deprecate entirely, but it’s simply too widely used and causes compatibility problems (even inside the compiler itself). Maybe we’ll reconsider it in v12~v13
We have dict and unknown. You can coerce explicitly with %identity, the same way as Obj.repr.
I just wanted to mention my concern about supporting it at the syntax level. e.g. value :> unknown, unlike other coercions, the compiler cannot check anything.