<FromGitter>
<j8r> I don't know yet if it's better to have annotations standardized in the `Object#from`, or let the `MyFormat.serialize` dealing with
<FromGitter>
<j8r> standardization vs flexibility
<FromGitter>
<Blacksmoke16> hm
rob264 has joined #crystal-lang
<FromGitter>
<j8r> I'd say having standard annotations, then others that are passed as arguments
<FromGitter>
<Blacksmoke16> im assuming for it to use the custom args they would have to override the serialize method to tell it how to utilize the custom args?
<FromGitter>
<j8r> no necessarily, there is a `**serialization_args` then having a macro inside
<FromGitter>
<Blacksmoke16> a macro inside? that could be implemented by the user to define the custom logic?
<FromGitter>
<Blacksmoke16> i see how extra args could be passed in, but how would it know what to do with them?
<FromGitter>
<j8r> nvm yes, you could have a custom serializer/deserializer
<FromGitter>
<j8r> yes
<FromGitter>
<Blacksmoke16> i think ideally this would be a shard of its own so that its easier to add feature sto
<FromGitter>
<Blacksmoke16> vs part of stdlib
<FromGitter>
<Blacksmoke16> i always had an idea but its not super easy to implement atm
<FromGitter>
<Blacksmoke16> where you give an ivar a path, then on deserialize would set that property to the value at the end of that path
<FromGitter>
<j8r> the concept has its place on the stdlib, this would prevent having custom annotation like `YAML::Field` or `JSON::Field`
<FromGitter>
<j8r> then extending it can of course be in a shard
<FromGitter>
<Blacksmoke16> i.e. unify them into one
<FromGitter>
<j8r> yes, this what it does
<FromGitter>
<Blacksmoke16> not sure its a big deal but then you would lose being able to target a specific type?
<FromGitter>
<Blacksmoke16> i.e. ignore this property on to_json but not on to_yaml
* Jenz
O_o
<FromGitter>
<Jens0512> Oh, now it's working
<FromGitter>
<j8r> For example you can deserialize from json, and serialize to YAML easily
<FromGitter>
<Blacksmoke16> id have to see more fleshed out alternatives, but im quite a fan of the current include mechanic
<FromGitter>
<Blacksmoke16> pretty sure the mapping doesnt allow for inheritance
<z64>
`MyFormat.serialize(foo, io)` / `MyFormat.deserialize(io) : Foo` is the cleanest thing - and in fact already exists as `IO#read_bytes(T, endian)`/`#write_bytes(t, endian)` - but people don't want to type that much it seems :P
<FromGitter>
<Blacksmoke16> :p
<FromGitter>
<Blacksmoke16> *effort*
<FromGitter>
<Blacksmoke16> was looking into how minification happens on JS. is pretty neat how some of it works
<FromGitter>
<Blacksmoke16> true/false gets converted to like `!0/0`
<FromGitter>
<Blacksmoke16> gotta save them extra characters
<z64>
yes, now you implement `#to_io`, and you use the format argument to encode to a specific format
<FromGitter>
<vladfaust> That's harder than including a module
<FromGitter>
<vladfaust> @j8r did it in his forum post I guess
<z64>
not the point, i'm not talking (yet) about magic; this cleanly seperates serialization logic. you could have some macro that generates a formatter for your type
<z64>
basically, you could have something that generates this: https://carc.in/#/r/6lhx ; this is more similar to, on topic, what rust serde does (...)
<z64>
consider you want to have a generic formatter JSON. `def self.encode(obj : Foo)` becomes `def self.encode(obj : T) forall T` - which i realize the issue with that, but bear with me. consider also, `def self.decode(io)`.. when you have multiple objects, in crystal, the return of this now becomes a union of all serializable types
<z64>
you "solve" this by generating `{% if T == Foo %} .. code that returns Foo {% end %}`
DmitryBochkarev has quit [Ping timeout: 272 seconds]
<z64>
to me this would be perfect; there is no type tree / method pollution, or relying on `include` just to trigger some macros after the final type pass, etc.
<z64>
but we can't generate this because, as i mentioned previously, our generics aren't powerful enough. rust is capable of doing these specializations for any type, which we can't do
<FromGitter>
<Jens0512> I think our generics has huge potential, i.e. they're quite flawed ATM, but I don't think there is much that is missing (from a semantic standpoint) before they'll be huge
<FromGitter>
<Jens0512> I'm an idiot though
<FromGitter>
<Jens0512> In many ways, as everyone are
<FromGitter>
<Blacksmoke16> this would make a nice addition to `Spec`
<FromGitter>
<PlayLights_twitter> Hello everyone :) Im experiencing something weird, Do you know why openSSL on decrypt randomly throws `EVP_CipherFinal_ex: Unknown or no error (OpenSSL :: Cipher :: Error)`
<FromGitter>
<dscottboggs_gitlab> So, what editors do you guys use/prefer?
<FromGitter>
<Blacksmoke16> sublime atm
<FromGitter>
<dscottboggs_gitlab> I've been using Atom since before I started using Crystal, but I kinda find the plugins lacking. ⏎ ⏎ I should just fix the plugins for it :/
<FromGitter>
<Blacksmoke16> sounds like a plan :P
<FromGitter>
<Blacksmoke16> sublime is nice as it auto formats on sa ve
<FromGitter>
<dscottboggs_gitlab> that and ameba integration are what I'm kinda wishing atom had now
<FromGitter>
<dscottboggs_gitlab> I do like the experience in vim a lot, but I don't like working on large, multi-file projects in vim.
<FromGitter>
<dscottboggs_gitlab> I mean, in atom, the syntax highlighting isn't even complete. I went to fix it one time, but it was like thousands of lines of coffeescript and I just noped out.
<FromGitter>
<Blacksmoke16> quite happy with how it turned out
<FromGitter>
<dscottboggs_gitlab> I've been thinking about that lately, it's kinda interesting. Making `require`s work the way they do and allowing reopening of constructs across files kinda exposes how the compiler works in a neat way. Especially once you understand that later defined AST-nodes overwrite previously-defined ones