RFC - One word alias for require_relative

Discussion in 'Ruby' started by Ilias Lazaridis, Jun 11, 2011.

  1. Solutions:
    require! 'lib/alter' # 2011-06-17 by Gary Wright
    rr 'lib/alter' # 2011-06-19 by Ted Han
    involve 'lib/alter' # 2011-06-16 by Sam Duncan
    locally 'lib/alter' # 2011-06-11 by Rob Biedenharn
    uniload 'lib/alter' # my
    request 'lib/alter' # my
    include 'lib/alter' # my
    relative 'lib/alter' # my


    require_relative 'lib/baselib'
    require 'sinatra"'
    require! 'lib/baselib"'
    require 'sinatra'


    Applying the change:
    module Kernel
    alias require! require_relative


    I like the word "involve" more, but as "require!" reminds clearly the
    original "require", it's the first choice.

    2nd choice would be to use "rr" and "r" (similar to "p" for "puts")

    Ilias Lazaridis, Jun 20, 2011
    1. Advertisements

  2. Petite Abeille, Jun 20, 2011
    1. Advertisements

    David Masover, Jun 20, 2011
    David Masover, Jun 20, 2011
  5. [...] - (not readed, 'cause it's anyway biased babbling)

    Ilias Lazaridis, Jun 20, 2011
  6. Ilias Lazaridis

    Stu Guest

    alias your a lamer and jackass to boot.
    Stu, Jun 20, 2011
  7. I agree the discussions that have spun off have been (very)
    informative, but as responses to the original question they're
    evidence of good trolling. I would much rather have the informative
    discussion without "dismissed!" but.. that's obvious. Who wouldn't?
    The discussion that came off it might have been the same, in the end,
    but I don't think the actual original point raised by Ilias would have
    had quite the same set of reactions, because they wouldn't have come
    from Ilias.
    Perhaps being terse and linking to existing solutions? If the desire
    is to actually respond to incorrect/uninformed statements, for the
    sake of having proper answers in the thread (which I also agree is
    worthwhile), I can't see a simpler approach. The more "babbling" there
    is (how _dare_ you!), the greater the reaction he's got out of people.
    Adam Prescott, Jun 21, 2011
  8. Not everything he asks has an existing solution, though, partly because he
    doesn't actually give us a real problem to begin with. The best I could do, I
    suppose, is link back to other posts I've made -- for instance, when he
    forgets by the weekend a point I made on Wednesday, rather than making the
    point again, I could just link back to the other post.

    I'm not sure that's easier, but it would be quieter.
    David Masover, Jun 21, 2011
  9. Sorry??? the given argument is really GOOD:


    require can also load from absolute paths -- that is, require_relative can =
    implemented in terms of __FILE__ and require.

    require_relative can also load from absolute paths, so on that score, they =

    If you do not specify an absolute path, require_relative will only attempt =
    resolve things relative to the current file. By contrast, require will atte=
    to resolve things relative to an arbitrary number of paths in $: -- which, =
    that matter, can be configured by the caller.

    If anything, require_relative is "safer" than require. However, neither of
    them is truly "dangerous" now that '.' is no longer in the default load pat=
    When it was, we might've considered require to be actually dangerous, while
    require_relative is not.

    I=C3=B1aki Baz Castillo
    Iñaki Baz Castillo, Jun 21, 2011
  10. If someone is usually not concise and straight to the point, and
    "wraps" technical information with personal-level babbling, then I
    simply stop to read him.
    Ok, I'll take a look:
    [...] - (explanations)


    * loads from an absolute path (if given) or
    * loads from location looked-up within multiple paths given in global
    path variable ($:)

    * loads *only* from an absolute or file_relative path

    In that case, the bang-name "require!" would not be adequate for


    Possibly it would be easier to add behaviour of "require":

    require "./filename" #=> loads relative to $Dir.pwd (process working

    require ":/filename" #=> loads relative to the file-directory

    Possibly there's somewhere a standard for this.

    Ilias Lazaridis, Jun 23, 2011
  11. (please note that responses on ruby-talk do not arrive on
    comp.lang.ruby due to an abrupt interruption of the gateway-service.
    If you post to ruby-talk, you can try to add
    "" to your recipients list to reach
    additionally the usenet group)

    require 'lib/alter' # 2011-06-11 by Intransition (extend
    require! 'lib/alter' # 2011-06-17 by Gary Wright
    rr 'lib/alter' # 2011-06-19 by Ted Han
    involve 'lib/alter' # 2011-06-16 by Sam Duncan
    locally 'lib/alter' # 2011-06-11 by Rob Biedenharn
    uniload 'lib/alter' # my
    request 'lib/alter' # my
    include 'lib/alter' # my
    relative 'lib/alter' # my


    As I realized that "require_relative" does *not* load from the global
    library paths, merging "require" and "require_relative" seems the way
    to go.

    This was suggested already somehow here: 2011-06-11 by Intransition


    Combined with the suggested term "require!", and extending the
    functionality even more, the result would be this one:

    module Kernel
    def require!(*libs)

    libs.each do |lib|
    rescue LoadError
    require lib


    require! 'json', 'yaml', 'sinatra'


    This version of "require" is more powerful, and so it would "deserve"
    the "!".

    require/require_relative remain untouched (full backwards

    require_relative 'lib/baselib'
    require 'sinatra"'

    require! 'lib/baselib', 'sinatra'


    I still like the word "involve" more, but as "require!" reminds
    clearly the
    original "require", it's still the first choice.

    Ilias Lazaridis, Jun 23, 2011
  12. [at least this one made me laugh.]

    Dear Mr. Fictional Project Manager.

    I'll keep the dead-line, and I'm currently active with this task:

    REWORK - Task: Unify behaviour of by-literal-instantiated Objects

    You should refrain from further interventions, as the only commitment
    I've made is to provide a result.

    At the next intervention, I'll use the right that section 3.5 of our
    agreement gives me:

    "Right of contractor to call the project manager names, if the project
    manager intervenes in the processing (after a task was started)"

    cu end of June.

    Ilias Lazaridis, Jun 25, 2011
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.