While "involve" is a single word, it is 8 characters and not 7 characters or
less. It appears that "ilias" is the only acceptable answer.
···
On Thu, Jun 16, 2011 at 2:17 PM, Sam Duncan <sduncan@wetafx.co.nz> wrote:
involve
This one sounds good!
I think I've a new favourite!
involve 'lib/alter'
locally 'lib/alter' # locally located file
uniload 'lib/alter' # universal load
request 'lib/alter' #
include 'lib/alter' # the commonly known "include"
relative 'lib/alter' #
.
···
On 16 Ιούν, 23:17, Sam Duncan <sdun...@wetafx.co.nz> wrote:
On 12/06/11 05:35, Ilias Lazaridis wrote:
> 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 wordinvolve
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__
Hi,
···
In message "Re: RFC - One word alias for require_relative" on Sat, 18 Jun 2011 06:40:36 +0900, Ilias Lazaridis <ilias@lazaridis.com> writes:
Solutions:
require! 'lib/alter' # 2011-06-17 by Gary Wright
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
I like the word "involve" more, but as "require!" reminds clearly the
original "require", it's the first choice.
Unfortunately the general rule for the "!" in the method name, at
least in the standard library, is that it means "more dangerous than
the version without bang". Since require! does not follow this rule,
and not worthy to change the rule. So it's no chance to have require!
in the standard library.
matz.
Liar.
···
On Tue, Jun 21, 2011 at 01:20:26AM +0900, Ilias Lazaridis wrote:
On 11 Ιούν, 20:35, Ilias Lazaridis <il...@lazaridis.com> wrote:
relative 'lib/alter' # my
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
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 24/06/11 09:59, Ilias Lazaridis wrote:
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
endend
end#original
require_relative 'lib/baselib'
require 'sinatra"'#new
require! 'lib/baselib', 'sinatra'
[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.
.
···
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!!
> This idea of course presents backward compatibility issues, but it is
> a way to do it that actually improves the robustness and efficiency of
> the load system.If it breaks backwards compatibility, it's neither effective nor
robust, I'd say.
They are different. Of course it's not robust if you are mixing two
incompatible systems. Obviously we wouldn't do that.
Especially since your idea introduces a *lot* of mental overhead on my part:
Not really, it similar enough to overhead that we use for Ruby already
in referencing constants. I mean really, it's `::` and `package-
name:file-path` that's all there is to know.
Do I want a local or a global file? What's the syntax for a global
require, again? And it's almost, but not entirely, completely unlike
accessing nested constants (Module::Class vs ::file).And running non "::require"-aware code leads to fun bugs and security
issues (imagine a "ostruct" file in the load path that wipes your
filesystem. The joys...).
That can already happen, btw. Very easily in fact. But again you are
suggesting mixing two incompatible systems.
On the flip side, require and require_relative make it completely
clear that I load either globally or in relation to my source files
*without* having to remember what a particular bit of line noise
means.If the issue is that you have to type so much more, set up a macro in
your favourite editor. Or if you happen to use AutoHotKey:
::r#::require
::rr#::require_relative
No, that's not it. You missed the big benefit here. By specifying the
package-name in the require, we can guarantee the origin of the file.
As things are today, a gem author could readily play havoc with the
load system --which is why isolation systems sprung up, like isolate
and (partially) Bundler.
···
On Jun 11, 3:51 pm, Phillip Gawlowski <cmdjackr...@googlemail.com> wrote:
On Sat, Jun 11, 2011 at 9:12 PM, Intransition <transf...@gmail.com> wrote:
Hi Josh, your idea is essentially the basis to what I was suggesting
in my earlier comments. By adding the current files path to $LOAD_PATH
you make #require and #relative_require one and the same. But that can
cause problems if you have name conflicts between a local file and a
file in another library. Consider the example I gave. If you wanted to
create an extension for OpenStruct, and created a file called
`ostruct.rb` in your project, how would you load Ruby's 'ostruct.rb'
file?
···
On Jun 12, 5:59 am, Josh Cheek <josh.ch...@gmail.com> wrote:
Back in the blissful days before I understood the `$LOAD_PATH` or the
difference between `Dir.pwd` and `File.dirname(__FILE__)`, I could `require
"file"` and it would work (unless I was in another dir). `require_relative`
isn't universally implemented, and doesn't seem to play well with others.
It's just generally been unavailable / not worked right for me to the point
that I prefer to use `File.dirname(__FILE__) + "/file"`What if, instead of having CWD in the load path, we had
`File.dirname(__FILE__)`? Essentially, CWD of the file that the require
statement is originated through. In the same way that every file has its own
`__FILE__` variable, what if the `$LOAD_PATH` included the current file's
dir, for any given file? Then the old interface would work again, it would
be simpler to think about, security risks of CWD in the load path would be
addressed, and most importantly, I could write beautiful code again (I die a
little bit inside each time I write __FILE__).Of course, I have no idea if it's even possible, and it's not immediately
clear to me how it would affect gems. Still, thought I'd put it out there.
What if, instead of having CWD in the load path, we had
`File.dirname(__FILE__)`? Essentially, CWD of the file that the require
statement is originated through.
Close, but no. When I call 'require' in, say, lib/foo/bar.rb, I want "require
'foo/baz'" to work, but "require 'baz'" should not, and it especially should
not have lib/foo/baz.rb mask lib/baz.rb.
So, if this is going to be a default, I'd much rather it apply to the original
file only -- that is, the file in which Ilias' Kernel#executed? (or whatever)
returns true.
Then again, how many points of entry does a typical application have? I think
the worst-case structure might be something like:
bin/
bunch of scripts
lib/
bunch of library stuff that should be in the load path
Worst case, I might put an init.rb or something in the project root, so that
each script starts off with:
require_relative '../init'
Then, init.rb includes something like this:
$: << File.join(File.dirname(__FILE__), 'lib')
Ugly, but it's only in one place. Or, if you're likely to deal with enough
other pathnames to make it worthwhile:
require 'pathname'
$: << Pathname(__FILE__).parent.join('lib')
Slightly prettier, and __FILE__ is contained to one place inside your project.
I don't like it either, but it just doesn't seem that critical to me.
Then the old interface would work again,
it would be simpler to think about, security risks of CWD in the load path
would be addressed, and most importantly, I could write beautiful code
again (I die a little bit inside each time I write __FILE__).
I tend to agree that it reduces the security risks. I can see myself putting a
Ruby script in my PATH and running it as a command in an unsafe directory. I
can't often see a case where CWD in the path would be more useful than the
root of the project. I really can't see a case where I would drop a Ruby
script in an unsafe directory and then execute it -- it seems like if the
directory is unsafe, no attempt to make the script safe is going to get me
anywhere.
Still, as I said, it doesn't seem that critical to me. It seems like
require_relative, Pathname, and __FILE__ all do the trick.
Of course, I have no idea if it's even possible, and it's not immediately
clear to me how it would affect gems.
I'm not sure how it would affect them, but it seems like gems would need this
even less. With a gem, your $: is pretty much set up for you, so long as you
follow the conventions about putting scripts in bin and libraries in lib.
So it's again something that doesn't seem to matter much -- how many
applications do we have, in comparison to gems?
···
On Sunday, June 12, 2011 04:59:57 AM Josh Cheek wrote:
yes, to describe "mixing"
I realize that this would lead to confusion (or even collisions).
Any other word?
.
···
On 12 Ιούν, 22:18, Luc Heinrich <l...@honk-honk.com> wrote:
On 12 juin 2011, at 20:50, Ilias Lazaridis wrote:
> include 'lib/alter' # the commonly known "include"
> require 'alibrary'You do know that 'include' is already used in Ruby. Right?
Right?!??
I understand.
Thus the first works for the main file, *and* for included files which
can use again require_relative.
The second works only for the main file (usually executed from it's
location).
···
On 15 Ιούν, 22:26, Florian Gilcher <f...@andersground.net> wrote:
On Jun 15, 2011, at 9:10 PM, Ilias Lazaridis wrote:
> require_relative 'lib/alter'
> require './lib/alter'> To my understanding, both should do the same thing.
> Is this right?
No, the first is relative to the file, the second is relative to "Dir.pwd", the process working directory.
-
So it looks I can't drop require_relative.
And so I still need a shorter name.
.
Especially since "request" sounds to me like "would be nice to have,
but not really important to my core functionality". Syntactic sugar
for rescuing a non-critical LoadError, in other words.
···
2011/6/16 Matt Harrison <iwasinnamuknow@genestate.com>:
Ilias, resident Abstract Programmer
request 'lib/alter' # like require, but uses the path relative to the
current fileYou mean like "require_relative" which actually makes more sense than your
suggestions?
--
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
>> 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> #existent load functionality
> load 'alibrary.rb'
> require 'alibrary'> locally 'lib/alter' # locally located file
> include 'lib/alter' # the commonly known "include" ("collision" with
> the "include" used for mixins)
> uniload 'lib/alter' # universal load> #one more suggestion
> request 'lib/alter' # like require, but uses the path relative to the
> current fileYou mean like "require_relative"
Yes of cousre, "require_relative"
which actually makes more sense than your suggestions?
"require_relative(_to_this_file)" in a single word, ideally with 7
chars
This is the topic.
Is it really so difficult for you people to solve a given problem,
even if you personally don't agree that it is a problem?
···
On 16 Ιούν, 17:29, Matt Harrison <iwasinnamuk...@genestate.com> wrote:
On 16/06/2011 13:40, Ilias Lazaridis wrote:
> On 11 , 20:35, Ilias Lazaridis<il...@lazaridis.com> wrote:
-
locally 'lib/alter' # locally located file
include 'lib/alter' # the commonly known "include"
uniload 'lib/alter' # universal load
request 'lib/alter' # like require_relative, but uses the path
relative to the current file
one more
relative 'lib/alter' #
.
You can't count.
And furthermore, you can't read.
optional:
* ideally a 7 letter word
Who is the real troll here?
···
On 17/06/11 08:23, Mike Moore wrote:
On Thu, Jun 16, 2011 at 2:17 PM, Sam Duncan<sduncan@wetafx.co.nz> wrote:
involve
While "involve" is a single word, it is 8 characters and not 7 characters or
less. It appears that "ilias" is the only acceptable answer.
70 messages in and the topic becomes clear: entertain me with 7-letter
words.
···
On 16 Jun 2011 21:30, "Ilias Lazaridis" <ilias@lazaridis.com> wrote:
>
> involveThis one sounds good!
I think I've a new favourite!
"involve", reminds me "include" (which I would use naturally, but it's
used to describe "mixin")
After reviewing some dictionaries, I like the term "involve" even more
than "include".
···
On 16 Ιούν, 23:28, Ilias Lazaridis <il...@lazaridis.com> wrote:
On 16 Éïýí, 23:17, Sam Duncan <sdun...@wetafx.co.nz> wrote:
> On 12/06/11 05:35, Ilias Lazaridis wrote:
> > 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> involve
This one sounds good!
I think I've a new favourite!
involve 'lib/alter'
locally 'lib/alter' # locally located fileuniload 'lib/alter' # universal load
request 'lib/alter' #
include 'lib/alter' # the commonly known "include"relative 'lib/alter' #
-
I leave the trolls now alone to discuss my English skills and to
theorize about my job interviews and whatever other personal things
they may find. They're trolls, don't be to hard in judging them.
Time for some episodes of serials!
.
I had no idea about "require!". Thanks for mentioning it.
···
On Sat, Jun 18, 2011 at 03:17:50AM +0900, Gary Wright 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__
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
This could become my new favourite.
"!" is used as a convention, to clarify that a method "modifies the
object"
"!" 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".
And with an additional space, headers look clean, too:
require! "lib/baselib"
require "sinatra"
Yes, this could be the "winner".
.
···
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__
I've read somewhere that it's a security risk to have the local
directory in the library path (which "require" accesses). Thus
"require_relative" became necessary.
require_relative *has* the local directory in it's "path", thus it is
somehow "more dangerous than the version without bang". It is "more
powerful than the version without bang" - and thus "more dangerous".
Thus it looks like it follows the "!" rule!
···
On 18 Ιούν, 02:30, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
Hi,
In message "Re: RFC - One word alias for require_relative" > on Sat, 18 Jun 2011 06:40:36 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
>Solutions:
>
>require! 'lib/alter' # 2011-06-17 by Gary Wright
>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>I like the word "involve" more, but as "require!" reminds clearly the
>original "require", it's the first choice.Unfortunately the general rule for the "!" in the method name, at
least in the standard library, is that it means "more dangerous than
the version without bang". Since require! does not follow this rule,
and not worthy to change the rule. So it's no chance to have require!
in the standard library.
-
But even if not, the "!" rule could be extended
"!" for object-methods is used as usual, to indicate that a method
"modifies the
object" or that it is "more dangerous".
"!" for "flat" functions (e.g. "flat" Kernel functions which do not
operate strictly on an object) is used to indicate:
* "you should know what you do, possible risks" (= more dangerous),
or
* "more powerful implementation", (essentially this means: more
dangerous).
.