<FromGitter>
<Sija> I'm throwing the towel, my macro-fu ain't strong enough… time to sleep :P
<FromGitter>
<neutrinog> I have some inheritance happening in a project and I want certain methods to be "final" in the parent class. E.g. not overridable. Is there a crystal way to achieve this?
<FromGitter>
<Blacksmoke16> can use a macro, but nothing built in atm
<FromGitter>
<Sija> @r00ster91 yeah, but such exclusive approach would quickly get pretty verbose once you have more types
<FromGitter>
<Sija> forcing you to add more `unless X && unless Y`
<FromGitter>
<Sija> @dscottboggs_gitlab thing is that using `.is_a?` within `.find` doesn't mean shit for the compiler, it can only narrow down the type within `if/unless` branches
<FromGitter>
<Sija> and if you want to change `Array(X)` to `Array(X | Y)` you can't simply do `.as(Array(X | Y)`, instead you'd need to call `.map &.as(X | Y)` on the array itself
<FromGitter>
<dscottboggs_gitlab> yeah, the problem seems to be upcasting the Array to the union type before flitering it back out.
<FromGitter>
<dscottboggs_gitlab> @r00ster91 I seee that would work too
<FromGitter>
<dscottboggs_gitlab> @Sija ouch that would be quite the penalty hit.
<FromGitter>
<r00ster91> but if you want more types then I recommend Sija's https://carc.in/#/r/6a1j
<FromGitter>
<Sija> exactly
<FromGitter>
<dscottboggs_gitlab> the `#each` version is a simpler implementation anyway
<FromGitter>
<Sija> i'd avoid `.map` as long as it's possible
<FromGitter>
<Sija> for sure if you want to play with the type system :)
<FromGitter>
<dscottboggs_gitlab> I mean, it's not as bad as it looks on its face...map returns an iterator so the blocks are lazily handled
<FromGitter>
<Sija> yeah, but iterator is… expensive! ;)
<FromGitter>
<dscottboggs_gitlab> is it?
<FromGitter>
<Sija> like hell
<FromGitter>
<Sija> blocks are inlined, iterator is heap allocated
<FromGitter>
<dscottboggs_gitlab> I thought that was the most efficient way to do those sorts of calculations because you can perform more than one action at a time on each value
<FromGitter>
<Sija> well, as they say *IT depends* ;)
<FromGitter>
<dscottboggs_gitlab> hahaha of course
<oprypin>
@dscottboggs_gitlab, @sija, `[1, 2, 3] of (Int32 | String)`
<FromGitter>
<dscottboggs_gitlab> hm, yes that would work in that case
<oprypin>
but actually since im boycotting this syntax, `Array(Int32 | String){1, 2, 3}`
<FromGitter>
<dscottboggs_gitlab> lol
<FromGitter>
<dscottboggs_gitlab> fair enough
<FromGitter>
<Sija> @oprypin fair 'nuff, but that would only work when creating arrays
aither has joined #crystal-lang
<FromGitter>
<Sija> @r00ster91 oh, you're right! only some of them are, but still you have allocations vs inlined code
<Yxhuvud>
sija: well, anything implementing << and argumentless initialize, really.
Yxhuvud has quit [Quit: No Ping reply in 180 seconds.]
<FromGitter>
<Sija> @Yxhuvud: true but the thing is you can't use it say, within methods taking `Array` as an argument
<FromGitter>
<Sija> once you've done with initialization it's all over and you're back to `.map &.as(…)`
Yxhuvud has joined #crystal-lang
<FromGitter>
<Sija> and the case you've mentioned only applies to `T{1, 2, 3}` syntax, not `[1, 2, 3] of T`
<Yxhuvud>
well, I hardly ever uses the latter syntax. *shrug* (and I might have missed some comment due to that reconnect)
<FromGitter>
<Sija> I never use the former one… ;) btw, isn't `T{1, 2, 3}` more expensive than `[1, 2, 3] of T` (because of two-fold nature of it - calling `.new` + `#<<`)?
<Yxhuvud>
Eh, how do you think "[] of" work? I'd be very surprised if they didn't end up totally equal.
<FromGitter>
<Sija> well, it's a language keyword so it doesn't work the same
<FromGitter>
<Sija> whereas `T{}` syntax can be used by any class implementing `#<<`
ua has quit [Ping timeout: 250 seconds]
<Yxhuvud>
I was talking how I expected the generated code to look like, not compiler performance.
<FromGitter>
<Sija> and I *was* talking about the performance
<FromGitter>
<Sija> generated code would obviosly look different anyway
<Yxhuvud>
Why is that?
<FromGitter>
<Sija> because I see no reason for the compiler to use more expensive way, instead of directly initializing the class knowing the type beforehand
<FromGitter>
<Sija> prove me wrong ;)
<Yxhuvud>
I don't see why the compiler don't know the type beforehand in both cases.
<FromGitter>
<Sija> yeah, but the generic nature of `T{}` makes the difference in a way of initializing values taking away possibility of optimizations
<FromGitter>
<Sija> I mean it's possible, but IMHO quite unlikely it'll end-up with *exactly* the same generated code...
<FromGitter>
<j8r> i think Yxhuvud is right
<FromGitter>
<j8r> looks like the `of` syntax is no more than a syntactic sugar
<FromGitter>
<Sija> @j8r issue you've linked has nothing to do with the current topic, it's about the preference not the way the final code is generated
<FromGitter>
<j8r> Not really
<FromGitter>
<j8r> if there was performance considerations, i think it will be put in the issue at least
<FromGitter>
<j8r> but it totally about syntax preferences
ua has joined #crystal-lang
<FromGitter>
<Sija> @j8r we talk about the normalized code, not the syntax preferences so I don't follow what does it have to do with the topic...
<FromGitter>
<j8r> if there is performance hit, it better to mention it in the issue
<FromGitter>
<Sija> you can check the specs and you'll see the generated code is different in both cases, I don't know which version is more performant though...
fanta7531 has quit [Quit: fanta7531]
<FromGitter>
<Sija> but benchmarking it would be quite easy thing to do ;)
<FromGitter>
<j8r> the `{}` is slower
<FromGitter>
<j8r> looks like there is a missing optimization
<Yxhuvud>
Hmm. Seems you are right (though the difference will be neglible in practice). There is nothing stopping the compiler from looking at the type and specialize the generation for arrays though, even if it doesn't currently.
<FromGitter>
<Sija> that's what I thought, it's pretty obvious given generic nature of `T{}`… ;)
<FromGitter>
<j8r> maybe there is no initial capacity set?
<FromGitter>
<j8r> problem with of is we can use it with our custom types :(
<FromGitter>
<Sija> @j8r *it's not a bug, it's a feature* :)
<FromGitter>
<j8r> that's like with do with `Set`
<FromGitter>
<Sija> there are more types using it, `HTTP::Headers` for example
<FromGitter>
<j8r> yes i would say it :)
<FromGitter>
<j8r> Cookie IIRC
<FromGitter>
<j8r> only Hash and Array have `of`, for some reasons?
<FromGitter>
<Sija> IMHO it definately should stay the way it is, the only thing to be done is to apply optimizations to certain types, like e.g. `Array`
<FromGitter>
<Sija> reasons being that they're most common container types I guess
<FromGitter>
<j8r> multiple way to do the same hurts, really.
<FromGitter>
<Sija> being Chinese hurts too ;)
<FromGitter>
<j8r> ??
<FromGitter>
<Sija> I mean having only 1, sancioned way of doing things ;)
<FromGitter>
<Sija> in general I'd agree but let's not get into paranoia with it
<FromGitter>
<Sija> *moderation* is the key, so while avoiding pointless aliases I'd say is definately good, in some cases having more ways to do the same gives developer some flexibility, not necessarily for the worst
<FromGitter>
<j8r> only minor syntax sugar isn't a valid way, for me.
jemc has joined #crystal-lang
<FromGitter>
<j8r> adding a new way worth it if it's considerably shorter,and/ore more performant
sagax has quit [Ping timeout: 240 seconds]
<FromGitter>
<girng> > problem with of is we can use it with our custom types :( ⏎ ⏎ you can still use your own custom types without the of T syntax right
jemc has quit [Ping timeout: 246 seconds]
<FromGitter>
<Sija> @j8r that's mostly a matter of preference (and marginal performance difference), I see no problem with disagreeing ;)