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/
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
?
macro derive_from(owner, *names)
\{% for name in names %}
\{% var = owner.resolve.instance_vars.find{ |v| v == name } %}
property \{{name}} : \{{var.type}}
\{% end %}
def initialize( \{{ names.map{ |n| "@#{n}".id }.join("").id }} )
end
\{% debug %}
end
the problem is that at this point, instance_vars is empty once more