<postmodern>
but it doesn't look like you can specify the type your block wishes to receive?
<FromGitter>
<Blacksmoke16> You can, but I don't know if that would work
chachasmooth has quit [Ping timeout: 240 seconds]
<FromGitter>
<Blacksmoke16> Is like `& : String -> Int32`
<FromGitter>
<Blacksmoke16> Block yields a string and returns an int32
<postmodern>
but what if i have two methods both with the same name, but their &block signatures are different
<postmodern>
could i do something lke foo { |x : Int32| ... } vs. foo { |x : Char| ... } to denote which overloaded method i was wanting to call
<FromGitter>
<Blacksmoke16> No
chachasmooth has joined #crystal-lang
chachasmooth has quit [Ping timeout: 260 seconds]
<postmodern>
i noticed that when you write a case/when state for _every_ element in an enum, the compiler still assumes the case/when may return a Nil despite being 1:1 wiith the enum values
<postmodern>
is that by design or a current limitation of the compiler?
chachasmooth has joined #crystal-lang
<FromGitter>
<Blacksmoke16> Use in instead of when
<FromGitter>
<Blacksmoke16> In signifies it should be exhaustive
<postmodern>
arg trying to find the documentation on case in
<FromGitter>
<Blacksmoke16> The book probably needs updated
<postmodern>
ah s/when/in/ worked. yeah couldn't find it in the book
<postmodern>
hmm does #to_s not get called on structs when embedding them into strings via #{}?
<FromGitter>
<Blacksmoke16> It should, got an example?
<FromGitter>
<naqvis> but I won't recommend such usages, as it defies the purpose. Better to put consideration on design, as `struct` or `class` might not be right mechanism for your use-case
zorp has quit [Ping timeout: 246 seconds]
f1reflyylmao has quit [Ping timeout: 272 seconds]
f1refly has joined #crystal-lang
oddp has joined #crystal-lang
alexherbo2 has joined #crystal-lang
<FromGitter>
<benphelps> why would the logic here not be the same? ⏎ ```if (left.is_a?(PheltObject::Integer | PheltObject::Float)) && (right.is_a?(PheltObject::Integer | PheltObject::Float))``` ⏎ ```if (left.is_a?(PheltObject::Integer) || left.is_a?(PheltObject::Float)) && (right.is_a?(PheltObject::Integer) || right.is_a?(PheltObject::Float))```
<FromGitter>
<benphelps> the second example works as expected, but the first, using a union type, doesn't work
<FromGitter>
<benphelps> it's generalizing the union type more than it should? ⏎ ```(PheltObject::Integer | PheltObject::Float) = PheltObject::Object```
<FromGitter>
<benphelps> can I have a union of two types that isn't just the parent type?
<oprypin>
@benphelps: i think is_a union doesn't work like that, even in terms of the Boolean that it will return to you. check it. deduction is affected secondarily
<FromGitter>
<benphelps> well, I have an alias type called PheltObject::Number that is Float and Integer together, and it gets generalized to the parent type
<FromGitter>
<benphelps> even though I have more than just Float and Integer types
<FromGitter>
<benphelps> and the parent is just an abstract class to force method implementation
<FromGitter>
<benphelps> i could remove the abstract class inheritance and I'm sure it'd fix my problem, but it seems like that should be a thing to me
<FromGitter>
<benphelps> im not sure why it gets generalized to the parent when the parent has children of more than just those two types
<FromGitter>
<benphelps> if it was inclusive of all types that'd make sense, but it's not
<FromGitter>
<benphelps> all children types
<FromGitter>
<asterite> it generalizes to the parent because that's how it works. It's also documented in the virtual types section. But when you use is_a with unions something funky happens, probably a bug or I wanted to be smarter and avoid going to the parent type some times
<FromGitter>
<benphelps> is there not a cleaner way to check if something is a union of a set of children types and not of the complete set ?
<FromGitter>
<benphelps> it basically makes unions of a type with children useless
<FromGitter>
<benphelps> the compiler should warn you I feel if it's always going to be all children because it makes the code misleading
<FromGitter>
<asterite> yes, do a case using each type, and duplicate code for each case
<FromGitter>
<asterite> you can report a bug around that, I don't think anyone did it yet
<FromGitter>
<benphelps> im not even sure I understand the problem well enough to make a report
<FromGitter>
<benphelps> it's mostly me just not understanding the type system fully yet
<FromGitter>
<asterite> it's a bug, not a feature of the tye system. Or a wrong feature that must be undone. Or an error reported
<FromGitter>
<benphelps> oh, so it shouldn't generalize all the way up?
<FromGitter>
<benphelps> that's documented, the is_a? of a union shouldn't though
<FromGitter>
<benphelps> it works fine, i dont understand
<FromGitter>
<asterite> that's the thing. Someone wanted that to not generalize and it does and doesn't, there's a bug around that if I remember correctly
<FromGitter>
<benphelps> if you alias a union, it gets generalized, if you don't it doesn't
<FromGitter>
<benphelps> so it has to do with alias unions
<FromGitter>
<benphelps> if you agree that's not expected, I can make a bug on that example
<FromGitter>
<benphelps> and according to the docs, alias works like a macro and should just replace the alias where it's used, but that's not the case here
<FromGitter>
<j8r> Glad I finished [de]serializing crystal objects from/to bytes
<FromGitter>
<j8r> At my surprise, I don't see any JS library to do the same?
<FromGitter>
<Blacksmoke16> :shrug:
alexherbo2 has quit [Ping timeout: 260 seconds]
alexherbo2 has joined #crystal-lang
<FromGitter>
<ImAHopelessDev_gitlab> It's ENUM TIME again baby!
<FromGitter>
<ImAHopelessDev_gitlab> i ought to really stop using "action == 0" or "action == 1" etc. i don't know why, but i always do that. i guess it's because i never really used enums in javascript and php back in the day? lol
<FromGitter>
<Blacksmoke16> yes you should
alexherbo2 has quit [Ping timeout: 265 seconds]
<FromGitter>
<j8r> I just read ought vs should
<FromGitter>
<j8r> Very close a the end, ought has slightly obligations, a bit closer to "must"
<FromGitter>
<j8r> But then, "really should" vs "ought"... 😅 I will likely not use ought
<FromGitter>
<j8r> this removed the inconvenience, which can be error-prone, to pass the correct context around
<FromGitter>
<j8r> it is automatically done in the above example
<Jenz>
I should have showed a more complete example of my situation initially. The complicating factor I guess is that there are many different kinds of `Bar`s, as here: https://play.crystal-lang.org/#/r/9ic6, using j8rs nice solution; working just as I want it
<Jenz>
Essentially, with an abstract Barish class. Pardon my clumsiness
oddp has quit [Ping timeout: 256 seconds]
oddp has joined #crystal-lang
<FromGitter>
<Blacksmoke16> if you change `a` in `SomeBar`, would you expect it to also be changed within `OtherBar`?
<Jenz>
Definitely
<Jenz>
As it would with this solution
<Jenz>
Either way, I wouldn't use either SomeBar nor OtherBar outside of Foo.bar; that is, I discard of them whenever I change between Some- and OtherBar
<FromGitter>
<Blacksmoke16> i see
<Jenz>
My clumsiness may be excused, though about my terrible english I can only beg forgiveness D:
<Jenz>
Whenever I turn melodramatic, I take that as a sure sign I need sleep. Good night!
Jenz has quit [Quit: leaving]
<FromGitter>
<mwlang> I'm upgrading an app from Crystal 0.29.0 to 0.35.0. `IO::Timeout` seems to have gone away. As well as `Time.now` Is that truly the case?
<FromGitter>
<Blacksmoke16> Time.local or Time.utc
<FromGitter>
<mwlang> Which one more closely reflects the old Time.now?
<FromGitter>
<Blacksmoke16> Local iirc
<FromGitter>
<mwlang> 👍
<FromGitter>
<Blacksmoke16> `IO::Timeout` is now `IO::TimeoutError`
<FromGitter>
<mwlang> Ah! ok, looks like cossack shard has fallen behind the times.
<FromGitter>
<Blacksmoke16> probably
<FromGitter>
<mwlang> are crystal-community/<shard> maintained by those working actively on crystal language or are they indeed just various folks in the community?
<FromGitter>
<mwlang> There's a pull request to fix the IO::Timeout reference but it's been open for a while with no activity
<FromGitter>
<Blacksmoke16> its various people in the community afaik
<FromGitter>
<mwlang> `expect_raises` with no arguments also dropped? If so, what's the common fix for this?
<FromGitter>
<Blacksmoke16> i didnt know there was an argless version
<FromGitter>
<Blacksmoke16> prob just `expect_raises Exception`
<FromGitter>
<Blacksmoke16> ah, apparently there was prior to `0.24.0`
<FromGitter>
<mwlang> yeah, the docs I saw as 0.19.0. Kind of gone down a rabbit hole. Trying to fix various dependencies I'm using. cossack needs spec2 and I'm fixing the spec2 shard at the moment
<FromGitter>
<Blacksmoke16> not better to just switch it to stdlib
<FromGitter>
<Blacksmoke16> is the downside of these testing frameworks imo
<FromGitter>
<mwlang> you may be right!
<FromGitter>
<mwlang> I didn't quite expect the rabbit hole, to be honest. A lot's changed in 8 months since I was last fiddling with Crystal
<FromGitter>
<mwlang> well, small, but core things.
<FromGitter>
<Blacksmoke16> well to be fair, idk what was using the argless `expect_raises`, but that hasnt been a thing in like 3 years :P