<FromGitter>
<stronny> so about that. What if I have a `MyEnum.new(123)`?
return0e_ has joined #crystal-lang
return0e has quit [Ping timeout: 260 seconds]
alexherbo2 has joined #crystal-lang
<FromGitter>
<paulcsmith> This is probably simple, but I cannot figure it out. I'm trying to add a type restriction for a Proc and say the return type can be *anything* but I can't figure out a way to do it 🤔
<FromGitter>
<paulcsmith> So with the class I'm writing I want to pass multiple procs to it. Run each of them. But I don't care about the return value of the Proc. I want someone to pass whatever proc they want, run it, and that's it
<FromGitter>
<paulcsmith> Now I could do `-> { "hmm"; nil}` but that just looks super strange. I would expect to be able to set a return type of `Nil` and have the Proc always return nil, like it does with a method call
<FromGitter>
<paulcsmith> Yes, but that only works with one proc
<FromGitter>
<paulcsmith> Or is there a way to do that with multiple procs? My understanding was that syntax only works for one
<FromGitter>
<paulcsmith> As far as I can tell I do need an explicit type restriction. I can do it with `Proc(Nil)`, but I'd like to not have to return `nil` explicitly in each proc I pass it.
<FromGitter>
<stronny> there is a way to do it
<FromGitter>
<paulcsmith> Sorry I didn't explain that earlier. I was trying to keep it simple but probably left out too much info
<FromGitter>
<stronny> the question is why do you want it
<FromGitter>
<paulcsmith> I didn't want to go deep into why I want to do it, but if you really want to know I can explain
<FromGitter>
<paulcsmith> In Lucky you have class components for rendering html. I want to allow passing in procs to components so I can have a component that renders html in different slots. Return value does not matter. Will post example in a second
<FromGitter>
<paulcsmith> So in this case I want to create a resuable description list component and pass blocks for the different slots. This is a very powerful pattern I'd like to just not have to explicitly return `nil` in those passed in procs because it's weird 😬
<FromGitter>
<paulcsmith> So I really do want it, and I think it makes sense. However, if you have some others ideas, let me know :D
<FromGitter>
<paulcsmith> The key here is that the HTML methods write directly to a IO::Memory. So we don't need the return values as they are not used at all
<FromGitter>
<stronny> returning Nil is the best solution imo
<FromGitter>
<paulcsmith> 🤷♂️
<FromGitter>
<stronny> the problem here is that Proc is a template
<FromGitter>
<stronny> you won't be able to store `Proc` anyway
<FromGitter>
<stronny> you'll have to store `Proc(*T, R)`
<FromGitter>
<stronny> better to get comfortable earlier than later
<FromGitter>
<paulcsmith> Or modify the lang to do this. `Proc(Nil)` could be a special case to ignore return type. Just like with a method return type set to `Nil` does not retquire returning nil
<FromGitter>
<stronny> modify how?
<FromGitter>
<Blacksmoke16> It used to do that
<FromGitter>
<paulcsmith> That is a really nice feature when you don't want people to use the return value of a method
<FromGitter>
<paulcsmith> @stronny I do not know, but I assume it is possible
<FromGitter>
<paulcsmith> @Blacksmoke16 Oh that's interesting. That's what I thought actually so I was surpised when it didn't work
<FromGitter>
<stronny> there are conflicting interests here
<FromGitter>
<paulcsmith> Could you explain? I don't get how wanting someone to explicitly return `nil` is helpful. Not sure i understand the use case
<FromGitter>
<paulcsmith> The method return type precedent comes to mind. You don't need to retun `nil` for it to work
<FromGitter>
<paulcsmith> I'll also check the GitHub issues to try to find some context
<FromGitter>
<stronny> there is one method definition right in front of its body
<FromGitter>
<stronny> with procs you have several defs all around the code and the actual block somewhere else
<FromGitter>
<paulcsmith> So I think it is still desirable to have a Proc with Nil return type. It just needs to not break other stuff :)
<FromGitter>
<paulcsmith> Maybe I'll try resurrecting that issue and offer a bug bounty. Would really love to be able to do this and not mess up the other stuff
<FromGitter>
<paulcsmith> Thanks for the info @Blacksmoke16. Very helpful to know it was reverted and why
<FromGitter>
<Blacksmoke16> it wasnt reverted :p
<FromGitter>
<Blacksmoke16> hence why the issue i created is still open
<FromGitter>
<stronny> no but seriously what do you want to happen here? I have a block { 123 } that I should be able to put into Proc(Int32) and into Proc(Nil) both?
<FromGitter>
<paulcsmith> @stronny Yes exactly
<FromGitter>
<paulcsmith> Just liek with a method definition with return type of Nil
<FromGitter>
<paulcsmith> There is precedent here and I gave an example of how it is useful a few times
<FromGitter>
<stronny> what do you mean "just like"?
<FromGitter>
<paulcsmith> Same memory address. Nil restriction causes it to return nil
<FromGitter>
<stronny> these are two different methods with two different bodies
<FromGitter>
<stronny> notice you have to copy and paste your source
<FromGitter>
<paulcsmith> It is just an example
<FromGitter>
<stronny> with macros copy-paste would be done by compiler
<FromGitter>
<paulcsmith> The point being you can restrict return type to nil and it'll return nil
<FromGitter>
<stronny> with Proc you have a function pointer
<FromGitter>
<stronny> a pointer without an attached type information
<FromGitter>
<paulcsmith> Ok look I don't really care what the Proc is. I just want to ignore the return type of it if the type restriction is `Nil` 🤷♂️
<FromGitter>
<stronny> do you not see the difference?
<FromGitter>
<paulcsmith> I'm sure this is possible
<FromGitter>
<stronny> I'm also sure it's possible
<FromGitter>
<paulcsmith> Yes I see the difference I just don't care
<FromGitter>
<stronny> I just don't think it's beneficial
<FromGitter>
<paulcsmith> Ok, and I do.
<FromGitter>
<stronny> well good luck
<FromGitter>
<paulcsmith> We have difference of opinions but you can't convince me that my opinion is "wrong"
<FromGitter>
<stronny> I have no such intention
<FromGitter>
<paulcsmith> Ok then I think we can drop it. I want to be able to do it. If Crystal team doesn't add that, then that is ok :)
<FromGitter>
<paulcsmith> I get that Procs are different. I just don't want to return an explicit `nil`. That's all it comes down to 🤷♂️
<FromGitter>
<stronny> do you need the Procs at all?
<FromGitter>
<stronny> maybe try doing that with methods?
<FromGitter>
<paulcsmith> Where I have a generic component that accepts blocks so you can customize the different "slots" in the HTML
<FromGitter>
<stronny> macros
<FromGitter>
<Blacksmoke16> are all the procs of the same type?
<FromGitter>
<stronny> no
<FromGitter>
<Blacksmoke16> i.e. `Proc(Nil)`/
<FromGitter>
<paulcsmith> @Blacksmoke16 No they are `Proc(Nil)` or `Proc(IO::Memory)`
<FromGitter>
<paulcsmith> So I could do `Proc(Nil, IO::Memory)` but there could potentially be more return types.
<FromGitter>
<Blacksmoke16> gotcha
<FromGitter>
<paulcsmith> This is mostly an optimization to make it nicer. This is definitely not a blocker by any means. Just a nice thing I'd like :P
<FromGitter>
<paulcsmith> Would rather avoid macros if it can be domne with functions. Much easier to reason about and debug IMO
<FromGitter>
<stronny> my opinion that blocks and procs aren't well suited for usecases like yours
<FromGitter>
<stronny> I would do that with macros
<FromGitter>
<paulcsmith> How would you do it with macros?
<FromGitter>
<paulcsmith> Curious what your solution would be. I tend to avoid macros if can be down with regular lang constructs since it is easier to reason about and debug
<FromGitter>
<paulcsmith> Not sure how this would work with a macro actually 🤔
<FromGitter>
<stronny> no, both are hard to reason about, just the levels of complexity are different
<FromGitter>
<stronny> can't give you a working prototype atm
<FromGitter>
<stronny> kinda busy sorry
<FromGitter>
<paulcsmith> No prob
<FromGitter>
<paulcsmith> I think the functions are quite simple. You pass it in. The component calls them 🤷♂️ but maybe just me 🤣
<FromGitter>
<paulcsmith> Anyway, I'll open an issue or leave a comment on the Proc thing. I still would like to be able to do this and think it's a great solution
<FromGitter>
<paulcsmith> Ok this is interesting https://play.crystal-lang.org/#/r/8s9v works...which seems like what I want to do. The Proc returns an Int32, but since return type is Nil it just returns nil
<FromGitter>
<paulcsmith> So it seems like mine should work too but it doesn't...will have to play around with this a bit haha. Because that seems like what I'm doing
<FromGitter>
<Blacksmoke16> right, just be aware of the bug
<FromGitter>
<Blacksmoke16> only is when the procs are in an array i think tho
DTZUZU has joined #crystal-lang
<FromGitter>
<paulcsmith> Ahhh this fails! Looks like something to do with setting the type restriction in the initializer *or* with setting the proc in the argument https://play.crystal-lang.org/#/r/8s9x
<FromGitter>
<paulcsmith> @Blacksmoke16 Yes thanks for reminding me! I'm thinking since I'll use these for just Nil return type and no array it should be ok 🤞
<FromGitter>
<paulcsmith> But I will keep that in mind for other stuff since I may run into that
<FromGitter>
<stronny> idk, looks very fragile
<FromGitter>
<paulcsmith> What looks fragile?
<FromGitter>
<paulcsmith> The macro?
DTZUZU2 has quit [Ping timeout: 265 seconds]
<FromGitter>
<stronny> no, getter proc : Proc(Nil) trick
<FromGitter>
<paulcsmith> It is not a trick. It is how it is supposed to work
<FromGitter>
<paulcsmith> Yes...as a fix for the issue @Blacksmoke16 mentioned
<FromGitter>
<paulcsmith> With the intention to still add it back
<FromGitter>
<stronny> let me quote
<FromGitter>
<paulcsmith> > The following code is invalid in 0.27.2 but valid in 0.28.0 and we want to keep it that way.
<FromGitter>
<stronny> > Hmm... it's a bit hard. I feel like I'm constantly monkey patching the type system to make things work. For now I'll stop touching the compiler.
<FromGitter>
<paulcsmith> Doesn't mean it shouldn't work
<FromGitter>
<paulcsmith> Can we please just drop this?
<FromGitter>
<stronny> sure
Tungki has joined #crystal-lang
DTZUZU has quit [Ping timeout: 250 seconds]
DTZUZU has joined #crystal-lang
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #crystal-lang
<FromGitter>
<tenebrousedge> Oh cripes
<FromGitter>
<tenebrousedge> Crystal is pretty much Ruby++, isn't it?
return0e has quit [Read error: Connection reset by peer]
return0e has joined #crystal-lang
<FromGitter>
<stronny> I don't think so
<FromGitter>
<dscottboggs_gitlab> no not at all
<FromGitter>
<dscottboggs_gitlab> TBH I feel like comparing ruby to crystal doesn't make a ton of sense beyond the syntax style (not even the syntax itself)
<FromGitter>
<tenebrousedge> the stdlib is pretty similar, in addition to most of the syntax
<FromGitter>
<stronny> similar yes
<FromGitter>
<tenebrousedge> not comparing the two would seem to be an overreaction
<FromGitter>
<dscottboggs_gitlab> idk I mean C++ is still C, just with a bunch extra. The way your code runs in Crystal is completely different
<FromGitter>
<dscottboggs_gitlab> I used to think that crystal was a hard fork of ruby
<FromGitter>
<tenebrousedge> oh, that is certainly not the case
<FromGitter>
<tenebrousedge> But implementation aside, Crystal could be described as, "Ruby, plus a type system, plus other sensible changes", omitting certain divergences
<FromGitter>
<tenebrousedge> personally I was deeply disappointed by the Ruby devs' response to the `&.` proposal
<FromGitter>
<asterite> I think they rejected it because Ruby doesn't have syntax sugar
<FromGitter>
<stronny> could you share a link? I think I've missed the drama
<FromGitter>
<phykos> how do I remove a folder & it's content?
<FromGitter>
<j8r> @phykos `FileUtils.rm_r`
alexherbo2 has quit [Ping timeout: 265 seconds]
<oprypin>
*best* function name ever
<FromGitter>
<tenebrousedge> Ruby doesn't have syntactic sugar, except when it does >_< like the new positional block arguments
<FromGitter>
<j8r> oprypin agree, I remember having opened an issue about this module
<oprypin>
tenebrousedge, wow that's painful to read
<FromGitter>
<stronny> well that's ironic given that &. exists now with a different meaning
<FromGitter>
<andrewc910> Hey guys, there are a couple shards i would like to make some PR's for. However, these shards utilize several techniques i am not too familiar with. I figured i should understand them better before even attempting to comprehend the code bases. I was hoping someone here can point me at some resources. ⏎ ⏎ The major topics i have identified are: ⏎ Enums, Struts, Macros & Generics ⏎ ...
<oprypin>
andrewc910, i mean,... you even have a goal in mind, perfect for learning by doing
<oprypin>
can't you see the context that the libraries use them in?
<FromGitter>
<andrewc910> @oprypin Agreed but the code bases are at a level that makes comprehension almost impossible especially without proper debugging tools :/ ⏎ ⏎ Here is an example: https://github.com/imdrasil/jennifer.cr/blob/master/src/jennifer/query_builder/query.cr ⏎ ⏎ I can read the symbols, i can understand which variables are initialized, which classes are instantiated but some of those marcos i can't
<FromGitter>
<Blacksmoke16> would it make sense for the 2nd range `.end` to be 9?
<FromGitter>
<Blacksmoke16> since it doesnt include the ending value due to `...`
<FromGitter>
<stronny> idk, do you want 1..10 be == 1...11 ?
<FromGitter>
<jwoertink> Anyone here running on a linux machine that can run `echo $OSTYPE` and let me know what it returns for you? Or windows linux subsystem
<FromGitter>
<stronny> I think these are distinct with different qualities
<FromGitter>
<Blacksmoke16> well `1...10` is essentially the same as `1..9` no?
<FromGitter>
<andrewc910> Okay, so i can download a lib, add whatever debug statements, use that version in my demo app to help me understand macro sections. Is that the best way or do you recommend something else?
<FromGitter>
<Blacksmoke16> that would show you what code ends up going into the program yes
<FromGitter>
<andrewc910> Rereading the entire macro section today, will make sure to spend some time on that link :)