Top-level namespace is overloaded

[westonganger]

The top-level namespace is far too overused. Cons:

• This makes for one extremely long documentation page, and the methods are buried 1/4 of the page down because of the excess of constants in the top level namespace. One of the major complaints about DragonRuby was that the documentation is just one giant page. (I cant find this link to this discussion point however I found it to be notable)

• This top-level namespace is the least obvious link on the documentation pages, mostly the eyes are gravitated towards clicking on a class. (this was why I was previously unable to find the method get_attribute_from_element)

• Using the top-level namespace so heavily doesnt feel very Ruby like, as such I think many Rubyists could be turned off by this, I think that mostly all methods should be namespaced inside of some class.

An improved example taken from the website:

Suggested (for example, it should be noted the Draw constant may not be ideal naming, not sure)

Window.init(800, 480, "Taylor Example")
Window.set_target_fps(60)

until Window.should_close? # Detect window close button or ESC key
  Draw.drawing do
    Draw.clear
    Draw.text(
      "Welcome to your first Taylor application!",
      190, 200, 20, Colors::DARKGRAY
    )
  end
end

Window.close

Current

init_window(800, 480, "Taylor Example")
set_target_fps(60)

until window_should_close? # Detect window close button or ESC key
  drawing do
    clear
    draw_text(
      "Welcome to your first Taylor application!",
      190, 200, 20, DARKGRAY
    )
  end
end

close_window

If we did decide to update the namespace. If backwards compatibilty for old games is required then we could have a backwards_compatibilty layer that can be loaded. Ex.

# game.rb
require "backwards_compatibility"

# backwards_compability.rb
def close_window
  Window.close
end

def init_window(*args)
  Window.init(*args)
end

... etc ...

[HellRok]

I really like this suggestion and have had plans to clean up the top level namespace, on the roadmap this is what I consider part of "Audit the codebase". When I do it I'll also be writing a migration guide to 1.0.0 for people who have been using it that details all of the major changes like this.

This top level namespace clutter has come from me basically directly porting raylib functions with minimal effort to make them more ruby like. The reason for this is because I wanted to use the tools to actually make some games before I decide how I want to group them and make them more ruby like. I've been doing that for a while now and I have quite a few ideas, much like the ones you have mentioned.

Thanks for showing an interest in Taylor, I really appreciate it! I will absolutely be implementing changes based on this feedback.

[awfulcooking]

I'd love to help with patches for this.

Feel free to send some too, @westonganger. If there's a burst from me I'll PR it this weekend.

[kwrooijen]

Maybe we could create modules based on the Official Raylib Cheatsheet? e.g.:

Raylib::Core.init_window
Raylib::Shapes.get_collision_rec
Raylib::Textures.load_image
Raylib::Text.get_font_default
Raylib::Models.draw_line_3d
Raylib::Audio.init_audio_device

That way people can just refer to the official cheatsheet without having to cross reference how Taylor implemented it. From there we can create helper classes to make it easier (e.g. the Rectangle class).