hendursaga has quit [Remote host closed the connection]
hendursaga has joined #crystal-lang
<FromGitter>
<naqvis> Yes.
<FromGitter>
<naqvis> Because ClassMethods are designed for mixin with classes with no arg constructors
<FromGitter>
<naqvis> so extending them in standard api would make the extension harder for different implementations
<FromGitter>
<naqvis> think of it as a helper mixin which can be utilized by classes with argless constructor
<FromGitter>
<naqvis> provided support for md5, shaXXX use that, as these classes are just a wrapper against OpenSSL implementation of same algos
<postmodern>
ah ok
<postmodern>
you could modify the ClassMethods to accept a splat of additional args that get passed down to #initialize though.
<FromGitter>
<naqvis> that would change the `#digest` api
<postmodern>
the digest API has already been changed a bit since 0.35.0
<postmodern>
due to Digest::CRC32 being added and conflicting with my Digest::CRC32 in digest-crc.cr, I decided to rename the project to crc.cr (easier to remember/google). Should I also bump the version? guessing github will do redirects from the old repo path to the new one when people run `shards install`
_ht has joined #crystal-lang
teardown has quit [Remote host closed the connection]
teardown has joined #crystal-lang
hendursa1 has joined #crystal-lang
hendursaga has quit [Ping timeout: 268 seconds]
Vexatoast has quit [Quit: ZNC Quit]
Vexatos has joined #crystal-lang
f1reflyylmao has joined #crystal-lang
f1refly has quit [*.net *.split]
f1reflyylmao is now known as f1refly
deavmi has quit [Ping timeout: 265 seconds]
deavmi has joined #crystal-lang
andremedeiros has quit [Read error: Connection reset by peer]
<FromGitter>
<jrei:matrix.org> I can agree this is not intuitive, I'll look at how to fix this, or at least have a useful error
<FromGitter>
<jrei:matrix.org> but before doing that, could you reduce the examples in your issues? It will help me :)
<hightower2>
sure I'll try... let you know when done
<postmodern>
holy cow you can define an abstract struct which takes generics. that is too cool
<postmodern>
now i can support both RGB24 and RGB32 formats. apparently there's also some weird YUV pixel formats that use floats instead of uints.
<yxhuvud>
I don't understand why you need to make it abstract though.
<postmodern>
so i can inherit from it, also so i don't have to type RGB(UInt8, UInt8, UInt8) all the time
<FromGitter>
<jrei:matrix.org> postmodern: by experience if you combine inheritance and generics, you can have nasty bugs
<FromGitter>
<jrei:matrix.org> or just not intuitive behaviors
<FromGitter>
<jrei:matrix.org> hightower2: thanks! it help me for the specs too
<yxhuvud>
Add type aliases to the equation as well and it is really thin ice. But perhaps a sufficient amount of bugs have been ironed out since I last used it.
<hightower2>
jrei: so you wanna focus on #5 or #6 ?
deavmi has quit [Read error: Connection reset by peer]
<postmodern>
also it helps me reuse code from RGB in RGBA, which just adds an alpha channel
<postmodern>
previously i create a bunch of modules for each field i reused, i think a generic struct will be cleaner
<postmodern>
provided i don't segfault the compiler (knock on wood)
deavmi has joined #crystal-lang
<hightower2>
reduced, added comment to #5
<FromGitter>
<jrei:matrix.org> the root issue may be the same
<FromGitter>
<jrei:matrix.org> awesome, thanks!
<FromGitter>
<jrei:matrix.org> not really for the abstract struct issue, but when changing with modules or dedicated types it could turn into the other the #5 issue
<FromGitter>
<wyhaines> Ha! I didn't even notice that I did that. My mouse focus must have been over here, and in the flow of the moment, I didn't catch that at all.
hightower2 has quit [Ping timeout: 246 seconds]
<FromGitter>
<jrei:matrix.org> hightower2: so for #5, I need to have make a better error for unions
<FromGitter>
<jrei:matrix.org> the error should be `Error: no overload matches '#deserialize' with type (A.class | B.class)`.
<FromGitter>
<jrei:matrix.org> weird, I think the `to: ` is responsible
<FromGitter>
<jrei:matrix.org> I'd like to have S1, S2. not A, A
<FromGitter>
<jrei:matrix.org> maybe I could have a runtime case/when...
<FromGitter>
<Blacksmoke16> i remember running into this too
oz has joined #crystal-lang
zorp has joined #crystal-lang
<FromGitter>
<jrei:matrix.org> hightower2: got a fix for your issue, I'll push in few hours. ⏎ However, using modules instead of inheritance won't work (yet) because of unions
postmodern has joined #crystal-lang
<straight-shoota>
@jrei, @opypin: Based on your input on the session mechanism, I played a bit with alternative designs. Was a good idea.
<straight-shoota>
The result is a major refactoring, which improves many aspects besides polluting HTTP::Session
<FromGitter>
<jrei:matrix.org> I'll definitely look at it, I'm KO now :(
<postmodern>
so i'm guessing the crystal compiler can't do function overloading with the return types?
<FromGitter>
<Blacksmoke16> no, but you could combine it with like `def foo(_type : MyClass.class)` type overloads to do it
<FromGitter>
<Blacksmoke16> i.e. `foo(MyClass)` return `String`, but `foo(OtherClass)` returns `Bool`
hightower2 has joined #crystal-lang
<hightower2>
Hey jrei I see you founda a solution for #6, awesome, thanks!
<hightower2>
(with the method from #6 I was able to deserialize dependent on type)
_ht has quit [Remote host closed the connection]
<FromGitter>
<jrei:matrix.org> <3
<FromGitter>
<jrei:matrix.org> Remains adding support for type unions. By union, I mean T.class | U.class, not (T | U).class
<FromGitter>
<jrei:matrix.org> Note there is a little overhead, vs unrolling the loop with a macro. Should be negligible
<hightower2>
Yeah, what concerns me at this point is still this type-dependent deserialization. I mean it now works, I still didn't end up with very clean types without unions. I'll have to think about this some more because I don't have a clear picture in mind, but possibly macros will be the only way to avoid this... need to play a bit more with it to understand better.
<hightower2>
s/I still/but I still/
<FromGitter>
<jrei:matrix.org> maybe U could support unions afterall
<FromGitter>
<jrei:matrix.org> *I could support
<FromGitter>
<jrei:matrix.org> but this is very not ideal, this means copying each readed byte in case of deserialization failure
<FromGitter>
<jrei:matrix.org> in your case, do each type in the union have the same byte lenght?