From: Intransition Date: 2012-06-14T03:01:23+09:00 Subject: Re: require_relative? why didn't we "relative do" ------=_Part_1442_15583251.1339610481069 Content-Type: multipart/alternative; boundary="----=_Part_1443_15373150.1339610481069" ------=_Part_1443_15373150.1339610481069 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, June 13, 2012 10:40:08 AM UTC-4, Bartosz Dziewo=C5=84ski wrot= e: > > What for? This is needlessly munging a global variable. Also, if one=20 > of the required scripts also happen to require something, it will=20 > become a relative require, too. (Unless you add some magical guard=20 > code for this, and then we're on a slippery slope.)=20 > Ah good point. It wouldn't become relative exactly, but it could (however= =20 unlikely) conflict name wise. However, since one is requiring relative to a= =20 current file it is more likely that one would be aware of any such issue.= =20 Say a local `ostruct.rb` file when one actuall wants the ruby one. To clarify my implementation concept was something along the lines of: def relative(&block) dir =3D File.dirname(eval('__FILE__', block.binding)) $LOAD_PATH.unshift(dir) block.call $LOAD_PATH.delete(dir) end Obviously that would need to be improved upon, but that conveys the idea of= =20 it. Anyway, you are probably correct. It just struck me b/c a pure Ruby=20 implementation of #require_relative is not very robust as it has to use=20 `caller`, so I think its interesting that this block form never cropped up= =20 before. If it had, I wonder if #require_relative ever would have come about= =20 --there was such resistance to it by matz for so long. ------=_Part_1443_15373150.1339610481069 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, June 13, 2012 10:40:08 AM UTC-4, Bartosz Dziewo=C5=84= ski wrote:
What for? This is ne= edlessly munging a global variable. Also, if one
of the required scripts also happen to require something, it will
become a relative require, too. (Unless you add some magical guard
code for this, and then we're on a slippery slope.)

Ah good point. It wouldn't become relative exactl= y, but it could (however unlikely) conflict name wise. However, since one i= s requiring relative to a current file it is more likely that one would be = aware of any such issue. Say a local `ostruct.rb` file when one actuall wan= ts the ruby one.

To clarify my implementation concept was some= thing along the lines of:

    def relative(&block= )
      dir =3D File.dirname(eval('__FILE__', b= lock.binding))
      $LOAD_PATH.unshift(dir)
&nbs= p;     block.call
      $LOAD_PATH.de= lete(dir)
    end

Obviously that would need to be impro= ved upon, but that conveys the idea of it.

Anyway, you are probably = correct. It just struck me b/c a pure Ruby implementation of #require_relat= ive is not very robust as it has to use `caller`, so I think its interestin= g that this block form never cropped up before. If it had, I wonder if #req= uire_relative ever would have come about --there was such resistance to it = by matz for so long.



------=_Part_1443_15373150.1339610481069-- ------=_Part_1442_15583251.1339610481069--