Crystal: usefull macros

[kostya]

why not add useful macros to crystal?
like :methods, :instance_variables, ....

class Object
  macro def methods
    m = [] of String
    {% for method in @type.methods %}
      m << "{{method.name}}"
    {% end %}
    m
  end
end

usefull, when i just need to find method, (like in ruby in irb), this is faster than loading docs or sources: (i need to find method at_end_of_day)

p Time.now.methods.grep /day/
["day", "time_of_day", "day_of_week", "day_of_year", "at_beginning_of_day", "at_end_of_day", "at_midday", "sunday?", "monday?", "tuesday?", "wednesday?", "thursday?", "friday?", "saturday?", "year_month_day_day_year"]

https://play.crystal-lang.org/#/r/1dn5

[RX14]

Having a list of method names isn't useful to compiled code, and I would argue not useful to humans either. I guess it's slightly useful in crystal play, but you don't get method signatures or any docs on them other than their names, which makes using that information pretty useless. Looking stuff up in the documentation takes ~ 20 seconds and provides you with a lot more information.

On that note, a fuzzy finder in the documentation would be amazing and vastly reduce the time to find a method in the docs. I envision something like ctrl-p to fuzzy find types, or method/macro names across any type. Typing Str# would fuzzy match to string, and because its followed by #,would open up a list of instance methods in the completion list. Same with . for class methods.

Such a tool in the docs would greatly enhance discoverability and ease of use in the docs. Ctrl-t on github is similar but less advanced, but I still use it almost every time I want to find a file.

[kostya]

reasons also described here: https://groups.google.com/forum/#!topic/crystal-lang/-YsUpDtdsTY
when you get some object, much faster to output it methods, than read it sources, it can be shards without docs.

[cjgajard]

You just gave a strong reason to reject this, if #methods is included into std-lib there will be less docs

[rdp]

The goal here is quicker lookup time. Maybe if doc could be embedded into the source (a la python docstrings) somehow then that could also be output, but mostly I would just want to see the method names quickly and see if one looks appropriate. Also see the thread linked above. Cheers!

[rg-3]

good documentation and introspection at runtime are totally different. just because a language can introspect at runtime doesn't mean its documentation has to be crap. features like this BTW are useful for building developer tools. that's how Pry came to be; thanks to features like this. this would just be a small start in that direction. it could help while implementing a repl or a tool like crystal play (which right now doesn't offer much in term of features, but the potential is there).

i don't get the argument against this tbh. arguing it is not useful suggests to me you haven't ever experienced how useful runtime introspection can be. it can lay the foundation for development tools that make your life easier. in any case, if it's rejected, i suggest a crystal-introspect shard or something, cuz definitely useful imo.

[RX14]

@jazzonmymind But runtime introspection is largely pointless in a compiled language because you cannot use that information to generate calls at runtime. The only use for runtime introspection is for human consumption, when programming in a pseudo-dynamic environment such as crystal play. And if that's the case, why not just build better introspection into crystal play? I guess we could add stuff like .methods in crystal play, but it still seems pointless versus just using typeof(var) then checking the docs. I would be much more in favour of integrating docs into crystal play.

[lbguilherme]

That kind of functionality should come from the editor and not from the language itself. The thing that is really being needed here is editor support for autocompletion, which requires some sort of compiler language service to provide the information. The only possible use for a #methods method in crystal is for printing it from some object. And this means you have to run the code to get the output. And that output is very limited to only strings of method names, there is not much you can do with it if you don't have at least an idea of what each method would do. Looking at the docs is much more informative and complete. If going to the docs and finding something requires too many clicks, then the docs' interface is what should be improved to make it easier/faster.

Incremental compilation, when ready, will eventually lead to a language service that can analyse code "as-you-type" and provide an API for editors. Many other languages are doing this nowadays.

Big -1 from me.

[rdp]

why not just build better introspection into crystal play?

That would be really nice. Though not as easy to use for a large codebase,
(ex: kemal server system).

The thing that is really being needed here is editor support for
autocompletion

I agree that would be fantastic, but some of us are old school, and like to
just crack files in vi and then run them. Especially coming from a ruby
background good introspection is quite useful (a la pry). Just seeing
method names is a good start (especially since crystal could tell you the
types of the parameters as well, since it knows those--it's better
introspection than ruby has).Just my $0.02.
Cheers!

On Thu, Nov 10, 2016 at 7:32 AM, Guilherme Bernal [email protected]
wrote:

That kind of functionality should come from the editor and not from the
language itself. The thing that is really being needed here is editor
support for autocompletion, which requires some sort of compiler language
service to provide the information. The only possible use for a #methods
method in crystal is for printing it from some object. And this means you
have to run the code to get the output. And that output is very limited to
only strings of method names, there is not much you can do with it if you
don't have at least an idea of what each method would do. Looking at the
docs is much more informative and complete. If going to the docs and
finding something requires too many clicks, then the docs' interface is
what should be improved to make it easier/faster.

Incremental compilation, when ready, will eventually lead to a language
service that can analyse code "as-you-type" and provide an API for editors.
Many other languages are doing this nowadays.

Big -1 from me.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/crystal-lang/crystal/issues/3525#issuecomment-259704615,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAw0Ipf1jPD7A9IhWpFCezO-aDSr6cGks5q8ysZgaJpZM4KsfEN
.

[RX14]

In crystal, you don't really have a repl to use runtime introspection on. For runtime introspection to work, it actually has to run, which is harder to do in larger projects. For example you might have to recompile (can be a long time on large projects) just to run the .methods call. In addition, to compile, your program has to actually compile, unlike ruby.

As always, crystal isn't ruby and here especially I think that different solutions (editor/ide integration vs runtime introspection) apply to the same problem.