RFC - One word alias for require_relative
Ilias Lazaridis
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
.
Rob Biedenharn
require 'alibrary'
locally 'lib/alter'
>
> .
>
> --
> http://lazaridis.com
>
(Uh oh. I replied to Ilias! ;-)
-Rob
Rob Biedenharn
R...@AgileConsultingLLC.com http://AgileConsultingLLC.com/
r...@GaslightSoftware.com http://GaslightSoftware.com/
Intransition
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.
>
> --http://lazaridis.com
Phillip Gawlowski
>
> 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.
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.
--
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
Intransition
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:
>
> > 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.
Phillip Gawlowski
>
>
>> 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.
Mu. Address the point I made.
>> 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.
require # works globally
require_relative # works relative to current working directory
What these methods do is *encoded in the method name*. I don't have to
remember *a thing*, since the method tells me what it does, and it
even works when require[_relative] loads from a variable.
>> 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.
Not without "." in the loadpath it can't:
PS C:\temp> irb
>> require "ostruct"
=> true
>> require "./ostruct"
This is not Ruby's OpenStruct library.
=> true
>> exit
PS C:\temp> cat .\ostruct.rb
puts "This is not Ruby's OpenStruct library."
PS C:\temp> ruby -v
ruby 1.9.2p180 (2011-02-18) [i386-mingw32]
> 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.
No, we can't. Look up is still along the path, and something that is
named identically within the loadpath that gets loaded first still
blows up in your face.
> 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.
Which your system doesn't mitigate against at all. And it cannot, ever
(nor does Bundler: It is a poor man's version and dependency control).
Once code is on a machine, it can do whatever it wants. Ruby just
makes it easier to modify its own classes, but the vector is still
there: external code executed locally.
Without making gem signing the default, and have Ruby / RubyGems load
*only* signed source files, you have no idea who created the code
you've downloaded. And even then you have to trust the certificate,
and that the private key with which the code was signed wasn't
compromised somehow.
Without auditing code, you have no idea what the code does to your
machine, and who prevents anyone from claiming "I'm part of Ruby's
namespace"?
John W Higgins
Afternoon,
On Sat, Jun 11, 2011 at 10:35 AM, 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.
>
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.
Intransition
On Jun 11, 6:24 pm, Phillip Gawlowski <cmdjackr...@googlemail.com>
wrote:
> On Sat, Jun 11, 2011 at 11:08 PM, Intransition <transf...@gmail.com> wrote:
>
> >> 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.
>
> Mu. Address the point I made.
Then call it #another_way_to_load_a_ruby_file or #awtlarf to meet
IIias' 7-letter requirement;. Whatever. It's beside the point.
> >> 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.
>
> require # works globally
> require_relative # works relative to current working directory
>
> What these methods do is *encoded in the method name*. I don't have to
> remember *a thing*, since the method tells me what it does, and it
> even works when require[_relative] loads from a variable.
You still have to remember the name of the method. Moreover my system
does things yours does not. So to be fair you would need another
method or two, and a hash option too, e.g.
require 'ostruct', :library=>'ruby'
> >> 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.
>
> Not without "." in the loadpath it can't:
> PS C:\temp> irb>> require "ostruct"
> => true
> >> require "./ostruct"
>
> This is not Ruby's OpenStruct library.
> => true>> exit
>
> PS C:\temp> cat .\ostruct.rb
> puts "This is not Ruby's OpenStruct library."
> PS C:\temp> ruby -v
> ruby 1.9.2p180 (2011-02-18) [i386-mingw32]
What's your point? I don't see how that has anything to do with what
you said.
> > 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.
>
> No, we can't. Look up is still along the path, and something that is
> named identically within the loadpath that gets loaded first still
> blows up in your face.
That's not it. The suggestion I am making moves beyond the simple path
system Ruby now uses. It would require that Ruby understand packages.
So it's not "still along the path".
> > 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.
>
> Which your system doesn't mitigate against at all. And it cannot, ever
> (nor does Bundler: It is a poor man's version and dependency control).
> Once code is on a machine, it can do whatever it wants. Ruby just
> makes it easier to modify its own classes, but the vector is still
> there: external code executed locally.
Yes it does. I use it all the time. I wrote such a system and use if
for development.
> Without making gem signing the default, and have Ruby / RubyGems load
> *only* signed source files, you have no idea who created the code
> you've downloaded. And even then you have to trust the certificate,
> and that the private key with which the code was signed wasn't
> compromised somehow.
You're now talking about another subject.
> Without auditing code, you have no idea what the code does to your
> machine, and who prevents anyone from claiming "I'm part of Ruby's
> namespace"?
Ruby.
Phillip Gawlowski
>
> You still have to remember the name of the method. Moreover my system
> does things yours does not. So to be fair you would need another
> method or two, and a hash option too, e.g.
>
> require 'ostruct', :library=>'ruby'
What for?
And yes, I have to remember the method name. A method name that's much
more mnemonic than '::whatever'.
>
> What's your point? I don't see how that has anything to do with what
> you said.
You can't accidentally pollute the namespace if the file doesn't get
loaded by default. One of the reasons we have "require" and
"require_relative".
> That's not it. The suggestion I am making moves beyond the simple path
> system Ruby now uses. It would require that Ruby understand packages.
> So it's not "still along the path".
Please. Then I just define a package, put that someplace first in the
loadpath, and *boom*, your system blowing up in your face again.
>> Which your system doesn't mitigate against at all. And it cannot, ever
>> (nor does Bundler: It is a poor man's version and dependency control).
>> Once code is on a machine, it can do whatever it wants. Ruby just
>> makes it easier to modify its own classes, but the vector is still
>> there: external code executed locally.
>
> Yes it does. I use it all the time. I wrote such a system and use if
> for development.
Every programmer can invent a cypher he, himself, cannot break, as well.
Unless you wrote your own OS that allows only the execution of
specifically whitelisted binaries *and* script files (you have to
prevent arbitrary code execution within a Ruby interpreter, too, after
all, and just whitelisting the Ruby binary won;t work for that), code
that is running on your machine, can manipulate your machine.
>> Without auditing code, you have no idea what the code does to your
>> machine, and who prevents anyone from claiming "I'm part of Ruby's
>> namespace"?
>
> Ruby.
How? Since Ruby can execute arbitrary OS-level commands with system()
or ``, how can Ruby prevent namespace pollution?
Intransition
On Jun 11, 8:32 pm, Phillip Gawlowski <cmdjackr...@googlemail.com>
wrote:
> On Sun, Jun 12, 2011 at 1:42 AM, Intransition <transf...@gmail.com> wrote:
>
> > You still have to remember the name of the method. Moreover my system
> > does things yours does not. So to be fair you would need another
> > method or two, and a hash option too, e.g.
>
> > require 'ostruct', :library=>'ruby'
>
> What for?
It restricts where the file 'ostruct' can be found. In this case to
ruby's standard library.
> And yes, I have to remember the method name. A method name that's much
> more mnemonic than '::whatever'.
Fair enough. The device isn't as important as what it accomplishes. A
hash option can work too.
> > What's your point? I don't see how that has anything to do with what
> > you said.
>
> You can't accidentally pollute the namespace if the file doesn't get
> loaded by default. One of the reasons we have "require" and
> "require_relative".
Quite true. #require_relative is a great feature of 1.9. There's still
requiring from other libraries though, and if some one follows bad
practices the wrong file can get loaded.
> > That's not it. The suggestion I am making moves beyond the simple path
> > system Ruby now uses. It would require that Ruby understand packages.
> > So it's not "still along the path".
>
> Please. Then I just define a package, put that someplace first in the
> loadpath, and *boom*, your system blowing up in your face again.
That's not how it works. You can't put something first in the load
path. Rather than a simple list of paths, such a system uses a table
of { 'packgname' => 'path/to/package' }. Actually it's a little more
complicated than that b/c of versions and internal require_paths
settings but that's the basic idea.
> >> Which your system doesn't mitigate against at all. And it cannot, ever
> >> (nor does Bundler: It is a poor man's version and dependency control).
> >> Once code is on a machine, it can do whatever it wants. Ruby just
> >> makes it easier to modify its own classes, but the vector is still
> >> there: external code executed locally.
>
> > Yes it does. I use it all the time. I wrote such a system and use if
> > for development.
>
> Every programmer can invent a cypher he, himself, cannot break, as well.
>
> Unless you wrote your own OS that allows only the execution of
> specifically whitelisted binaries *and* script files (you have to
> prevent arbitrary code execution within a Ruby interpreter, too, after
> all, and just whitelisting the Ruby binary won;t work for that), code
> that is running on your machine, can manipulate your machine.
>
> >> Without auditing code, you have no idea what the code does to your
> >> machine, and who prevents anyone from claiming "I'm part of Ruby's
> >> namespace"?
>
> > Ruby.
>
> How? Since Ruby can execute arbitrary OS-level commands with system()
> or ``, how can Ruby prevent namespace pollution?
I think we are talking about two different things. I'm only talking
about preventing the wrong file from being loaded. Not anything to do
with what's in a file.
Phillip Gawlowski
>
> It restricts where the file 'ostruct' can be found. In this case to
> ruby's standard library.
See below.
>> Please. Then I just define a package, put that someplace first in the
>> loadpath, and *boom*, your system blowing up in your face again.
>
> That's not how it works. You can't put something first in the load
> path. Rather than a simple list of paths, such a system uses a table
> of { 'packgname' => 'path/to/package' }. Actually it's a little more
> complicated than that b/c of versions and internal require_paths
> settings but that's the basic idea.
Since you need to check for a package in different places (user
specific and global *at the very least*), you have a load path of some
sort. As long as my package comes first, your system can be broken,
subverted, by my package.
> I think we are talking about two different things. I'm only talking
> about preventing the wrong file from being loaded. Not anything to do
> with what's in a file.
Of course it has to do with what is *in* the file. If you execute a
file that arbitrarily loads code (like a Ruby file, for example, since
the file's contents get executed on load time already), your system
can be subverted. So, you do a lot of work to prevent something that
you *cannot* prevent to begin with. Not without changing how operating
systems work these days (i.e. instead of executing everything that's
not blacklisted, only that which is whitelisted gets executed).
Ilias Lazaridis
> 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 word
>
> require '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.
> >http://lazaridis.com
>
> (Uh oh. I replied to Ilias! ;-)
(You will be punished with 37 spam mails)
.
Josh Cheek
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.
Ilias Lazaridis
> On Jun 11, 1:35 pm, 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 word
>
> > optional:
> > * ideally a 7 letter word
>
> Okay, I'm willing to respond to this
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.
.
Intransition
Steve Klabnik
Yep, that just re-introduces the security issue that had us remove . from $:
in the first place.
And I wrote a gem that backports require_relative to 1.8, so you can use it
everywhere. ;) http://rubygems.org/gems/require_relative
Intransition
On Jun 12, 11:35 am, Steve Klabnik <st...@steveklabnik.com> wrote:
> Yep, that just re-introduces the security issue that had us remove . from $:
> in the first place.
>
> And I wrote a gem that backports require_relative to 1.8, so you can use it
> everywhere. ;)http://rubygems.org/gems/require_relative
Hompage link seems to be broken
Is this in backports (https://github.com/marcandre/backports), btw?
I'm wondering if I can just start doing 1.9+ only from now on, and if
the end user wants to use my stuff with 1.8.x they can add RUBYOPT="-
rbackports", or something along those lines. Could something like that
do the job?
Steve Klabnik
>
> Hompage link seems to be broken
>
I'll get that fixed, thanks. Till then,
https://github.com/steveklabnik/require_relative
> Is this in backports (https://github.com/marcandre/backports), btw?
>
I believe that backports has it too, yes.
Ilias Lazaridis
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'
.
Luc Heinrich
> include 'lib/alter' # the commonly known "include"
> require 'alibrary'
You do know that 'include' is already used in Ruby. Right?
Right?!??
--
Luc Heinrich - l...@honk-honk.com
David Masover
> 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?
Ilias Lazaridis
> 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?!??
yes, to describe "mixing"
I realize that this would lead to confusion (or even collisions).
Any other word?
.
Ilias Lazaridis
require_relative 'lib/alter'
require './lib/alter'
To my understanding, both should do the same thing.
Is this right?
.
Michael Edgar
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?
>
> --
> http://lazaridis.com
>
No.
require_relative 'lib/alter'
require File.join(File.dirname(__FILE__), 'lib/alter')
those two are the same.
Michael Edgar
ad...@carboni.ca
http://carboni.ca/
Florian Gilcher
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.
Regards,
Florian
Ilias Lazaridis
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).
-
So it looks I can't drop require_relative.
And so I still need a shorter name.
.
Michael Edgar
> And so I still need a shorter name.
If *you* need a shorter name for some absurd reason, then *you* can simply do the
following:
module Kernel
alias locally require_relative
end
Where "locally" can be any name *you* wish!
Problem solved!
Michael Edgar
ad...@carboni.ca
http://carboni.ca
John W Higgins
Afternoon,
On Wed, Jun 15, 2011 at 12:58 PM, Michael Edgar <ad...@carboni.ca> wrote:
> On Jun 15, 2011, at 3:55 PM, Ilias Lazaridis wrote:
>
> > And so I still need a shorter name.
>
>
> If *you* need a shorter name for some absurd reason, then *you* can simply
> do the
> following:
>
Michael, you clearly didn't read the first message here..... Ilias wouldn't
ever need something this absurd - it's a "project manager" that needs this
alias.
Why would you ever think Ilias would need something foolish? Are you aware
of any past history that the rest of us are not?
John
Michael Edgar
> Michael, you clearly didn't read the first message here..... Ilias wouldn't
> ever need something this absurd - it's a "project manager" that needs this
> alias.
>
> Why would you ever think Ilias would need something foolish? Are you aware
> of any past history that the rest of us are not?
While I guess I deserve a (honestly delightfully) sarcastic reply for responding to
him, I was mainly picking on how he slipped up and said "I still need a shorter name."
Ilias Lazaridis
> On Jun 15, 2011, at 3:55 PM, Ilias Lazaridis wrote:
>
> > And so I still need a shorter name.
>
> If *you* need a shorter name for some absurd reason,
If something is absurd, than it's the fact that the name
"require_relative"
has made it into the core. For sure this was kind of an accident,
because everyone was busy or tired or something else.
Either it should be corrected soon to be a key*word*.
or at least, if multi-word, then it should be written more clearly:
"require_relative_to_this_file"
There are many ways to ruin a language.
Step by step, silently.
> then *you* can simply do the following:
>
> module Kernel
> alias locally require_relative
> end
I am aware of this mechanism.
> Where "locally" can be any name *you* wish!
But still, I need a concise name.
> Problem solved!
.
Ilias Lazaridis
"I still need a shorter name" for the project-manager.
(I'm unemployed, the project-manager is a fictional one, just to have
a more realistic use-case)
.
David Masover
> 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.
>
> 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).
Not really, no.
More like, the first works wherever I'd normally be hacking around with
__FILE__ to get a decent require path.
The second doesn't work at all, unless it's actually what you intend. For
instance, if I add a ruby script to my PATH as a command, and then run it,
what directory I happen to be in when I run it is what determines what the
second is relative to.
Even on Windows, the working directory isn't always where the main file is.
Ilias Lazaridis
> On Wednesday, June 15, 2011 02:55:31 PM Ilias Lazaridis wrote:
>
Yes, you're right.
I forgot those cases.
What is sure for me now is:
I need the functionality that "require_relative" provides.
.
David Masover
> On 15 Ιούν, 22:58, Michael Edgar <ad...@carboni.ca> wrote:
> > On Jun 15, 2011, at 3:55 PM, Ilias Lazaridis wrote:
> > > And so I still need a shorter name.
> >
> > If *you* need a shorter name for some absurd reason,
>
> If something is absurd, than it's the fact that the name
>
> "require_relative"
>
> has made it into the core. For sure this was kind of an accident,
> because everyone was busy or tired or something else.
Of course, because the only reason anyone would ever disagree with you is
because they're busy, tired, stupid, or the wrong "kind" of person.
> Either it should be corrected soon to be a key*word*.
It's not a keyword, it's a method. It's also far from the only two-word method
-- consider define_method or instance_variable_set.
> or at least, if multi-word, then it should be written more clearly:
>
> "require_relative_to_this_file"
At a certain point, you have to assume that if it isn't obvious from the
context what something does, people are willing to look it up. 'locally' isn't
any better in this regard -- in fact, it's significantly worse, since at least
we know what 'require' usually means.
The alternative is Java-like madness, where define_method is actually
define_method_on_this_class_with_this_block_I_pass_in_here.
> There are many ways to ruin a language.
Dramatic much?
require_relative couldn't ruin a language -- it barely even touches the
language, and can trivially be renamed or removed at runtime:
Kernel.send :remove_method, :require_relative
Oh, sorry, I guess that should be:
Kernel.send_method_call :remove_method_from_this_class :require_relative
Ilias Lazaridis
[...]
I've read everything, but I'll not comment.
Do me a favour, please.
Can you please try to find one word (ideally with 7 chars),
independent of you think about the need.
Just as an exercise.
-
I have too cook now!
.
Matt Harrison
> I'm unemployed
How very suprising, given your invaluable work "auditing" many languages.
John W Higgins
2011/6/15 Ilias Lazaridis <il...@lazaridis.com>
>
> (I'm unemployed, ....
>
Too easy, simply too easy.........
John
Phillip Gawlowski
>
> Too easy, simply too easy.........
>
> John
Well, Ilias' grasp of the English language isn't the best, so he
probably meant "I'm not employed by a company, but am self-employed".
And now I have to shower...
--
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
Adam Prescott
>
> or at least, if multi-word, then it should be written more clearly:
>
> "require_relative_to_this_file"
>
> There are many ways to ruin a language.
>
> Step by step, silently.
>
I can only assume that these two pairs of lines being next to each
other is a joke.
Ilias Lazaridis
wrote:
> On Thu, Jun 16, 2011 at 12:05 AM, John W Higgins <wish...@gmail.com> wrote:
>
> > Too easy, simply too easy.........
>
> > John
>
> Well, Ilias' grasp of the English language isn't the best, so he
> probably meant "I'm not employed by a company, but am self-employed".
You are right, I was to lazy to write.
Self-employed, but as I currently look for a contract, I'm kind of un-
(self-)employed, or self-unemployed or whatever.
The effect of "unemployed" and "self-unemployed" is essentially the
same (e.g. empty freezer), possibly with the difference (in my case)
that I am focused on personal projects, as long as I'm un-
(self)employed.
> And now I have to shower...
Good idea!
.
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
#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
.
Ilias Lazaridis
There's only one joke:
The processes which guide the evolution of the ruby language.
One could say: "Which processes, there are none."
Exactly, there are none.
And this is the joke.
.
Matt Harrison
You mean like "require_relative" which actually makes more sense than
your suggestions?
Phillip Gawlowski
>> Ilias, resident Abstract Programmer
>>
>> request 'lib/alter' # like require, but uses the path relative to the
>> current file
>
> You mean like "require_relative" which actually makes more sense than your
> suggestions?
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.
Ilias Lazaridis
> On 16/06/2011 13:40, 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
>
> > #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
>
> You 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?
-
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' #
.
Ilias Lazaridis
wrote:
> 2011/6/16 Matt Harrison <iwasinnamuk...@genestate.com>:
>
> >> Ilias, resident Abstract Programmer
>
> >> request 'lib/alter' # like require, but uses the path relative to the
> >> current file
>
> > You mean like "require_relative" which actually makes more sense than your
> > suggestions?
>
> Especially since "request" sounds to me like "would be nice to have,
> but not really important to my core functionality".
I agree.
Additionally, "request" brings up the http request stuff.
So it looks "request" is invalid, too.
.
Matt Harrison
You don't seem to understand that you are arguing against the
descriptive nature of the "require_relevant" method name, yet in your
own words above you use those two words to describe it. This in itself
proves that the method name works, is sensible and suitably descriptive.
As said before, this isn't going to change. If you don't like it, or
your "project manager" doesn't like it, then alias it and be done.
If this really was the requirement of a project manager, I'd hope he
realised he's wasted the resources in having you argue this non-issue.
Phillip Gawlowski
>
> You don't seem to understand that you are arguing against the descriptive
> nature of the "require_relevant" method name, yet in your own words above
> you use those two words to describe it. This in itself proves that the
> method name works, is sensible and suitably descriptive.
On Ilias:
"[Ilias] soon started posting long tirades where he `proved' that the
CL standard requires various behaviour, while completely ignoring the
detailed rebuttals of his `proofs'. An example is the long series of
articles where he `proves' that merely copying the syntax of #\( and
#\) to, say #\[ and #\] should cause [ ... ] to be legal syntax,
despite multiple explanations by four or more people of why this
cannot work. He has also a number of other strange ideas, mostly
syntactic in nature - for instance he doesn't like the . in
dotted-list syntax, and doesn't understand how the , unquoteing syntax
works, and has argued, again, that the standard implies things that
mean that no implementation is conforming."
And:
"He is obsessed by the minutiae of syntax and apparently uninterested
in actually writing programs - he needs to invent some `perfect'
language before he can do anything, and he's starting with the syntax.
It seems quite likely that he's just trying to avoid doing anything at
all by endlessly fiddling with syntax."
Now *that* sounds familiar, doesn't it?
From: http://www.tfeb.org/lisp/mad-people.html
To cut a long story short: Ilias can't program, won't program, and is
a liability to everyone, particularly his "clients". Until proven
otherwise, Ilias claimed experience in coding is n x 1 year of actual
experience, if that.
Matthew K. Williams
> As said before, this isn't going to change. If you don't like it, or your
> "project manager" doesn't like it, then alias it and be done.
>
> If this really was the requirement of a project manager, I'd hope he realised
> he's wasted the resources in having you argue this non-issue.
He's admitted that the "project manager" is a hypothetical one. In other
words, it's a strawman argument. (or more aptly a sock puppet?)
Phillip Gawlowski
>
> He's admitted that the "project manager" is a hypothetical one. In other
> words, it's a strawman argument. (or more aptly a sock puppet?)
Naw, a sock puppet would require Ilias to be clever enough to create a
persona that posts this requirement and/or supports his harebrained
schemes.
Ilias Lazaridis
> On 16/06/2011 16:10, Ilias Lazaridis wrote:
>
REQUOTE:
""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?
"
It seems that it's just to difficult.
.
Matthew K. Williams
> [...] - (off-context babbing)
>
This is rude. You don't have to quote it if you don't want, but calling
it babbling? Rude.
> REQUOTE:
>
> ""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?
> "
>
> It seems that it's just to difficult.
>
You know, this was solved days ago via an alias, but that wasn't good
enough for you. Moreover, you're rude to people.
Enough. Killfile time.
Matt
Ilias Lazaridis
> On Fri, 17 Jun 2011, Ilias Lazaridis wrote:
> > [...] - (off-context babbing)
>
> This is rude. You don't have to quote it if you don't want, but calling
> it babbling? Rude.
>
> > REQUOTE:
>
> > ""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?
> > "
>
> > It seems that it's just to difficult.
>
> You know, this was solved days ago via an alias, but that wasn't good
> enough for you.
alias abcdefg require_relative
This does not solve it, I need the concise word.
> Moreover, you're rude to people.
Of course. I'm rude, and the freak-show that
a) has hijacked the thread at the beginning
b) continues with off-topic comments and start again to become
personal.
those are not rude, but civilized.
> Enough. Killfile time.
At least you know how to use filters.
> Matt
.
Matt Harrison
> On 16 οΏ½οΏ½οΏ½οΏ½, 19:45, "Matthew K. Williams"<m...@harpstar.com> wrote:
>> You know, this was solved days ago via an alias, but that wasn't good
>> enough for you.
>
> alias abcdefg require_relative
>
> This does not solve it, I need the concise word.
Then this is the wrong list. ruby-talk does not exist to cover prose or
literary matters. What you need is a thesaurus.
Ilias Lazaridis
> On 16/06/2011 17:55, Ilias Lazaridis wrote:
>
> >> You know, this was solved days ago via an alias, but that wasn't good
> >> enough for you.
>
> > alias abcdefg require_relative
>
> > This does not solve it, I need the concise word.
>
> Then this is the wrong list. ruby-talk does not exist to cover prose or
> literary matters. What you need is a thesaurus.
This is the correct list for my request.
What I need is, just a few more professionals with have the ability to
stay strictly in topic, or to shut up.
But I guess I have to give up the hope that some will pop up.
.
Jason Roelofs
If you *want* professionalism, you have to *be* professional yourself, something that you very rarely show. This huge thread has given you more than what you "need". Come up with something yourself instead of trying to waste anyone else's time here.
Jason
Phillip Gawlowski
>
> If you *want* professionalism, you have to *be* professional yourself, something that
> you very rarely show. This huge thread has given you more than what you "need".
> Come up with something yourself instead of trying to waste anyone else's time here.
If it wouldn't set a bad precedent, I'd be arguing to simply *ban*
Ilias, nd be done with it. He's gone above and beyond the call of duty
as a troll. He could get the Trollish Medal of Honor, as far as I am
concerned.
As it is, I'm sorely wishing GMail could filter individual messages in
conversation view--disabling conversations isn't a workable solution,
and I don't always have access to an email client, much less one that
supports filtering. Alas.
Ilias Lazaridis
> On Jun 16, 2011, at 1:50 PM, Ilias Lazaridis wrote:
>
> > On 16 Ιούν, 20:26, Matt Harrison <iwasinnamuk...@genestate.com> wrote:
> >> On 16/06/2011 17:55, Ilias Lazaridis wrote:
>
> >>> On 16 , 19:45, "Matthew K. Williams"<m...@harpstar.com> wrote:
> >>>> You know, this was solved days ago via an alias, but that wasn't good
> >>>> enough for you.
>
> >>> alias abcdefg require_relative
>
> >>> This does not solve it, I need the concise word.
>
> >> Then this is the wrong list. ruby-talk does not exist to cover prose or
> >> literary matters. What you need is a thesaurus.
>
> > This is the correct list for my request.
>
> > What I need is, just a few more professionals with have the ability to
> > stay strictly in topic, or to shut up.
>
> > But I guess I have to give up the hope that some will pop up.
>
How disappointing.
One more off-topic.
And just *one* (yes, just *one*) in-topic and in-context reply
(suggesting a word) in the overall thread.
A tragedy.
.
Ilias Lazaridis
wrote:
> On Thu, Jun 16, 2011 at 8:24 PM, Jason Roelofs <jameskil...@gmail.com> wrote:
>
> > If you *want* professionalism, you have to *be* professional yourself, something that
> > you very rarely show. This huge thread has given you more than what you "need".
> > Come up with something yourself instead of trying to waste anyone else's time here.
>
> If it wouldn't set a bad precedent, I'd be arguing to simply *ban*
> Ilias, nd be done with it. He's gone above and beyond the call of duty
> as a troll. He could get the Trollish Medal of Honor, as far as I am
> concerned.
The "Trollish Medal of Honor" goes to the self-proclaimed "Ruby Talk
Police".
You are the ones which are "trolling" (off-topic, hijacking threads,
personal nonsense, ridiculous and *endless* babbling subjecting an
individuals personal writing style).
But I start to believe that finally this *is* the ruby community
(because until now, I saw only 2 people intervene, with not more than
3 messages).
> As it is, I'm sorely wishing GMail could filter individual messages in
> conversation view--disabling conversations isn't a workable solution,
> and I don't always have access to an email client, much less one that
> supports filtering. Alas.
Why don't you simply relay my messages to the trash?
"More actions"
"Filter messages like these"
or
"More actions"
"Mute"
(I write only in my topics, thus it's easy for everyone to place a
filter (based on topic title).)
.
Joe Peric
I'm new to Ruby and finding the language pretty neat.
I think this might help in solving Ilias' problem of finding a word:
enum = ('aaaaaaa'..'zzzzzzz').to_enum
enum.each do |word|
puts word + "\n"
end
He can go through each one and find what he likes.
You're welcome. ;)
Mike Moore
The OP asked for comments on the proposal for a new, more descriptive name
for "require_relative". I have a hard time remembering if it is
"require_relative" or "relative_require", which causes me pain and grief
whenever I reach for "require_relative" as I'm coding. Because of this I
would like to leave my comment.
As I understand it, "require_relative" was introduced because of a
fundamental change to LOAD_PATH in Ruby 1.9. Having the current directory in
the LOAD_PATH was deemed to be a problem, and was removed for security
concerns and a sense of correctness. This meant that "require" would no
longer load files based on where the loading files location. Now, obviously,
this caused issues because behavior was changed, and a way was needed to fix
the broken code. Hence "require_relative" was introduced as the solution.
The stated question that began this thread is what alternative to
"require_relative" would you choose, asking only that the new single word
was 7 characters or less. I have a word in mind, but let me first
hypothesize on why "require_relative" was chosen in the first place. On the
surface having a multi-word name for this functionality seems to go counter
intuitive to Ruby's ease and flow that we all love. Why would something so
basic have a name that was so uncomfortable? As I said earlier, I have a
hard time even keeping the name right in my head! Why would the Ruby culture
create and propagate something so out of place and ill-tasting?
Why indeed. I have given this much thought. I have pondered on this subject
throughout the interactions on this thread. Why is it so wordy? Almost
overly descriptive? Where is the sweetness I am used to? Why hasn't Ruby
opened her arms to embrace me with her syntactic sugar? Why? Why Matz, why?
Could it be that "require_relative" is just a bad idea? Could it be that
"require_relative" was left intentionally wordy as some sort of syntax
vinegar to push people away from using that functionality? Not a punishment
per se, but a subtle reminder that something is wrong with the assumptions
that the code is making? A sore thumb on otherwise healthy code? But if that
is the case, then what shorter name can we give to "relative_require" that
would still communicate how ill-fitting and out of place the functionality
is to Ruby? Preferably in 7 characters or less?
My friends, I have the answer:
alias ilias require_relative
I sincerely hope my suggestion, a single word with 7 characters or less, can
help bring some closure to this topic.
~Mike
Ilias Lazaridis
[...]
I guess it's time to give up.
It's just to much off-topic trolling.
.
Mike Moore
2011/6/16 Ilias Lazaridis <il...@lazaridis.com>
> I guess it's time to give up.
>
> It's just to much off-topic trolling.
>
Trolling? I'm offended! I am certainly not trolling. My message was very
on-topic. And my suggested solution works. I even tested it and everything.
Sam Duncan
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
>
> .
>
> --
> http://lazaridis.com
>
Mike Moore
On Thu, Jun 16, 2011 at 2:17 PM, Sam Duncan <sdu...@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.
Ilias Lazaridis
Ilias Lazaridis
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' #
.
Sam Duncan
And furthermore, you can't read.
optional:
* ideally a 7 letter word
Who is the real troll here?
Mike Moore
On Thu, Jun 16, 2011 at 2:30 PM, Sam Duncan <sdu...@wetafx.co.nz> wrote:
> You can't count.
>
> And furthermore, you can't read.
>
>
> optional:
> * ideally a 7 letter word
>
> Who is the real troll here?
Why are you guys picking on me? I gave you a perfectly acceptable solution!
Phillip Gawlowski
> You can't count.
>
> And furthermore, you can't read.
It *is* seven letters.
Of course, it suffers from a glaring similarity with the include
keyword, hinting more at extension of something that exists, rather
than the requirement of something, but you win some and you lose some.
Adam Prescott
On 16 Jun 2011 21:30, "Ilias Lazaridis" <il...@lazaridis.com> wrote:
> >
> > involve
>
> This one sounds good!
>
> I think I've a new favourite!
>
70 messages in and the topic becomes clear: entertain me with 7-letter
words.
Ilias Lazaridis
Phillip Gawlowski
>
> What becomes clear is this: who are the trolls.
Your bad English is showing: Troll. Singular.
Matt Harrison
I really wish I could be there when you go for a job interview, or
attempt to bid on a contract and they recognise your name. I guess the
archives for list this (or anywhere you have infected) would be the best
resume ever...for warning the employer. Maybe that's already happened
and this is misplaced vengeance.
Mike Moore
On Thu, Jun 16, 2011 at 2:55 PM, Ilias Lazaridis <il...@lazaridis.com>wrote:
>
> What becomes clear is this: who are the trolls.
>
That is the second time you implied I was a troll. Even after I told you
directly that I am not a troll. I don't understand why you would do this.
You don't know me. I did nothing but try to help you and yet you repay my
kindness with libel? This defamation will not stand!
Matt Harrison
> On Thu, Jun 16, 2011 at 2:55 PM, Ilias Lazaridis<il...@lazaridis.com>wrote:
>
>>
>> What becomes clear is this: who are the trolls.
>>
>
> That is the second time you implied I was a troll. Even after I told you
> directly that I am not a troll. I don't understand why you would do this.
> You don't know me. I did nothing but try to help you and yet you repay my
> kindness with libel? This defamation will not stand!
I would throw some legal threats at him. Look at his previous posts if
you're not sure how.
Myself, I'm still waiting to see when we're all getting sued for
libelling him...should be exciting.
Ilias Lazaridis
"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".
-
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!
.
Ilias Lazaridis
> Hey everyone.
>
> I'm new to Ruby and finding the language pretty neat.
>
> I think this might help in solving Ilias' problem of finding a word:
>
> enum = ('aaaaaaa'..'zzzzzzz').to_enum
>
> enum.each do |word|
> puts word + "\n"
> end
>
> He can go through each one and find what he likes.
>
> You're welcome. ;)
Ah!
A creative Off-topic-Troll.
You'll made a career on this list!
> > The "Trollish Medal of Honor" goes to the self-proclaimed "Ruby Talk
> > Police".
>
> > You are the ones which are "trolling" (off-topic, hijacking threads,
> > personal nonsense, ridiculous and *endless* babbling subjecting an
> > individuals personal writing style).
>
> > But I start to believe that finally this *is* the ruby community
> > (because until now, I saw only 2 people intervene, with not more than
> > 3 messages).
.
Phillip Gawlowski
>
> A creative Off-topic-Troll.
>
> You'll made a career on this list!
Feel free to leave. Go with God, but go.
David Masover
> On 16 Ιούν, 00:36, David Masover <ni...@slaphack.com> wrote:
> [...]
>
> I've read everything, but I'll not comment.
>
> Do me a favour, please.
Let me think... no. You haven't even been cooperative when I have been trying
to give you the best answer to your question, by at least providing enough
context so that I understand why it's a real problem. And it gets more
personal from there.
> Can you please try to find one word (ideally with 7 chars),
> independent of you think about the need.
>
> Just as an exercise.
As "just an exercise", it's a pointless waste of time. At best, it might
enhance my vocabulary, which doesn't need the help. It also doesn't look like
fun. About the only other reason I'd do it as "just an exercise" is as a favor
to you, and given your conduct so far, replying to you is already a favor.
What I would be happy to do is discuss why this is needed, and how/whether to
get it included into the core, or what a good name might be outside of your
artificial one-word-7-char constraint.
But I'm not going to jump through hoops just because you say so.
I'd normally refuse to do so even for people I respect.
David Masover
> 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.
I can't resist...
Remember this, Ilias?
On Monday, May 23, 2011 05:35:26 AM Ilias Lazaridis wrote:
> I hope you are aware that you have already crossed moral and legal
> lines.
[...]
> I hope that the professionals within this group will intervene at some
> point, if the "attacks" on my person continue.
And then:
On Monday, May 23, 2011 07:00:30 AM Ilias Lazaridis wrote:
> You may want to research for "Defamation" / "Defamation of Character".
Your English skills aren't a problem; after all, Matz has good but not
flawless English also. Your conduct is... well, I suppose we can now add
"hypocritical" to the list.
David Masover
> "He is obsessed by the minutiae of syntax and apparently uninterested
> in actually writing programs - he needs to invent some `perfect'
> language before he can do anything, and he's starting with the syntax.
> It seems quite likely that he's just trying to avoid doing anything at
> all by endlessly fiddling with syntax."
>
> Now *that* sounds familiar, doesn't it?
Indeed it does, and this is probably why I respond to him as much as I do,
because I started out the same way.
This is going to be a long one. I'll try not to tell this story more than
once, because it's so long, and borders on actually being offtopic.
I wanted a language which was "fast enough", where "fast enough" meant "at
least as fast as Java, and better if it can approach C++", which compiled to
portable bytecode, preferrably bytecode for VMs people are likely to have
(Java or .NET) but a new VM would be acceptable, could run in 32-bit or 64-bit
modes, had flexible syntax with minimal verbosity, was extremely dynamic
semantically but ran as fast as static code, handled unicode well, had good
multiprocessing primitives (like Erlang)...
The list goes on. And on. And on.
I rejected Ruby at first because it was "too slow", and because I didn't see a
way it could be much faster, especially because I didn't quite understand the
difference between symbols and strings. Also, it runs from source, and didn't
seem to have any good compilers -- at the time, I thought I wanted to do game
development, and while I wanted my game to be almost automatically portable
(compile once, run anywhere, so I don't have to convince anyone to let me make
a Linux version), I also didn't want to actually ship source.
While I suppose I had a good rationale for almost every question I asked, I
followed a very similar pattern to Ilias. I'd get annoyed when people would
answer my real question instead of the one I asked, because then we'd be
arguing about architecture, not realizing how much I had to learn about that.
I would also wander from group to group -- I'm not sure I ever made an
appearance on Ruby-Talk directly, but I suspect I hit the IRC channel at some
point. I was really excited about Perl6 before it really was anything
resembling an actual language. I tried Squeak, and rejected it because 64-bit
support was experimental, and it seemed that it might be difficult to port
software between 32-bit and 64-bit, and even if it would work perfectly
eventually, the amount of work it was taking them to make a 64-bit Squeak VM
suggested that either the language was too difficult to port or the community
was too small to react to these kinds of changes in technology.
Basically, I spent my teenage years like this. I would often be tempted to
reinvent various wheels, and I still am.
But when it came down to it, when I really had to, I could program. It started
off really sloppy, and I actually still occasionally support programs I wrote
as a teenager. Still, I was able to get things done, at first mostly in Perl,
just little things, avoiding any project big enough that it would warrant The
Perfect Language.
The turning point was probably my first programming job, at a startup. For the
first time, I was forced to work with other people, and to actually program
roughly 8 hours a day, every day. For the first six months or so, it was
entirely JavaScript, running on HD-DVDs. For the next six months or so, it was
mostly Ruby -- Blu-Ray won, but we took our Rails backend for the HD-DVD stuff
and adapted it into a music widget.
The second time through, I saw a lot more of Ruby's brilliance. Plus, the
performance had improved significantly, to the point where it was still common
knowledge that "Ruby is Slow", but I could no longer see any major design
decisions which made Ruby _pointlessly_ slow -- any decisions that would tend
to make implementations slow weren't just carelessness, they were deliberate
tradeoffs between performance and programmer productivity.
I had to learn, the hard way, that there is no "perfect" language. While I can
think of some things I wish some language did that no languages do yet, I no
longer believe that there could ever be a language which is semantically
"better" than all other languages in all ways. One thing many people on this
list will be familiar with is Ruby vs JavaScript -- and I have to say, there
are tons of things I miss about each in the other, and some of them are
mutually exclusive. I like that every interaction with an object in Ruby is
actually sending it a message (a method call, usually), but that's
incompatible with JavaScript's idea that objects are just hashes of methods
and values.
That, and I actually learned to program.
The biggest change in my thinking now is that, when I was a teenager asking
the kind of questions Ilias does, I wasn't speaking from experience where a
given construct actually bothered me. It just bothered me from some idealistic
standpoint which had no connection to any program I have ever or will ever
write. These days, when I complain that (for example) autoload didn't actually
call the system require, I actually do have a good reason for wanting to
intercept the behavior of autoload.
That is, I've gone from being an idealistic, dogmatic, theoretical programmer
to being an actual, practicing, empirical programmer. It just took me five or
ten years, and I probably made some enemies along the way.
So as rude and arrogant as he is, and as little as he deserves (or wants) my
pity, it's kind of painful for me to see Ilias making the exact same mistakes
I did, and then grew out of -- and frustrating when he refuses to hear a word
of it.
Hopefully this is useful, or at least interesting. Thanks for your patience,
whoever's actually read this far. At the very least, now you see why it's so
hard for me to actually not feed this troll.
Ryan Davis
On Jun 16, 2011, at 23:49 , David Masover wrote:
> [...the actually interesting bits...]
>
> So as rude and arrogant as he is, and as little as he deserves (or wants) my
> pity, it's kind of painful for me to see Ilias making the exact same mistakes
> I did, and then grew out of -- and frustrating when he refuses to hear a word
> of it.
>
> Hopefully this is useful, or at least interesting. Thanks for your patience,
> whoever's actually read this far. At the very least, now you see why it's so
> hard for me to actually not feed this troll.
Yeah... but...
% curl -s http://legacy.lazaridis.com/resumes/lazaridis.html | grep -i years
<li>20 years - Solving Technical Problems Abstractly </li>
<li>18 years - IT Business </li>
<li>15 years - Software Developement </li>
<li>12 years - Product Management </li>
<li>10 years - Digital Electronic Design </li>
<li>05 years - Public System Analysis (Open Source Domain) </li>
(not that I believe Ilias)
Kane Williams
unsubscribe
> Date: Fri, 17 Jun 2011 15:19:57 +0900
> From: ni...@slaphack.com
> Subject: Re: RFC - One word alias for require_relative
> To: ruby...@ruby-lang.org
Ilias Lazaridis
> On Jun 16, 2011, at 23:49 , David Masover wrote:
[...] - (story of Mr. Masover's live, which I've not read)
> > So as rude and arrogant as he is, and as little as he deserves (or wants) my
> > pity, it's kind of painful for me to see Ilias making the exact same mistakes
> > I did, and then grew out of -- and frustrating when he refuses to hear a word
> > of it.
>
> > [...the actually interesting bits...]
>
> > Hopefully this is useful, or at least interesting. Thanks for your patience,
> > whoever's actually read this far. At the very least, now you see why it's so
> > hard for me to actually not feed this troll.
Wow, this (off-topic, off-context, my-personal-experiences-to-others-
by-brute-force) Troll is really a special one.
Get serious, Mr. Masover.
The only troll you feed is yourself.
And it seems that I make you very hungry.
> Yeah... but...
>
> % curl -shttp://legacy.lazaridis.com/resumes/lazaridis.html| grep -i years
> <li>20 years - Solving Technical Problems Abstractly </li>
> <li>18 years - IT Business </li>
> <li>15 years - Software Developement </li>
> <li>12 years - Product Management </li>
> <li>10 years - Digital Electronic Design </li>
> <li>05 years - Public System Analysis (Open Source Domain) </li>
>
> (not that I believe Ilias)
$ CopyAndPaste -shttp://lazaridis.com/244.html
25 years - IT Business, Solving Technical Problems Abstractly
15 years - Software Developement
10 years - Digital Electronic Design & Product Management
05 years - Public System Analysis (Open Source Domain)
.
KlausG
> "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?
>
No, it's easy. Here are some 7 letter words:
1000.times.collect { 7.times.inject("") { |w,c| w <<
(97+rand*26).to_i.chr } }
Choose one that suits you and use it with the alias method
--klaus
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
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
-
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.
.
Ilias Lazaridis
I am *responding* to "collaborative trolling attacks".
No defamation at all.
It is now within the archives:
You and the others, are... trolling within my threads.
You *are* the real trolls, by definition.
Simple as that.
.
Ilias Lazaridis
>
> > [...]
>
> > I've read everything, but I'll not comment.
>
> > Do me a favour, please.
> > Can you please try to find one word (ideally with 7 chars),
> > independent of you think about the need.
>
> > Just as an exercise.
Clearly kind of off-topic/off-context obsessed.
Dismissed!
.
Gary Wright
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__
Gary Wright
On Jun 17, 2011, at 2:21 PM, Chad Perrin wrote:
> I had no idea about "require!". Thanks for mentioning it.
It doesn't exist, I was just suggesting it as a possibility...
Gary Wright
Matthew K. Williams
> Damn. Okay, never mind.
>
> Of course, I'll just be happy with require_relative, anyway. It seems
> quite descriptive of its functionality, and succinct enough for my
> purposes.
Exactly. While I'm an old unix hack, I really like the descriptiveness of
this method. I know *exactly* what it's doing, without having to learn
some new obscure word.
Matt
Ryan Davis
One problem ilias... that's _not_ a resume (resumes actually mention companies) and nobody here believes a word of it. You couldn't code yourself out of a wet paper bag if your life depended on it (in _any_ language).
Ilias Lazaridis
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".
.
Ilias Lazaridis
[...]
> >> % curl -shttp://legacy.lazaridis.com/resumes/lazaridis.html|grep -i years
> >> <li>20 years - Solving Technical Problems Abstractly </li>
> >> <li>18 years - IT Business </li>
> >> <li>15 years - Software Developement </li>
> >> <li>12 years - Product Management </li>
> >> <li>10 years - Digital Electronic Design </li>
> >> <li>05 years - Public System Analysis (Open Source Domain) </li>
>
> >> (not that I believe Ilias)
>
> > $ CopyAndPaste -shttp://lazaridis.com/244.html
>
> > 25 years - IT Business, Solving Technical Problems Abstractly
> > 15 years - Software Developement
> > 10 years - Digital Electronic Design & Product Management
> > 05 years - Public System Analysis (Open Source Domain)
>
> One problem ilias... that's _not_ a resume (resumes actually mention companies)
Is this so? I've seen many which mention the employers/customers
anonymous, with an "references on request".
> and nobody here believes a word of it.
I don't care what the masses think and believe, especially those of
your kind.
> You couldn't code yourself out of a wet paper bag if your life depended on it (in _any_ language).
You're getting ordinary.
You can do better.
(but the thread is now closed, possibly in the next one)
.
Phillip Gawlowski
>
> Is this so? I've seen many which mention the employers/customers
> anonymous, with an "references on request".
You worked only on NDA'd projects for 20 years, and you can't even
mention past *clients*? Yeah, right.
>> You couldn't code yourself out of a wet paper bag if your life depended on it (in _any_ language).
>
> You're getting ordinary.
Well, let's get a little less ordinary: Why did you leave Siemens a
year after finishing your training as electrician? Provide the
Arbeitszeugnis[0] of your time at Siemens.
What happened to your first attempt at self-employment? Provide the
name and (expired by now, alas) registration of the business, or the
district court where the business was registered.
What's your further education after you made it to journeyman electrician?
Why didn't you decide to visit a Fachhochschule[1] to gain academic credentials?
What are your certifications in programming, program management, and design?
Until proven otherwise, we are free to assume that:
A) Siemens fired you (an extraordinary event back in the late 1980s,
since Siemens was like Japanese car makers in that time: If you were
good, you were set for *life*).
B) You don't have any credentials in software development.
C) You aren't qualified to be admitted to a Fachhochschule.
D) You never worked since you were fired by Siemens, living off of
unemployment grants.
Explanations for non-Germans:
[0] An Arbeitszeugnis is a diploma of sorts which details how well--or
not--an employee behaved and worked during their time at an employer.
It's by no means confidential (though private, and Ilias can't be
compelled to provide the Arbeitszeugnis).
[1] A Fachhochschule is roughly equivalent to a technical college in
the US, and allows those without the necessary credentials in second
level education (called "Fachhochschulreife", which is usually *not*
attained if you visited a lower rung,
not-very-intellectually-demanding school called "Hauptschule", or if
one wasn't good enough to visit the 10th year of schooling at a
"Realschule") to attain a degree in a field related to their trained
job after some time spent working in their learned field. Usually,
expertise can be provided in a less formal manner, for example
references to clients that one worked for, if one wants to study in a
field that one didn't train in.
Jason Roelofs
>> and nobody here believes a word of it.
>
> I don't care what the masses think and believe, especially those of
> your kind.
Yes, EVERYONE in this list already knows this, Ilias. But it makes one wonder, if you don't care about what people like us think and believe, why are you even here in the first place?
If only you were capable of ever listing to yourself, much less anyone else, the world would have been saved your inane trolling. But alas, this is simply entertainment now. The question now is: How far can Ilias go in self-affirming his own uselessness?
Of course for myself the definition of insanity comes to mind. No-one can show Ilias who he really is, so I shall stop trying.
Jason
Tony Arcieri
2011/6/17 Ilias Lazaridis <il...@lazaridis.com>
> 05 years - Public System Analysis (Open Source Domain)
>
That's quite the euphemism for "trolling mailing lists". I'd say the fact
you put it on your resume makes you a professional troll, but professionals
get paid.
--
Tony Arcieri
Ilias Lazaridis
wrote:
[...]
What about this:
I'm a 13year old kid, which likes to play with the regulars on the
language forums.
Now, the thread has reached 100 posts, its _really_ time to close it.
Have fun, confused soul!
.