RFC - One word alias for require_relative

I

Ilias Lazaridis

This is a simple Request for Comments.

Scenario:

require_relative 'lib/alter'
require 'alibrary'

Some project manager complains about "require_relative", and asks you
to find a one-word alias.

Which name would you select and for what reasons?

Requirements
must:
* one word

optional:
* ideally a 7 letter word

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

-

#old
require_relative 'lib/baselib'
require 'sinatra"'
#new
require! 'lib/baselib"'
require 'sinatra'

-

Applying the change:
module Kernel
alias require! require_relative
end

-

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")

..
 
D

David Masover

=20
Which would mean the rule apply, and the question is:
=20
Is "require_relative" more dangerous than "require", thus "require!"
would fit the naming-convention?
=20
I say:
=20
yes, because you can include everything from your source-tree, where
"require" loads only from predefined paths.

=46alse.

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

require_relative can also load from absolute paths, so on that score, they =
are=20
even.

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

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

David Masover

require_relative is completely fine. There is almost no sensible
discussion here, and certainly not one worth 100+ posts, complete with
people letting Ilias rile them up so that he can truncate text in his
reply, call it babbling and declare the thread closed and "dismiss"
people, like he owns the place, which just further aggravates people.

This is true. The actual, interesting discussion has been:

- Is require_relative a good name? Most people think yes, but there have been
some good arguments to the contrary.
- Is there some inherent security risk in any require? There used to be by
having '.' in the load path, but not anymore.
- Can we use require_relative with autoload? Not directly related, but I
wonder if it would've come up without this thread first?
- Just what _is_ the policy on bang methods?

That's just on this thread. His questions are profoundly stupid, but they can
also be a catalyst for real discussion, partly because of how they often deal
with such obscure and fundamental properties of the language.

I know I learn things just trying to wrap my head around (and explain) just
how wrong Ilias is about, say, initialize and constructors. It's fair to say
that I'd forgotten, or never learned, a really solid concept of what
constructors actually are in Ruby, and why initialize isn't a constructor (but
is, in fact, a good pattern to adopt in Java code) -- and I learned this by
watching someone else explain to Ilias how wrong he is.
(Hint: it's intentional. He's being a dick. On purpose.)

Don't get me wrong, I'd rather not have him here at all, but despite his best
efforts to troll us, he does occasionally raise some good points. Probably the
most productive use we could make of him is to read his initial post, respond
to that, and then ignore him and only respond to sane people for the rest of
the thread.

Of course, this is why he's so dangerous as a troll. He's not just some asshat
posting Goatse or Lemonparty. He's dangerous because he can give an appearance
of actually having interesting questions, opinions, or observations, and then
being a dick at absolutely every opportunity after raising the initial
concern.
If anyone else had posted his original "scenario", I'd bet it would
have been largely ignored.

Unlikely. If you look at the people responding to him, it doesn't seem like
most of them are people who (like me) should know better by now. If it was
anyone else posting that, I might've been kinder, and given them more of the
benefit of the doubt, but the response would still be effectively the same:
"Why would you ever want that? What are you actually trying to do?"
Can we stop being trolled now?

I suppose.

I'll probably continue to respond when it seems like there's a genuine
misunderstanding, mostly because if a newbie happens on one of his misguided
posts ("require_relative" is more dangerous than "require"? Really?), I'd like
an actual answer to be there.

Plus, every time he responds to an actual, legitimate, informative answer by
"dismissing" me or "closing the thread," I win.

But I guess this makes me part of the problem. I'm not sure what a good
solution is, though. I hate to leave his crap unchallenged. Either responding
or not responding still gives the impression that he's running the list, and
gives him some amount of perceived credibility.
 
A

Adam Prescott

This is true. The actual, interesting discussion has been:

=C2=A0- Is require_relative a good name? Most people think yes, but there= have been
some good arguments to the contrary.
=C2=A0- Is there some inherent security risk in any require? There used t= o be by
having '.' in the load path, but not anymore.
=C2=A0- Can we use require_relative with autoload? Not directly related, = but I
wonder if it would've come up without this thread first?
=C2=A0- Just what _is_ the policy on bang methods?

That's just on this thread. His questions are profoundly stupid, but they= can
also be a catalyst for real discussion, partly because of how they often = deal
with such obscure and fundamental properties of the language.

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?
I know I learn things just trying to wrap my head around (and explain) ju= st
how wrong Ilias is about, say, initialize and constructors. It's fair to = say
that I'd forgotten, or never learned, a really solid concept of what
constructors actually are in Ruby, and why initialize isn't a constructor= (but
is, in fact, a good pattern to adopt in Java code) -- and I learned this = by
watching someone else explain to Ilias how wrong he is.


Don't get me wrong, I'd rather not have him here at all, but despite his = best
efforts to troll us, he does occasionally raise some good points. Probabl= y the
most productive use we could make of him is to read his initial post, res= pond
to that, and then ignore him and only respond to sane people for the rest= of
the thread.

Of course, this is why he's so dangerous as a troll. He's not just some a= sshat
posting Goatse or Lemonparty. He's dangerous because he can give an appea= rance
of actually having interesting questions, opinions, or observations, and = then
being a dick at absolutely every opportunity after raising the initial
concern.


Unlikely. If you look at the people responding to him, it doesn't seem li= ke
most of them are people who (like me) should know better by now. If it wa= s
anyone else posting that, I might've been kinder, and given them more of = the
benefit of the doubt, but the response would still be effectively the sam= e:
"Why would you ever want that? What are you actually trying to do?"

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.
I suppose.

I'll probably continue to respond when it seems like there's a genuine
misunderstanding, mostly because if a newbie happens on one of his misgui= ded
posts ("require_relative" is more dangerous than "require"? Really?), I'd= like
an actual answer to be there.

Plus, every time he responds to an actual, legitimate, informative answer= by
"dismissing" me or "closing the thread," I win.

But I guess this makes me part of the problem. I'm not sure what a good
solution is, though. I hate to leave his crap unchallenged. Either respon= ding
or not responding still gives the impression that he's running the list, = and
gives him some amount of perceived credibility.

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.
 
D

David Masover

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.

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.
 
I

Iñaki Baz Castillo

2011/6/20 Ilias Lazaridis said:
[...] - (not readed, 'cause it's anyway biased babbling)

Sorry??? the given argument is really GOOD:


False.

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

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

If you do not specify an absolute path, require_relative will only attempt =
to
resolve things relative to the current file. By contrast, require will atte=
mpt
to resolve things relative to an arbitrary number of paths in $: -- which, =
for
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=
h.
When it was, we might've considered require to be actually dangerous, while
require_relative is not.

--=20
I=C3=B1aki Baz Castillo
<[email protected]>
 
I

Ilias Lazaridis

2011/6/20 Ilias Lazaridis said:
[...] - (not readed, 'cause it's anyway biased babbling)

Sorry???

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.
the given argument is really GOOD:

Ok, I'll take a look:
[...] - (explanations)

Essence:

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

require_relative
* loads *only* from an absolute or file_relative path

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

-

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

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

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

Possibly there's somewhere a standard for this.

..
 
I

Ilias Lazaridis

This is a simple Request for Comments.

Scenario:

require_relative 'lib/alter'
require 'alibrary'

Some project manager complains about "require_relative", and asks you
to find a one-word alias.

Which name would you select and for what reasons?

Requirements
must:
* one word

optional:
* ideally a 7 letter word

(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
"(e-mail address removed)" to your recipients list to reach
additionally the usenet group)

Solutions:
require 'lib/alter' # 2011-06-11 by Intransition (extend
functionality)
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|
begin
require_relative(lib)
rescue LoadError
require lib
end
end

end
end

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

-

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

require/require_relative remain untouched (full backwards
compatibility)

#original
require_relative 'lib/baselib'
require 'sinatra"'

#new
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.

..
 
I

Ilias Lazaridis

Ilias, stop wasting your time and get back to work!  As your project manager
and direct superior I expect.... no, I *demand* you listen to me and get
back to the tasks I have assigned you.  You have a deadline in front ofyou
and all you have done so far is argue over minutiae.  Dismissed!!

[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
http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/8d55ce96810ccf60#

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.

..
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,009
Latest member
GidgetGamb

Latest Threads

Top