<FromGitter>
<mjfiano:matrix.org> Is there a shorthand form for when you have the same type restriction for adjacent parameters, to make something like `(a : Float64, b : Float64, c : Float64, d : Float64)` more concise?
<FromGitter>
<oprypin:matrix.org> mfiano (https://matrix.to/#/@mjfiano:matrix.org): no
<FromGitter>
<naqvis> oops, that was not your question :)
<raz>
hmm right, but close :)
<raz>
i guess what i'm really trying to ask: is there a way to add something to the constructors that `JSON::Serializable` generates (short of making a custom converter for every field 🙈)
<raz>
i have this really nice and rather relevant logic in my settings, but serializable doesn't care to invoke them when populating the object from json :,(
<raz>
s/settings/setters/
<FromGitter>
<naqvis> macro populate the fields, it would have been better if it would have invoked setters (if any) and fall-back to current behavior
<FromGitter>
<naqvis> in that way, one could just define the setters for fields which require some extra processing
<FromGitter>
<naqvis> for the time-being what you can do is override `after_initialize` and invoke your setters there, this method is invoked after macro is done with populating the fields
<raz>
well, that's amazingly useful for being so underdocumented! :D
<FromGitter>
<Blacksmoke16> there's also one that runs after you do `to_json`
<raz>
pffft, who needs that
elf_fortrez has joined #crystal-lang
elf_fortrez has quit [Quit: Client closed]
<FromGitter>
<ashishbista> Is it possible to run a spec file with the interactive mode enabled? ⏎ I want to put the debugger in a spec file and then execute the spec file.
<FromGitter>
<Blacksmoke16> > By the way, before this PR you could also use debugger and lldb or gdb would stop at that point, if compiled with -d (otherwise it seems the program just crashes, maybe we should just ignore debugger in that case: something to improve outside of this PR) ⏎ ⏎ Sounds like that wont be supported for the moment
<FromGitter>
<Blacksmoke16> or that is an issue not related to this PR, nvm
<FromGitter>
<Blacksmoke16> you can run a spec file like you would a normal file, prob best you're going to get for a while
jacotsu has joined #crystal-lang
jacotsu has quit [Quit: leaving]
jacotsu has joined #crystal-lang
jacotsu has quit [Quit: leaving]
jacotsu has joined #crystal-lang
jacotsu has quit [Client Quit]
<FromGitter>
<manveru:matrix.org> btw, is there any emacs mode out there that actually works with macro syntax?
jacotsu has joined #crystal-lang
jacotsu has quit [Client Quit]
jacotsu has joined #crystal-lang
<jacotsu>
Quick question, does the compiler support only these target triples "i686-unknown-linux-gnu", ""amd64-unknown-openbsd"", "amd64-unknown-openbsd"; or there's a way to compile for another arch without modifying the compiler (talking about armv7)?
<FromGitter>
<mjfiano:matrix.org> Am I correct in thinking that the only difference between `include` and `extend` is mixing in instance or class methods?
<FromGitter>
<Blacksmoke16> pretty much yea, `include` adds the modules instance methods as instance methods in the including type, while `extend` adds the module's instance methods as class methods in the extending type
<FromGitter>
<Blacksmoke16> iirc they're also slightly different in regards to typing
<FromGitter>
<Blacksmoke16> like if you include `MyModule` into `Foo`, `Foo.new.is_a? MyModule # => true`, but if you extend the module it affects the type of `Foo.class` not the actual instance type
<FromGitter>
<mjfiano:matrix.org> and this behaves like composition over inheritance, which is what I suppose they docs mean by partial types, right?
<FromGitter>
<mjfiano:matrix.org> Like mixins in some other languages/paradigms
<FromGitter>
<Blacksmoke16> yes exactly
<FromGitter>
<mjfiano:matrix.org> Great thanks
<FromGitter>
<Blacksmoke16> they're also great as a means of having interfaces
<FromGitter>
<Blacksmoke16> as you can define abstract methods on the module that the including type would be required to implement them
<FromGitter>
<ashishbista> > you can run a spec file like you would a normal file ⏎ I didn't know this. It would solve my issue. Thank you!
<FromGitter>
<mjfiano:matrix.org> I've been trying to think how to structure my module hierarchy correctly for a couple hours. I'm not used to this way of programming apparently.
<FromGitter>
<Blacksmoke16> oh?
<FromGitter>
<mjfiano:matrix.org> I have a few different structs, each in their own file under `src/myproject/`, and in a `MyProject` module. In `src/myproject.cr` I basically just do `require "./src/myproject/*`. Now I would like to add a "common.cr" file with common functionality between all the structs, implementing mostly class methods, and also available to users of the library. I can't seem to figure out how to get that to work.
<FromGitter>
<Blacksmoke16> is the logic common to *all* the structs or only some of them?
<FromGitter>
<mjfiano:matrix.org> Well, one such common method would be that `nearly_equal?(x, y, rel_tol, abs_tol)` method I wrote yesterday. This would be used in the implementation of several of each of the structs' instance methods.
<FromGitter>
<Blacksmoke16> put it in a parent abstract struct?
<FromGitter>
<mjfiano:matrix.org> I could look into that. I also want some of these methods to be public facing.
<FromGitter>
<mjfiano:matrix.org> If that will work
<FromGitter>
<Blacksmoke16> a public method declared in a parent type is available in all its children
<FromGitter>
<Blacksmoke16> a module/mixin is mainly ideal for like extra code that could be useful for any type. E.g. like the stdlib's Comparable, or Enumerable modules
<FromGitter>
<Blacksmoke16> but if something is common to multiple things, just define that once and use inheritance
<FromGitter>
<mjfiano:matrix.org> Right, I just have to look up abstract types in Crystal again. I'm used to all of their methods also being abstract.
<FromGitter>
<mjfiano:matrix.org> Thanks. I'll re-read that again. Your suggestion above also really clicked for me.
<FromGitter>
<Blacksmoke16> and im assuming you actually want structs. I.e. are they immutable?
<FromGitter>
<Blacksmoke16> one gotcha is you cant inherit a non abstract struct, which might require some redesign if you wanted to have a base struct that was also usable on its own
<FromGitter>
<mjfiano:matrix.org> That is something I'm still deciding on. I'm not sure if I want to allocate new stack memory or just use heap-allocated objects/mutability yet.
<FromGitter>
<mjfiano:matrix.org> I will have to see how it is to be used and benchmark some I suppose. For now, they are structs though. I expect the change to class to be easy later if need be.
<FromGitter>
<Blacksmoke16> 👍
<FromGitter>
<mjfiano:matrix.org> I'm having a ton of fun learning, albeit slow, thanks for your help :)
<FromGitter>
<Blacksmoke16> np
<FromGitter>
<Blacksmoke16> is there a better way to create read addition bytes into a larger Bytes slice other than doing like: ⏎ ⏎ ``` bytes = Bytes.new 4 ⏎ io.pos -= 3 ⏎ io.read_fully bytes``` ⏎ ⏎ where the original bytes slice was 3 [https://gitter.im/crystal-lang/crystal?at=60f3204217929c14e691c598]
<FromGitter>
<mjfiano:matrix.org> Do the property/getter/setter macros inline the generated method defs?
<FromGitter>
<Blacksmoke16> im not sure, would be up to LLVM i'd think
<FromGitter>
<Blacksmoke16> could you even inline that? like since its internal state
<FromGitter>
<mjfiano:matrix.org> I guess it depends how they are implemented. In Lisp, struct members are regular functions that access the internal state, and are inlined by default, but can be told not to be.
<FromGitter>
<mjfiano:matrix.org> I was just wondering if that was the case here, and if the `AlwaysInline` annotation was implied, or a way to opt in/out
<FromGitter>
<manveru:matrix.org> `undefined macro method 'Path#instance_vars'` confused me way longer than i wanna admit... it refers to `Crystal::Macros::Path` and not `Path` :P
<FromGitter>
<Blacksmoke16> yea...all that stuff is macro level types
<FromGitter>
<manveru:matrix.org> i was using Path around that area, so got quite confused :)
<FromGitter>
<Blacksmoke16> that would do it
<FromGitter>
<manveru:matrix.org> i'm still fighting with macro evaluation order i think
<FromGitter>
<Blacksmoke16> oh/
<FromGitter>
<Blacksmoke16> ?
<FromGitter>
<manveru:matrix.org> basically... i want some kind of inheritance i guess