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
.
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 wordoptional:
* ideally a 7 letter word
require 'alibrary'
locally 'lib/alter'
.
(Uh oh. I replied to Ilias! 
-Rob
Rob Biedenharn
Rob@AgileConsultingLLC.com http://AgileConsultingLLC.com/
rab@GaslightSoftware.com http://GaslightSoftware.com/
On Jun 11, 2011, at 1:35 PM, 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 wordoptional:
* ideally a 7 letter word
Okay, I'm willing to respond to this b/c I think there's an
interesting alternative here that would be an improvement over the
current system.[1]
Instead of having two different methods, have the one #require that
does both. How would it work? Kind of like constant lookup. First the
require method would look locally, if it failed to find it there it
could look relative to the current loading project, and then from
there globally. Of course the problem is name conflict, but that can
easily be solved. Let's say I have lib file called 'ostruct.rb', say
it has an extension to ruby's OpenStruct class. Because of the
relative loading we wouldn't be able to just require 'ostruct' b/c it
would try to load itself. So instead we have to tell it to look
globally. We just need a way to denote it, e.g.
require '::ostruct'
We could also be more specific and actually specify the library it is
in, which could be used to speed up load times and prevent name
clashes altogether, with:
require 'ruby:ostruct'.
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.
[1] Hey, get what you can out of him.
Afternoon,
On Sat, Jun 11, 2011 at 10:35 AM, Ilias Lazaridis <ilias@lazaridis.com>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.
Fire the project manager or get another job - any bozo that cares about 9
descriptive characters isn't worth the time.....
John
P.S. This now moves into the lead as to the stupidest of Ilias' questions
thus far. I am surprised that this isn't a barrier to something.
As there is just one suggestion till now, I'll add two suggestions
myself, thus we have 3:
locally 'lib/alter' # locally located file
require 'alibrary'
new suggestions:
include 'lib/alter' # the commonly known "include"
require 'alibrary'
uniload 'lib/alter' # universal load
require 'alibrary'
.
On 11 Ιούν, 20:35, Ilias Lazaridis <il...@lazaridis.com> 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 wordoptional:
* ideally a 7 letter word
require_relative 'lib/alter'
require './lib/alter'
To my understanding, both should do the same thing.
Is this right?
.
On 11 Ιούν, 20:35, Ilias Lazaridis <il...@lazaridis.com> 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 wordoptional:
* 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 file
.
On 11 Ιούν, 20:35, Ilias Lazaridis <il...@lazaridis.com> 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 wordoptional:
* ideally a 7 letter word
involve
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 wordoptional:
* ideally a 7 letter word.
My own suggestions didn't pass the requirements.
I order the list
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 11 Ιούν, 20:35, Ilias Lazaridis <il...@lazaridis.com> 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 wordoptional:
* ideally a 7 letter word
-
Original situation of headers
require_relative "lib/baselib"
require "sinatra"
Use of "involve" results in very clean headers:
involve "lib/baselib"
require "sinatra"
-
Applying the change:
module Kernel
alias involve require_relative
end
-
Btw: I am the project-manager (on my own project), and as I'm alone
for now, I had to fulfil the role of the executing project-member as
well (posting this RFC here).
This thread gives additionally some valuable insights subjecting the
topic "trolling" and "trolls", uncovering some "trouble-makers" of
comp.lang.ruby (or ruby-talk).
Many thanks to the very few people which managed to stay in-topic and
in-context.
Time to close this thread.
.
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
On 11 Ιούν, 20:35, Ilias Lazaridis <il...@lazaridis.com> 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 wordoptional:
* ideally a 7 letter word
-
#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.
.
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 11 Ιούν, 20:35, Ilias Lazaridis <il...@lazaridis.com> 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 wordoptional:
* ideally a 7 letter word
-
#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")
.
(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
On 11 Ιούν, 20:35, Ilias Lazaridis <il...@lazaridis.com> 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 wordoptional:
* ideally a 7 letter word
-
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.
.
If it breaks backwards compatibility, it's neither effective nor
robust, I'd say.
Especially since your idea introduces a *lot* of mental overhead on my part:
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...).
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
(using the # to avoid situations where you want to type literal "r" and "rr"s)
You can then tell your project manager to do some actual work, instead
of worrying about 8 bytes worth of storage.
On Sat, Jun 11, 2011 at 9:12 PM, Intransition <transfire@gmail.com> wrote:
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.
--
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
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.
> 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 wordrequire 'alibrary'
locally 'lib/alter'
"Locally", because it's an inclusion from the local directories, and
not from the global library directories.
Yes, this one sounds good.
(Uh oh. I replied to Ilias!
(You will be punished with 37 spam mails)
.
On 11 Ιούν, 20:48, Rob Biedenharn <R...@AgileConsultingLLC.com> wrote:
On Jun 11, 2011, at 1:35 PM, 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 wordOkay, I'm willing to respond to this
[...] - (changing/extending context)
But you haven't responded.
The response would be to suggest a word.
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.
The process would be:
* let "require" and "require_relative" work as usual (backwards
compatibility)
* define a new keyword for the new load system (e.g. "ensure")
* engineer this system from scratch
* including a non-intrusive dynamic OO library-system which builds
on the strengths of the language (dynamic, oo, etc.)
The term "engineer" refers to the process.
But this is really *ways* out of the current topic here.
As said, just looking for a word, ideally with 7 letters.
.
On 11 Ιούν, 22:12, Intransition <transf...@gmail.com> wrote:
On Jun 11, 1:35 pm, Ilias Lazaridis <il...@lazaridis.com> wrote:
You do know that 'include' is already used in Ruby. Right?
Right?!??
On 12 juin 2011, at 20:50, Ilias Lazaridis wrote:
include 'lib/alter' # the commonly known "include"
require 'alibrary'
--
Luc Heinrich - luc@honk-honk.com
No.
require_relative 'lib/alter'
require File.join(File.dirname(__FILE__), 'lib/alter')
those two are the same.
Michael Edgar
adgar@carboni.ca
http://carboni.ca/
On Jun 15, 2011, at 3: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.
Regards,
Florian
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?
You mean like "require_relative" which actually makes more sense than your suggestions?
On 16/06/2011 13:40, Ilias Lazaridis wrote:
On 11 Ιούν, 20:35, Ilias Lazaridis<il...@lazaridis.com> 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 wordoptional:
* 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 file