On Jun 20, 2011, at 5:14 PM, Luc H. wrote:
Trolleomorphism or in other words: if it walks like a troll and quacks like a
troll, it’s a troll.
A subspecies of Tiny Yapper perhaps?
On Monday, June 20, 2011 09:17:51 AM Adam P. wrote:
On Mon, Jun 20, 2011 at 2:54 PM, Christopher D. [email protected]
wrote:OTOH, require_relative is much more clear as to what it is doing than
require! would be, amd. anyway, require! is 8 characters, not 7.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.
On 20 Ιούν, 21:17, David M. [email protected] wrote:
Is “require_relative” more dangerous than “require”, thus “require!”
would fit the naming-convention?I say:
yes, because you can include everything from your source-tree, where
“require” loads only from predefined paths.False.
[…] - (not readed, 'cause it’s anyway biased babbling)
.
On Mon, Jun 20, 2011 at 2:26 PM, Ilias L. [email protected]
wrote:
[…] - (not readed, 'cause it’s anyway biased babbling)
alias your a lamer and jackass to boot.
On Mon, Jun 20, 2011 at 7:39 PM, David M. [email protected]
wrote:
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 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?
Don’t get me wrong, I’d rather not have him here at all, but despite his best
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?”
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.
“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.
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.
On Tuesday, June 21, 2011 06:51:08 AM Adam P. wrote:
On Mon, Jun 20, 2011 at 7:39 PM, David M. [email protected] wrote:
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.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.
On Monday, June 20, 2011 11:10:35 AM Ilias L. wrote:
I say:
yes, because you can include everything from your source-tree, where
“require” loads only from predefined paths.
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
attempt
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
path.
When it was, we might’ve considered require to be actually dangerous,
while
require_relative is not.
On 21 Ιούν, 21:55, Iñaki Baz C. [email protected] wrote:
2011/6/20 Ilias L. [email protected]:
False.
[…] - (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:
False.
[…] - (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.
.
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.
2011/6/20 Ilias L. [email protected]:
False.
[…] - (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
attempt
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
path.
When it was, we might’ve considered require to be actually dangerous,
while
require_relative is not.
On Wednesday, June 22, 2011 10:25:37 PM Ilias L. wrote:
simply stop to read him.
Yet take the time to post “Babbling”, without actually confirming that
it was.
Still, I didn’t even write as much “personal” stuff as in this
paragraph, or
the paragraph I quoted above. I just responded directly to your points.
When you do the same…
the given argument is really GOOD:
Ok, I’ll take a look:
[snip]
In that case, the bang-name “require!” would not be adequate for
“require_relative”.
…when you do the same, we get somewhere.
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.
That’s not a bad idea.
I still don’t see the point of having this over require_relative, and we
can
no longer require files which begin with a colon character. It certainly
seems
less readable than require_relative, especially when I usually read a
colon
prefix as “Symbol”.
Still, it at least doesn’t break much (who has a file named :foo.rb,
really?).
So, just for fun, here’s an implementation:
module Kernel
def require_with_colon path
if path =~ /^:(.*)/
require_relative $1
else
require_without_colon path
end
end
alias require_without_colon require
alias require require_with_colon
end
Or, to pollute the namespace less:
module Kernel
require_without_colon = method :require
define_method :require do |path|
if path =~ /^:(.*)/
require_relative $1
else
require_without_colon[path]
end
end
end
I’ll still be using require_relative, myself, but if people end up
actually
using either of the above, I’d think that’d be a good case for getting
it into
core, if that’s what you want to do.
On 11 , 20:35, Ilias L. [email protected] wrote:
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
“[email protected]” 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 W.
rr ‘lib/alter’ # 2011-06-19 by Ted H.
involve ‘lib/alter’ # 2011-06-16 by Sam D.
locally ‘lib/alter’ # 2011-06-11 by Rob B.
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.
.
On Thursday, June 23, 2011 02:07:47 PM David M. wrote:
On Wednesday, June 22, 2011 10:25:37 PM Ilias L. wrote:
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.
Reading back, I think my code sample doesn’t quite follow your
suggestion:
module Kernel
def require_with_colon path
if path =~ /^:(.*)/
Replace that line with
if path =~ /^:\/(.*)/
require_relative $1 else require_without_colon path end end alias require_without_colon require alias require require_with_colonend
That’s better, actually, as it means we now only break requiring Ruby
files
which are in some subdirectory of a directory called ‘:’ which is in the
load
path, which is sufficiently outlandish that I don’t think it’s a
credible
objection anymore. After all, ‘:’ is already the load path separator
anyway.
Wait a moment …
Are you now referring to YOUR question and giving YOURSELF an answer to
this question?
I am not sure where you live, perhaps in Greece, but in central europe
it is custom to enter a DISCUSSION not by answering your own questions,
unless they were suggestive questions insinuating that you weren’t
interested in an honest answer anyway. Or you were monologuing anyway.
Why should anyone bother with you if you aren’t interested in replies
anyway?
This version of “require” is more powerful, and so it would
“deserve” the “!”.
Bold statement especially given that you have 0 knowledge about ruby.
Otherwise, you would not have suggested to append a trailing “!”
You do know when ! are typically used for method names, right?
On 24/06/11 09:59, Ilias L. wrote:
require lib end endend
end
#original
require_relative ‘lib/baselib’
require ‘sinatra"’#new
require! ‘lib/baselib’, ‘sinatra’
Presumably you would then have to be careful not to have something
called sinatra.rb nearby to avoid unexpected side effects. Merging the
two flavours of require might not be a good idea for that reason. It
also makes it a bit ambiguous for people reading your code as to where
the require is /supposed/ to be coming from.
… unless I’m missing something obvious.
On Thu, Jun 23, 2011 at 1:07 PM, David M. [email protected]
wrote:
I still don’t see the point of having this over require_relative
I’d say Ilias wants to save himself some typing, but a ballpark estimate
puts Ilias at 2500 uses of require_relative before having a 7 letter
alias
would save him keystrokes over the amount of typing he’s done in this
thread
alone.
On 24 , 22:18, “Project Manager” [email protected] wrote:
On 23-Jun-2011, Ilias L. [email protected] wrote:
I still like the word “involve” more, but as “require!” reminds
clearly the
original “require”, it’s still the first choice.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 of you
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.
.