The Crystal programming language | http://crystal-lang.org | Fund Crystal's development: http://is.gd/X7PRtI | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/
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
or that is an issue not related to this PR, nvm
you can run a spec file like you would a normal file, prob best you're going to get for a while
btw, is there any emacs mode out there that actually works with macro syntax?
Am I correct in thinking that the only difference between
include and extend is mixing in instance or class methods?
iirc they're also slightly different in regards to typing
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
and this behaves like composition over inheritance, which is what I suppose they docs mean by partial types, right?
Like mixins in some other languages/paradigms
as you can define abstract methods on the module that the including type would be required to implement them
:thumbsup:
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.
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.
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.
I could look into that. I also want some of these methods to be public facing.
If that will work
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
but if something is common to multiple things, just define that once and use inheritance
Right, I just have to look up abstract types in Crystal again. I'm used to all of their methods also being abstract.
Thanks. I'll re-read that again. Your suggestion above also really clicked for me.
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
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.
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.
I'm having a ton of fun learning, albeit slow, thanks for your help :)
Do the property/getter/setter macros inline the generated method defs?
could you even inline that? like since its internal state
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.
I was just wondering if that was the case here, and if the
AlwaysInline annotation was implied, or a way to opt in/out
undefined macro method 'Path#instance_vars' confused me way longer than i wanna admit... it refers to Crystal::Macros::Path and not Path :P