From: "Michael T. Richter" Date: 2007-08-31T23:18:11+09:00 Subject: Re: Weird problem with DATA and __END__ --=-9+k0UV1R9uoYnKHQ4Jiq Content-Type: multipart/alternative; boundary="=-UE+4vUcO9mnZH5Wtmqtf" --=-UE+4vUcO9mnZH5Wtmqtf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, 2007-31-08 at 22:48 +0900, Florian A=C3=9Fmann wrote: > Hi Michael, >=20 > 1. DATA *constant* becomes defined: > DATA.inspect # =3D> "This is the data in test1.rb." > > require 'test2' > *snip* > 2. test2 becomes loaded > 3. test2 reads lines from DATA(0) to DATA(EOF) and puts them > >> puts "test2.rb =3D " + DATA.readlines.to_s >=20 > test2.rb =3D This is the data in test1.rb. >=20 > >> # ignored unless it's called first > >> __END__ > >> This is the data in test2.rb. > *snip* > 4. test1 reads lines from DATA(EOF) to DATA(EOF) and puts them > > puts "test1.rb =3D " + DATA.readlines.to_s >=20 > test1.rb =3D >=20 > > __END__ > > This is the data in test1.rb. >=20 > Your dealing with a constant here, you should expect that it won't change= . Ok, > you maybe expected that the require behaves like the ruby-bin... OK, that makes a twisted sort of sense, but... I *REALLY* do not like this. At all. Not just because it royally screws what I'm working on (although I may have a slightly clumsier workaround) but also because it means any libraries I require in my code can suck up my __END__ data. I would have expected the DATA constant to be localized in some way to the language unit it's being used in, not passed around freely like some kind of depraved party girl. And what's the "ruby-bin"? --=20 Michael T. Richter (GoogleTalk: ttmrichter@gmail.com) All really first class designers are both artists, engineers, and men of a powerful and intolerant temper, quick to resist the least modification of the plans, energetic in fighting the least infringement upon what they regard as their own sphere of action. (Nevil Shute) --=-UE+4vUcO9mnZH5Wtmqtf Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, 2007-31-08 at 22:48 +0900, Florian Aßmann wrote:

Hi Michael,

1. DATA *constant* becomes defined:
DATA.inspect # =3D> "This is the data in te=
st1.rb."
>     require 'test2'
*snip*
2. test2 becomes loaded
3. test2 reads lines from DATA(0) to DATA(EOF) and =
puts them
>>     puts "test2.rb =3D " + DATA.=
readlines.to_s

test2.rb =3D This is the data in test1.rb.

>> # ignored unless it's called first
>>     __END__
>>     This is the data in test2.rb.
*snip*
4. test1 reads lines from DATA(EOF) to DATA(EOF) an=
d puts them
>     puts "test1.rb =3D " + DATA.read=
lines.to_s

test1.rb =3D

>     __END__
>     This is the data in test1.rb.

Your dealing with a constant here, you should expec=
t that it won't change. Ok,
you maybe expected that the require behaves like th=
e ruby-bin...

OK, that makes a twisted sort of sense, but... I *REALLY* do not like= this. At all. Not just because it royally screws what I'm work= ing on (although I may have a slightly clumsier workaround) but also becaus= e it means any libraries I require in my code can suck up my __END__ data.&= nbsp; I would have expected the DATA constant to be localized in some way t= o the language unit it's being used in, not passed around freely like some = kind of depraved party girl.

And what's the "ruby-bin"?

--
Michael T. Richter <ttmri= chter@gmail.com> (GoogleTalk: ttmrichter@gmail.com)
All really first class designers are both artists, engineers, and men of= a powerful and intolerant temper, quick to resist the least modification o= f the plans, energetic in fighting the least infringement upon what they re= gard as their own sphere of action. (Nevil Shute)

--=-UE+4vUcO9mnZH5Wtmqtf-- --=-9+k0UV1R9uoYnKHQ4Jiq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBG2CMNLqyWkKVQ54QRAoMCAKCqAEo+EC6rtBStNSJl2AdYNA+FrQCgnGjq ucoL4pWW9xXdK6roeskmaEM= =P1mc -----END PGP SIGNATURE----- --=-9+k0UV1R9uoYnKHQ4Jiq--