postmodern has quit [Read error: Connection reset by peer]
ur5us has quit [Ping timeout: 240 seconds]
ur5us has joined #crystal-lang
ur5us has quit [Ping timeout: 240 seconds]
ur5us has joined #crystal-lang
ur5us has quit [Ping timeout: 240 seconds]
jhass[m] has quit [Quit: Bridge terminating on SIGTERM]
fifr[m] has quit [Quit: Bridge terminating on SIGTERM]
jhass[m] has joined #crystal-lang
fifr[m] has joined #crystal-lang
walden has joined #crystal-lang
walden has quit [Ping timeout: 246 seconds]
walden has joined #crystal-lang
walden has quit [Ping timeout: 246 seconds]
<FromGitter>
<ewalden:matrix.org> Hello everyone, I am fairly experienced with Ruby and just getting started with Crystal. I love the experience! But I have a question about the approach. I am porting an existing Ruby app to Crystal, and in the original app, we use hashes to pass an arbitrary number of params. ⏎ ⏎ For example, the original Ruby it looks like this: ⏎ ⏎ ```code paste, see link``` ...
<FromGitter>
<Blacksmoke16> using `**kwargs` would allow you to do like `Obj.new has_x: true, y: 10`
<FromGitter>
<Blacksmoke16> are these opts used in multiple types or just one?
<FromGitter>
<Blacksmoke16> i guess i never got the benefit of using a hash/arbitrary args for this. Like the first example only uses 2, so why not just have `def initialize(has_x : Bool, y : Int32)`
<FromGitter>
<tenebrousedge> having multiple overloads probably is a way to avoid that sort of thing, too
<FromGitter>
<ewalden:matrix.org> My issue with **kwargs was that it uses a NameTuple, which require the types to the same. It's actually quite a bit of data of different types. ⏎ ⏎ I considered `def initialize(@has_x : Bool, @y : Int32)` approach, but that would change the method signature by a lot, add a lot of paramters, and require a lot more rewriting. But now that I think it over, this may be simplest in the long term.
<FromGitter>
<tenebrousedge> structs could be a thing, too
<FromGitter>
<Blacksmoke16> yes, just bite the bullet and make your initializers how they should be, you may have to un-learn some stuff from Ruby 😉
<FromGitter>
<tenebrousedge> going from Crystal to Ruby, I really miss being able to assign instance vars in the signature
<FromGitter>
<ewalden:matrix.org> Yeah, I think that's the lesson here. Time to let go the unlearn the Ruby way. So my take away: for lots of params: Using structs and/or listing out all the params are reasonable approaches. Thanks ya'll.
<FromGitter>
<Blacksmoke16> if a type has a lot of params, is it possible to break it up?
<FromGitter>
<ewalden:matrix.org> Which type? You mean method?
<FromGitter>
<Blacksmoke16> like instead of having 1 type with a bunch of instance variables, could you break it up into other types, kinda like what you were doing with the struct just as a way to better group related ivars
<FromGitter>
<Blacksmoke16> granted i know 0 of your context so maybe that doesn't make sense :shrug:
<FromGitter>
<ewalden:matrix.org> ☝️ Edit (https://gitter.im/crystal-lang/crystal?at=611e5c079484630efa47ed35): Hello everyone, I am fairly experienced with Ruby and just getting started with Crystal. I love the experience! But I have a question about the approach. I am porting an existing Ruby app to Crystal, and in the original app, we use hashes to pass an arbitrary number of params. ⏎ ⏎ For example, the original Ruby it
<FromGitter>
<ewalden:matrix.org> ☝️ Edit (https://gitter.im/crystal-lang/crystal?at=611e5c079484630efa47ed35): Hello everyone, I am fairly experienced with Ruby and just getting started with Crystal. I love the experience! But I have a question about the approach. I am porting an existing Ruby app to Crystal, and in the original app, we use hashes to pass an arbitrary number of params. ⏎ ⏎ For example, the original Ruby it
<FromGitter>
<ewalden:matrix.org> ☝️ Edit (https://gitter.im/crystal-lang/crystal?at=611e5c079484630efa47ed35): Hello everyone, I am fairly experienced with Ruby and just getting started with Crystal. I love the experience! But I have a question about the approach. I am porting an existing Ruby app to Crystal, and in the original app, we use hashes to pass an arbitrary number of params. ⏎ ⏎ For example, the original Ruby it
<FromGitter>
<ewalden:matrix.org> Ah, yes. It's a complicated code base, so I will probably be taking different approaches for different situations.
<FromGitter>
<Blacksmoke16> oof, i like how editing it re-pastes the whole message? 🤔
<riza>
probably because matrix/gitter/irc/one-bridge-to-rule-them-all
<FromGitter>
<ewalden:matrix.org> Are you referring to my edits? Did they trigger re-posts? 😬
<riza>
yeah :[
Starfoxxes has quit [*.net *.split]
cfebs has quit [*.net *.split]
jrayhawk has quit [*.net *.split]
jrayhawk has joined #crystal-lang
Starfoxxes has joined #crystal-lang
cfebs has joined #crystal-lang
<FromGitter>
<oprypin:matrix.org> ewalden (https://matrix.to/#/@ewalden:matrix.org): @Blacksmoke16 : think gitter disallows editing after an hour or something, but matrix doesnt disallow, and in that case needs to duplicate
<FromGitter>
<oprypin:matrix.org> anyway, please dont do edits at all because in IRC they aren't shown
SamantazFox has quit [Ping timeout: 268 seconds]
SamantazFox has joined #crystal-lang
ur5us has joined #crystal-lang
ur5us has quit [Ping timeout: 240 seconds]
ur5us has joined #crystal-lang
hightower2 has joined #crystal-lang
<hightower2>
Hey, a file-hierarchy question... let's say I have a common/base class named Widget in src/widget.cr, and then various actual widgets in a subdir src/widget/<name>.cr. Now, the base class (file widget.cr) is large and I want to split it into individual files. What's a good way to do that?
<FromGitter>
<Blacksmoke16> is it really worth it to split it up?
<FromGitter>
<Blacksmoke16> just would make finding things harder imo
<hightower2>
well it's 3.3k lines... and I did split it into multiple modules within that one file so it is already "grouped" in a way, but somehow I think individual files would be more manageable.
<FromGitter>
<tenebrousedge> do you use any of those modules anywhere else?
<FromGitter>
<Blacksmoke16> oh well if they're already in their own modules, id just have a file for each module
<hightower2>
tenebrousedge these ones I don't, they are specific to that class. (For others that are shared modules, they're in appropriate places)
<FromGitter>
<tenebrousedge> I mean if you have a bunch of modules you only use with one class, why are they modules?
<hightower2>
because I originally already had them in separate files, which I organized as modules... and then after I joined everything in a single file, I still kept it separated into modules so that large groups of separate functionality would still somehow be separated, rather than just lumped together
<FromGitter>
<Blacksmoke16> to be fair modules are also used as a means of namespacing stuff
<FromGitter>
<Blacksmoke16> doesn't mean they'll ever be included/extended in something else
<hightower2>
right, sure.
<hightower2>
well, yes, those modules or not, it doesn't matter... I could have just closed/reopened the class multiple times as a form of delimiter. Modules just seemed convenient because it allowed me to group and assign a name(space) to a group.
<hightower2>
My question is if you had such a case where there would be a naming/placement conflict between files which are part of base class and its subclasses, where would you put the files to avoid it?
<FromGitter>
<Blacksmoke16> going to need to the require the extra files somewhere
<FromGitter>
<Blacksmoke16> id just put them next to the main widget.cr file and require them in there
<hightower2>
like widget-stuff1.cr, widget-stuff2.cr etc.?
<FromGitter>
<Blacksmoke16> seems fine
<FromGitter>
<Blacksmoke16> think convention is to use `_` tho
<hightower2>
Another idea I had was to possibly use the widget/ subdir for both, but the files which are actually part of base class and never need to be referenced individually (except for 'require' of course) would be prefixed with _.
<hightower2>
Something like:
<hightower2>
ls -al widget/ --> _stuff1.cr, _stuff2.cr, widget1.cr, widget2.cr
<FromGitter>
<Blacksmoke16> meh
<hightower2>
Ok, will think a little bit more. The reason why I don't particularly like that first idea of widget_part1.cr, widget_part2.cr, is that I have such a case (large file split into groups of functionality) in 2 places. And in the other place that class doesn't have subclasses, so I indeed used its subdir/ to place parts of the base class there.
<hightower2>
thanks for the discussion as always
<FromGitter>
<Blacksmoke16> dont think it really matters too much
<FromGitter>
<Blacksmoke16> more so whatever organizational setup you want to use
<hightower2>
right, sure, I just wanted something intuitive and it seemed intuitiveness wasn't great in this case, so wanted to check for potential similar cases
<hightower2>
will probably keep it as a single file for now