On Mon, Jun 20, 2011 at 6:25 AM, Chad Perrin <c...@apotheon.net> wrote:
> Oddly enough, you should be following your own advice. Sure, you didn't > declare the thread closed, but you *are* feeding the "Scumbag Steve" of > this list.
OTOH, this has Ilias nicely contained in one spot, instead of him being all over the place polluting actually interesting discussions.
I'm running out of popcorn, though.
-- Phillip Gawlowski
A method of solution is perfect if we can forsee from the start, and even prove, that following that method we shall attain our aim. -- Leibnitz
> On 17 Ιούν, 21:17, Gary Wright <gwtm...@mac.com> wrote: >> I can't believe I'm adding to this conversation...
>> Ruby already has an idiom for naming two related methods so how about:
>> require "a/b" # the usual >> require! "a/b" # require relative to __FILE__
> This could become my new favourite.
> "!" is used as a convention, to clarify that a method "modifies the > object"
This misstates the existing convention; see below.
> "!" could be used for stand-alone functions (e.g. the "flat" Kernel > functions which do not operate strictly on an object) to clarify (by > convention) "you should know what you do, possible risks" or simply > "alternate implementation".
This second thing is actually the current convention for "!" for normal methods (e.g., not just "flat" Kernel functions.): "!" indicates a more-dangerous alternative when the base name is already used. It doesn't always indicate a mutating method, and mutating methods don't always have it.
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.
On Mon, Jun 20, 2011 at 2:54 PM, Christopher Dicely <cmdic...@gmail.com> 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. (Hint: it's intentional. He's being a dick. On purpose.)
If anyone else had posted his original "scenario", I'd bet it would have been largely ignored.
Can we stop being trolled now? Even if he's somehow not intending to be a troll, it's all the same up to trolleomorphism.
> 2011/6/17 Ilias Lazaridis <il...@lazaridis.com>: > > On 17 Éïýí, 21:17, Gary Wright <gwtm...@mac.com> wrote: > >> I can't believe I'm adding to this conversation...
> >> Ruby already has an idiom for naming two related methods so how about:
> >> require "a/b" # the usual > >> require! "a/b" # require relative to __FILE__
> > This could become my new favourite.
> > "!" is used as a convention, to clarify that a method "modifies the > > object"
> This misstates the existing convention; see below.
> > "!" could be used for stand-alone functions (e.g. the "flat" Kernel > > functions which do not operate strictly on an object) to clarify (by > > convention) "you should know what you do, possible risks" or simply > > "alternate implementation".
> This second thing is actually the current convention for "!" for > normal methods (e.g., not just "flat" Kernel functions.): "!" > indicates a more-dangerous alternative when the base name is already > used. It doesn't always indicate a mutating method, and mutating > methods don't always have it.
> 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.
> > On 17 Ιούν, 21:17, Gary Wright <gwtm...@mac.com> wrote: > >> I can't believe I'm adding to this conversation...
> >> Ruby already has an idiom for naming two related methods so how about:
> >> require "a/b" # the usual > >> require! "a/b" # require relative to __FILE__
> > This could become my new favourite.
> > "!" is used as a convention, to clarify that a method "modifies the > > object"
> This misstates the existing convention; see below.
ok
> > "!" could be used for stand-alone functions (e.g. the "flat" Kernel > > functions which do not operate strictly on an object) to clarify (by > > convention) "you should know what you do, possible risks" or simply > > "alternate implementation".
> This second thing is actually the current convention for "!" for > normal methods (e.g., not just "flat" Kernel functions.): "!" > indicates a more-dangerous alternative when the base name is already > used.
Which would mean the rule apply, and the question is:
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.
> It doesn't always indicate a mutating method, and mutating > methods don't always have it.
ok
> OTOH, require_relative is much more clear as to what it is doing than > require! would be, amd.
> 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
On 20 Éïýí, 07:43, Phillip Gawlowski <cmdjackr...@googlemail.com> wrote:
> On Mon, Jun 20, 2011 at 6:25 AM, Chad Perrin <c...@apotheon.net> wrote:
> > Oddly enough, you should be following your own advice. Sure, you didn't > > declare the thread closed, but you *are* feeding the "Scumbag Steve" of > > this list.
> OTOH, this has Ilias nicely contained in one spot, instead of him > being all over the place polluting actually interesting discussions.
I write only in threads that I open (making it simple for people to filter me out, friendly as I am)
What's "contained in one spot" is the "freak-show".
On Monday, June 20, 2011 11:10:35 AM Ilias Lazaridis wrote:
> On 20 Ιούν, 16:54, Christopher Dicely <cmdic...@gmail.com> wrote: > > This second thing is actually the current convention for "!" for > > normal methods (e.g., not just "flat" Kernel functions.): "!" > > indicates a more-dangerous alternative when the base name is already > > used.
> Which would mean the rule apply, and the question is:
> 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.
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 Monday, June 20, 2011 09:17:51 AM Adam Prescott wrote:
> On Mon, Jun 20, 2011 at 2:54 PM, Christopher Dicely <cmdic...@gmail.com> 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 Monday, June 20, 2011 11:10:35 AM Ilias Lazaridis wrote:
> > On 20 Ιούν, 16:54, Christopher Dicely <cmdic...@gmail.com> wrote: > > > This second thing is actually the current convention for "!" for > > > normal methods (e.g., not just "flat" Kernel functions.): "!" > > > indicates a more-dangerous alternative when the base name is already > > > used.
> > Which would mean the rule apply, and the question is:
> > 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.
On Mon, Jun 20, 2011 at 7:39 PM, David Masover <ni...@slaphack.com> wrote: > On Monday, June 20, 2011 09:17:51 AM Adam Prescott wrote: >> 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 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) 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?"
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'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.
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 Prescott wrote:
> On Mon, Jun 20, 2011 at 7:39 PM, David Masover <ni...@slaphack.com> 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.
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.
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
> 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 "comp.lang.ruby@googlegroups.com" 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 "!".
On 23-Jun-2011, Ilias Lazaridis <il...@lazaridis.com> 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!!
On 24 Éïýí, 22:18, "Project Manager" <y...@project.here> wrote:
> On 23-Jun-2011, Ilias Lazaridis <il...@lazaridis.com> 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:
