[#84664] CGI uses file size to distinguish between regular values and files — David Heinemeier Hansson <david@...>

I've been having a ton of problems handling file uploads with CGI.rb

23 messages 2003/11/02
[#84674] Re: CGI uses file size to distinguish between regular values and files — Simon Kitching <simon@...> 2003/11/03

Hi David,

[#84676] Re: CGI uses file size to distinguish between regular values and files — Dmitry Borodaenko <d.borodaenko@...> 2003/11/03

On Mon, Nov 03, 2003 at 02:29:08PM +0900, Simon Kitching wrote:

[#84678] Re: CGI uses file size to distinguish between regular values and files — Austin Ziegler <austin@...> 2003/11/03

On Mon, 3 Nov 2003 20:12:06 +0900, Dmitry Borodaenko wrote:

[#84692] Re: CGI uses file size to distinguish between regular values and files — Dmitry Borodaenko <d.borodaenko@...> 2003/11/03

On Mon, Nov 03, 2003 at 11:40:48PM +0900, Austin Ziegler wrote:

[#84700] Re: CGI uses file size to distinguish between regular values and files — Austin Ziegler <austin@...> 2003/11/03

On Tue, 4 Nov 2003 04:37:19 +0900, Dmitry Borodaenko wrote:

[#84701] Re: CGI uses file size to distinguish between regular values and files — Simon Kitching <simon@...> 2003/11/03

On Tue, 2003-11-04 at 10:29, Austin Ziegler wrote:

[#84703] Re: CGI uses file size to distinguish between regular values and files — Austin Ziegler <austin@...> 2003/11/03

On Tue, 4 Nov 2003 06:51:43 +0900, Simon Kitching wrote:

[#84708] Re: CGI uses file size to distinguish between regular values and files — matz@... (Yukihiro Matsumoto) 2003/11/04

Hi,

[#84735] Managing metadata about attribute types — Simon Kitching <simon@...>

Hi,

52 messages 2003/11/05
[#84740] Re: Managing metadata about attribute types — Austin Ziegler <austin@...> 2003/11/05

On Wed, 5 Nov 2003 09:38:16 +0900, Simon Kitching wrote:

[#84741] Re: Managing metadata about attribute types — Simon Kitching <simon@...> 2003/11/05

On Wed, 2003-11-05 at 17:09, Austin Ziegler wrote:

[#84762] Re: Managing metadata about attribute types — Simon Kitching <simon@...> 2003/11/06

What a vigorous discussion I seem to have triggered :-)

[#84770] Re: Managing metadata about attribute types — dblack@... 2003/11/06

Hi --

[#84780] Re: Managing metadata about attribute types — Ryan Pavlik <rpav@...> 2003/11/06

On Thu, 6 Nov 2003 12:45:39 +0900

[#84858] Re: Managing metadata about attribute types — "John W. Long" <ng@...> 2003/11/08

Ryan,

[#84847] Long-running daemon acquiring giant memory footprint — Jason DiCioccio <jd@...>

I have written a long-running daemon in ruby to handle dynamic DNS updates.

16 messages 2003/11/07

[#84900] Antwort: Re: Power of Interpreted Languages — Robert.Koepferl@...

25 messages 2003/11/10
[#84914] Re: Antwort: Re: Power of Interpreted Languages — Aredridel <aredridel@...> 2003/11/10

> But, would you implement a game with ruby?

[#84917] Re: Antwort: Re: Power of Interpreted Languages — Gregory Millam <walker@...> 2003/11/10

Received: Tue, 11 Nov 2003 01:21:15 +0900

[#84920] Re: Antwort: Re: Power of Interpreted Languages — "Sean O'Dell" <sean@...> 2003/11/10

On Monday 10 November 2003 09:28 am, Gregory Millam wrote:

[#84921] Ruby/Tk Some Basic Questions — "Zach Dennis" <zdennis@...> 2003/11/10

Hi,

[#84930] Re: Ruby/Tk Some Basic Questions — Hidetoshi NAGAI <nagai@...> 2003/11/11

Hi,

[#85097] substring: to the end of the string — KONTRA Gergely <kgergely@...>

Hi!

19 messages 2003/11/14

[#85104] Microsoft's C/C++ compiler freely available — "Nathaniel Talbott" <nathaniel@...>

Thought this might be interesting to those stuck on win32...

23 messages 2003/11/15
[#85106] Re: Microsoft's C/C++ compiler freely available — Daniel Carrera <dcarrera@...> 2003/11/15

Question:

[#85178] overload method in module_eval, how? — Simon Strandgaard <qj5nd7l02@...>

I want to overload a testcase method with debug-enabling wrapper.

13 messages 2003/11/17

[#85218] Access ftp-server through proxy — Kristian Sensen <ks@...>

14 messages 2003/11/17

[#85330] Yet Another Rite Thought: method combination — gabriele renzi <surrender_it@...1.vip.ukl.yahoo.com>

I just looked at matz' slides and I don't have a clear understanding

28 messages 2003/11/17

[#85421] Again, Rite explanation needed (keyword args and new hash syntax) — gabriele renzi <surrender_it@...1.vip.ukl.yahoo.com>

Hi gurus and nubys,

13 messages 2003/11/18

[#85488] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )<Pine.LNX.4.44.0311171402340.1133-100000@ool-435 5dfae.dyn.optonline.net> — "Weirich, James" <James.Weirich@...>

David Black (dblack@wobblini.net) wrote:

121 messages 2003/11/18
[#85492] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )<Pine.LNX.4.44.0311171402340.1133-100000@ool-435 5dfae.dyn.optonline.net> — Simon Kitching <simon@...> 2003/11/18

On Wed, 2003-11-19 at 10:30, Weirich, James wrote:

[#85499] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )<Pine.LNX.4.44.0311171402340.1133-100000@ool-435 5dfae.dyn.optonline.net> — "Sean O'Dell" <sean@...> 2003/11/18

On Tuesday 18 November 2003 02:06 pm, Simon Kitching wrote:

[#85523] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — Austin Ziegler <austin@...> 2003/11/19

On Wed, 19 Nov 2003 08:08:25 +0900, Sean O'Dell wrote:

[#85582] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Sean O'Dell" <sean@...> 2003/11/19

On Tuesday 18 November 2003 10:30 pm, Austin Ziegler wrote:

[#85609] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — Austin Ziegler <austin@...> 2003/11/19

On Thu, 20 Nov 2003 02:43:31 +0900, Sean O'Dell wrote:

[#85619] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Sean O'Dell" <sean@...> 2003/11/19

On Wednesday 19 November 2003 12:04 pm, Austin Ziegler wrote:

[#85656] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — Austin Ziegler <austin@...> 2003/11/19

On Thu, 20 Nov 2003 05:48:37 +0900, Sean O'Dell wrote:

[#85664] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Sean O'Dell" <sean@...> 2003/11/19

On Wednesday 19 November 2003 03:00 pm, Austin Ziegler wrote:

[#85684] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — Austin Ziegler <austin@...> 2003/11/20

On Thu, 20 Nov 2003 08:19:08 +0900, Sean O'Dell wrote:

[#85688] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — Simon Kitching <simon@...> 2003/11/20

On Thu, 2003-11-20 at 14:06, Austin Ziegler wrote:

[#85734] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — Thien Vuong <tvuong@...> 2003/11/20

[#85748] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — Austin Ziegler <austin@...> 2003/11/20

On Thu, 20 Nov 2003 14:52:17 +0900, Thien Vuong wrote:

[#85854] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Sean O'Dell" <sean@...> 2003/11/20

On Wednesday 19 November 2003 10:47 pm, Austin Ziegler wrote:

[#85858] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — dblack@... 2003/11/20

Hi --

[#85895] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — matz@... (Yukihiro Matsumoto) 2003/11/20

Hi,

[#85906] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — Chad Fowler <chad@...> 2003/11/20

On Fri, 21 Nov 2003, Yukihiro Matsumoto wrote:

[#85938] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — matz@... (Yukihiro Matsumoto) 2003/11/21

Hi,

[#85940] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Sean O'Dell" <sean@...> 2003/11/21

On Thursday 20 November 2003 06:47 pm, Yukihiro Matsumoto wrote:

[#85944] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — matz@... (Yukihiro Matsumoto) 2003/11/21

Hi,

[#85951] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Sean O'Dell" <sean@...> 2003/11/21

On Thursday 20 November 2003 07:58 pm, Yukihiro Matsumoto wrote:

[#85970] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — matz@... (Yukihiro Matsumoto) 2003/11/21

Hi,

[#85997] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Sean O'Dell" <sean@...> 2003/11/21

On Friday 21 November 2003 02:20 am, Yukihiro Matsumoto wrote:

[#86046] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — matz@... (Yukihiro Matsumoto) 2003/11/21

Hi,

[#86071] Method wrapper question (was "stereotyping (was ...)) — Gavin Sinclair <gsinclair@...> 2003/11/22

On Saturday, November 22, 2003, 10:53:39 AM, Yukihiro wrote:

[#86085] Re: Method wrapper question (was "stereotyping (was ...)) — ts <decoux@...> 2003/11/22

>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

[#86090] Re: Method wrapper question (was "stereotyping (was ...)) — Gavin Sinclair <gsinclair@...> 2003/11/22

On Saturday, November 22, 2003, 11:47:50 PM, ts wrote:

[#86091] Re: Method wrapper question (was "stereotyping (was ...)) — ts <decoux@...> 2003/11/22

>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

[#86092] Re: Method wrapper question (was "stereotyping (was ...)) — "Christoph" <chr_mail@...> 2003/11/22

ts wrote:

[#86093] Re: Method wrapper question (was "stereotyping (was ...)) — ts <decoux@...> 2003/11/22

>>>>> "C" == Christoph <chr_mail@gmx.net> writes:

[#86095] Re: Method wrapper question (was "stereotyping (was ...)) — "Christoph" <chr_mail@...> 2003/11/22

ts wrote:

[#85908] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Sean O'Dell" <sean@...> 2003/11/20

On Thursday 20 November 2003 02:40 pm, Chad Fowler wrote:

[#85590] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "David A. Black" <dblack@...> 2003/11/19

Hi --

[#85597] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Sean O'Dell" <sean@...> 2003/11/19

On Wednesday 19 November 2003 10:33 am, David A. Black wrote:

[#85599] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — matz@... (Yukihiro Matsumoto) 2003/11/19

Hi,

[#85604] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Sean O'Dell" <sean@...> 2003/11/19

On Wednesday 19 November 2003 11:14 am, Yukihiro Matsumoto wrote:

[#85503] String startswith/endswith in Ruby? — Dave Benjamin <ramen@...>

Hi all,

12 messages 2003/11/18

[#85518] Multi-dimensioned sparse array ? — Charles Hixson <charleshixsn@...>

Does anyone have an implementation of a multi-dimensioned sparse array?

14 messages 2003/11/19
[#85527] Re: Multi-dimensioned sparse array ? — Austin Ziegler <austin@...> 2003/11/19

On Wed, 19 Nov 2003 14:21:19 +0900, Charles Hixson wrote:

[#85526] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )<Pine.LNX.4.44.0311171402340.1133-100000@ool-4355dfae.dyn.optonline.net> <Pine.LNX.4.44.0311181524130.2236-100000@ool-4355dfae.dyn.optonline.net> — Thien Vuong <tvuong@...>

54 messages 2003/11/19
[#85544] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) — dblack@... 2003/11/19

[Apologies to anyone whose threading is getting messed up by the

[#85583] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) — "Sean O'Dell" <sean@...> 2003/11/19

On Wednesday 19 November 2003 03:55 am, dblack@wobblini.net wrote:

[#85588] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) — "David A. Black" <dblack@...> 2003/11/19

Hi --

[#85595] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) — "Sean O'Dell" <sean@...> 2003/11/19

On Wednesday 19 November 2003 10:27 am, David A. Black wrote:

[#85598] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) — matz@... (Yukihiro Matsumoto) 2003/11/19

Hi,

[#85601] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) — "Sean O'Dell" <sean@...> 2003/11/19

On Wednesday 19 November 2003 11:05 am, Yukihiro Matsumoto wrote:

[#85605] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) — Chad Fowler <chad@...> 2003/11/19

On Thu, 20 Nov 2003, Sean O'Dell wrote:

[#85612] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) — "Sean O'Dell" <sean@...> 2003/11/19

On Wednesday 19 November 2003 11:46 am, Chad Fowler wrote:

[#85617] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) — Maik Schmidt <contact@...> 2003/11/19

Sean O'Dell wrote:

[#85629] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) — "Sean O'Dell" <sean@...> 2003/11/19

On Wednesday 19 November 2003 12:42 pm, Maik Schmidt wrote:

[#85543] Re: $& write-protected? — ts <decoux@...>

>>>>> "S" == Simon Strandgaard <none> writes:

14 messages 2003/11/19

[#85547] x.f! RCR — Greg McIntyre <greg@...>

It bugs me that some methods have a ! on the end and some don't. It

20 messages 2003/11/19

[#85698] Re: "stereotyping" — Michael Campbell <michael_s_campbell@...>

Sean O'Dell wrote:

19 messages 2003/11/20
[#85701] Re: "stereotyping" — "Sean O'Dell" <sean@...> 2003/11/20

On Wednesday 19 November 2003 07:01 pm, Michael Campbell wrote:

[#85704] Re: "stereotyping" — Michael campbell <michael_s_campbell@...> 2003/11/20

Sean O'Dell wrote:

[#85718] Re: "stereotyping" — Clifford Heath <cjh_nospam@...> 2003/11/20

Michael campbell wrote:

[#85757] Re: "stereotyping" — Julian Fitzell <julian@...4.com> 2003/11/20

Clifford Heath wrote:

[#85913] Re: "stereotyping" — Clifford Heath <cjh_nospam@...> 2003/11/20

Julian Fitzell wrote:

[#85713] Re: [ANN] win32-clipboard 0.1.0 — Daniel Berger <djberg96@...>

Oops - forgot the link:

14 messages 2003/11/20

[#85766] learning the "Ruby way" — mark.wirdnam@... (Mark Wirdnam)

**Hobby-programmer alarm**

24 messages 2003/11/20
[#85863] Re: learning the "Ruby way" — Chad Fowler <chad@...> 2003/11/20

On Thu, 20 Nov 2003, Mark Wirdnam wrote:

[#85821] iterator 0.1 — Simon Strandgaard <qj5nd7l02@...>

homepage:

22 messages 2003/11/20

[#85870] Re: "stereotyping" — Michael Campbell <michael_s_campbell@...>

Sean O'Dell wrote:

17 messages 2003/11/20

[#85886] Partial Euphoric Type Checking — "T. Onoma" <transami@...>

Greetings all Type Checkers!

16 messages 2003/11/20
[#85948] Re: Partial Euphoric Type Checking (now Ducked!) — "T. Onoma" <transami@...> 2003/11/21

quack! quack! I added duck typing capability to my euphoric type checking

[#85952] Re: Partial Euphoric Type Checking (Super Duck!?) — "T. Onoma" <transami@...> 2003/11/21

Now some for some rally crazy cross thought. First a complete interface

[#85957] Re: Partial Euphoric Type Checking (Super Duck!?) — "T. Onoma" <transami@...> 2003/11/21

for some cross rally some thought crazy. ( read: i need a type system for my

[#85981] Re: Partial Euphoric Type Checking (Super Duck!?) — Chris Morris <chrismo@...> 2003/11/21

> you see we have a problem here. it doesn't matter what methods are

[#85987] Re: Partial Euphoric Type Checking (Super Duck!?) — Peter <Peter.Vanbroekhoven@...> 2003/11/21

> > you see we have a problem here. it doesn't matter what methods are

[#85888] New Type Checking System Idea — "Sean O'Dell" <sean@...>

Taking comments into consideration, a totally new approach strikes me

22 messages 2003/11/20

[#85947] RubyConf 2003 Presentations Posted — Ryan Davis <ryand-ruby@...>

In absolute record time (5 days compared to 3 months), rubyconf 2003

11 messages 2003/11/21

[#86007] Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) ) — "Weirich, James" <James.Weirich@...>

> This is a wonderful idea. Let me restate it to make sure I

13 messages 2003/11/21

[#86127] Ruby classes for MP3 de-/encoding — Dennis Oelkers <dennis@...>

Hello folks,

12 messages 2003/11/22

[#86183] "wrong argument type nil (expected String)" from Dir.chdir — Tim Kynerd <vxbrw58s02@...>

I'm running Ruby 1.6.8.

13 messages 2003/11/23

[#86202] Message "Insecure world writable dir ..." — Harry Ohlsen <harryo@...>

When File.popen() is passed an executable whose path contains a world writable directory, it produces a warning message.

19 messages 2003/11/24

[#86215] Library path relative to current .rb file — zoranlazarevic@... (Zoran Lazarevic)

One of the most irritating (missing) features of Ruby is inability to

12 messages 2003/11/24

[#86265] raise unless RUBY_VERSION[%r/^\s*\d+\.\d+/o].to_f >= 1.8 — "Ara.T.Howard" <ahoward@...>

25 messages 2003/11/24

[#86344] Re: Controlled block variables — "T. Onoma" <transami@...>

On Wednesday 26 November 2003 09:10 am, Guy Decoux wrote:

42 messages 2003/11/26
[#86369] Re: Controlled block variables — Dan Doel <djd15@...> 2003/11/26

I actually have wondered in the past why there isn't an #eval that takes

[#86390] Re: Controlled block variables — "T. Onoma" <transami@...> 2003/11/26

On Wednesday 26 November 2003 03:57 pm, Dan Doel wrote:

[#86346] Re: Controlled block variables — ts <decoux@...> 2003/11/26

>>>>> "T" == T Onoma <transami@runbox.com> writes:

[#86347] Re: Controlled block variables — "T. Onoma" <transami@...> 2003/11/26

On Wednesday 26 November 2003 09:56 am, ts wrote:

[#86360] turning a string into array of ASCII bytes — David Garamond <lists@...6.isreserved.com>

What is the shortest, most straightforward way (without temporary

17 messages 2003/11/26

[#86391] Method wrapping — Hal Fulton <hal9000@...>

I've come late into the thread on this, and I haven't read all

62 messages 2003/11/26
[#86445] Re: Method wrapping — matz@... (Yukihiro Matsumoto) 2003/11/26

Hi,

[#86457] Re: Method wrapping — Hal Fulton <hal9000@...> 2003/11/27

Yukihiro Matsumoto wrote:

[#86462] Re: Method wrapping — matz@... (Yukihiro Matsumoto) 2003/11/27

Hi,

[#86470] Re: Method wrapping — "T. Onoma" <transami@...> 2003/11/27

On Thursday 27 November 2003 07:07 am, Yukihiro Matsumoto wrote:

[#86493] Re: Method wrapping — "Christoph" <chr_mail@...> 2003/11/27

Yukihiro Matsumoto wrote:

[#86498] Re: Method wrapping — Peter <Peter.Vanbroekhoven@...> 2003/11/27

> I have asked the same this question as well and I really wish

[#86508] Re: Method wrapping — "Christoph" <chr_mail@...> 2003/11/27

From: Peter wrote:

[#86512] Re: Method wrapping — Peter <Peter.Vanbroekhoven@...> 2003/11/27

> This sound all good and well however this does not change the

[#86550] pre/post question/idea — "David A. Black" <dblack@...>

Hello --

21 messages 2003/11/28

[#86646] Underpinnings of Method Wrapping — "T. Onoma" <transami@...>

Its important that we clearly seperate the issue of "surface" syntax from the

54 messages 2003/11/28
[#86657] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/11/28

> Thoughts?

[#86692] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/11/29

On Saturday 29 November 2003 12:44 am, Peter wrote:

[#86707] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/11/29

> I originally had a small paragraph touching on this, but I took it out b/c I

[#86726] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/11/29

On Saturday 29 November 2003 04:26 pm, Peter wrote:

[#86734] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/11/30

> The join-points are the only thing required to facilitate all of this. So I

[#86747] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/11/30

On Sunday 30 November 2003 01:01 am, Peter wrote:

[#86794] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/11/30

> How would they know? ;-)

[#86812] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/11/30

On Sunday 30 November 2003 03:57 pm, Peter wrote:

[#86824] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/11/30

> > I like the proper separation, but why pre and post for extrinsic and def

[#86831] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/11/30

On Sunday 30 November 2003 09:39 pm, Peter wrote:

[#86835] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/11/30

> You're absolutely right. Hmm...Granted this is acting in accordance to an

[#86873] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/12/01

On Monday 01 December 2003 12:25 am, Peter wrote:

[#86911] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/12/01

> I was thinking about the terms. To really distinguish these two types of wraps

[#86943] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/12/02

On Monday 01 December 2003 06:58 pm, Peter wrote:

[#87024] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/12/02

> OK as in so-so, or OK as in yes? If just so-so we'll find something better. I

[#87034] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/12/02

Peter:

[#87068] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/12/03

[snip]

[#87242] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/12/04

On Wednesday 03 December 2003 03:21 am, Peter wrote:

[#87478] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/12/07

Here is an intereseting problem that I'm currently facing and which is related

[#87481] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/12/07

> As always, I may be over looking the obvious. But if anyone has a current

[#87491] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/12/08

On Sunday 07 December 2003 08:02 pm, Peter wrote:

[#87575] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/12/09

Hi Tom,

[#87609] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/12/09

On Tuesday 09 December 2003 01:05 am, Peter wrote:

[#87686] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/12/10

> QUICK SIDE NOTE: might be nice to have something for all those dang ends. How

[#87688] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/12/10

On Wednesday 10 December 2003 05:16 am, Peter wrote:

[#87713] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/12/10

> Mine too! But I was joking :) Well, half way. It would be nice to have a good

[#87731] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/12/10

On Wednesday 10 December 2003 05:55 pm, Peter wrote:

[#87747] Re: Underpinnings of Method Wrapping — Peter <Peter.Vanbroekhoven@...> 2003/12/11

> Well, I thought of using the underscores to allow one to indent as needed to

[#87761] Re: Underpinnings of Method Wrapping — "T. Onoma" <transami@...> 2003/12/11

On Thursday 11 December 2003 04:04 am, Peter wrote:

[#86655] anything disappearing from Ruby for 2.0? — "David A. Black" <dblack@...>

Hi --

62 messages 2003/11/28
[#86710] Re: anything disappearing from Ruby for 2.0? — matz@... (Yukihiro Matsumoto) 2003/11/29

Hi,

[#86737] Re: anything disappearing from Ruby for 2.0? — Michael Campbell <michael_s_campbell@...> 2003/11/30

Yukihiro Matsumoto wrote:

[#86779] Re: anything disappearing from Ruby for 2.0? — matz@... (Yukihiro Matsumoto) 2003/11/30

Hi,

[#86661] rdoc included in standard distribution? — Chad Fowler <chad@...>

I've seen various plans for this dating back more than a year. Is it

16 messages 2003/11/29

[#86669] Class-level readers and writers — Carl Youngblood <carl@...>

I've been working with the class attribute shortcuts that Hal introduced

36 messages 2003/11/29
[#86675] Re: Class-level readers and writers — "David A. Black" <dblack@...> 2003/11/29

Hi --

[#86722] Re: Class-level readers and writers — Carl Youngblood <carl@...> 2003/11/29

> (Just as a footnote, you can also use "normal" accessor shortcuts at

[#86723] Re: Class-level readers and writers — "David A. Black" <dblack@...> 2003/11/29

Hi --

[#86728] Re: Class-level readers and writers — "Christoph" <chr_mail@...> 2003/11/29

David A. Black wrote:

[#86752] Re: Class-level readers and writers — "T. Onoma" <transami@...> 2003/11/30

On Saturday 29 November 2003 10:59 pm, Christoph wrote:

[#86782] Re: Class-level readers and writers — "David A. Black" <dblack@...> 2003/11/30

Hello --

[#86801] Re: Class-level readers and writers — "T. Onoma" <transami@...> 2003/11/30

On Sunday 30 November 2003 12:11 pm, David A. Black wrote:

[#86807] Re: Class-level readers and writers — "David A. Black" <dblack@...> 2003/11/30

Hi --

[#86808] Re: Class-level readers and writers — ts <decoux@...> 2003/11/30

>>>>> "D" == David A Black <dblack@wobblini.net> writes:

[#86815] Re: Class-level readers and writers — "David A. Black" <dblack@...> 2003/11/30

Hi --

[#86673] New to ruby--trouble with initializing arrays — vanjac12@... (Van Jacques)

I am writing a practice program; the Game of Life. Naturally I am having troubles.

11 messages 2003/11/29

[#86784] Re: anything disappearing from Ruby for 2.0? — "Gavri Savio Fernandez" <Gavri_F@...>

> From: Chris Uppal [mailto:chris.uppal@metagnostic.REMOVE-THIS.org]

21 messages 2003/11/30
[#86800] Re: anything disappearing from Ruby for 2.0? — "Chris Uppal" <chris.uppal@...> 2003/11/30

Gavri Savio Fernandez wrote:

Re: Managing metadata about attribute types

From: Ryan Pavlik <rpav@...>
Date: 2003-11-06 06:17:03 UTC
List: ruby-talk #84776
On Thu, 6 Nov 2003 12:27:43 +0900
Austin Ziegler <austin@halostatue.ca> wrote:

> On Wed, 5 Nov 2003 18:08:04 +0900, Ryan Pavlik wrote:
<snip>
> > This is demonstrably wrong.
> 
> Actually, it's demonstrably correct. It's exactly to the point and
> perfectly accurate regarding how one should deal with data in a
> dynamically typed language such as Ruby. In Text::Format, I have a
> method #hyphenator= which accepts any object that responds to
> #hyphenate_to with an arity of 2 or 3. I explicitly reject any other
> object. In documentation, I make it clear that #hyphenate_to should
> return an array of two objects. In this way, I don't care what
> *class* an object is, I just care that it's type is a hyphenator (as
> defined above).

This is a specific case that does not generalize.

> > An object cannot validate and transform its own data in this
> > context in any reasonably general manner.
> 
> Your StrongTyping module doesn't help with this, either, Ryan. It's
> not a conversion module.

Actually it does, but not the way you think.  The point in using the
ST module is not the type verification; many ruby people get too hung
up on the type checking bit.

The real area of interest is the fact it _documents_ what you want;
you can ask it what type it is expecting with the various query
functions the ST module provides.

> > It's simple when you're addressing a few basic types... String,
> > Float, Integer, Hash and Array.
> 
> Not really. If I were to do the following:

<big typechecking examples snipped>

> If you know you're going to be doing something that could leave
> things in an intermediate state, ensure that they don't get left in
> such a state. The bridge is closed when you pass "m" as a string.

Again, this misses the point.  The original question was "how do I ask
what a particular thing wants?"  My answer was to use the ST module,
because you do exactly that:

    class Foo
      def foo=(x); expect(x, Numeric); @x=x; end
    end

Or more conveniently:

    class Foo
      attr_accessor_typed Numeric, :foo
    end

Now you can simple say:

    foo = Foo.new
    t   = get_arg_types(foo.method(:foo=))    # => [[Numeric]]

Now, how is this useful?  We can do "third-party" input processing,
where it properly belongs.  Having this code in either the source
class (String) or the destination class (for the XML) is wrong, since
it results in unnecessary coupling, and thus limits extensibility.

As a third party, we can have an interface for extending the input
processing from any position.

> > * We just don't allow it. This does no good for us.
> 
> But this is *exactly* what StrongTyping does, Ryan. It doesn't allow
> types that it doesn't know how to deal with.

No, Austin, this isn't what it's about.  This is not about type
checking arguments passed to a method---that's just a handy side
effect in this case.  It's about querying beforehand.

<snip>
> > Using #to_* methods are the ruby equivalent of type casting. The
> > point in this case is not to _convert_ types, it's to provide the
> > right type in the first place. Instead of giving the attribute a
> > string and expecting it to be parsed, we want to create the
> > desired type and hand that off.
> 
> Oh, bollocks. Item's @cost is expected to work as a float. Not an
> integer, a float. If I want to ensure that it works as a float,
> Item#cost= should attempt to *make* the provided parameter into a
> float. If someone is going to pass me something that can't be
> converted to what I expect, they're going to get an error. If I'm
> expecting a Foo, though, then I should probably do something like:
> 
>   def foo=(x)
>     @x = Foo(x)
>   end

Er, that works in C++, but not ruby, unless you define a Foo()
function.  I'm not sure ruby will allow both a Foo class and a Foo
function, but either way it's not any sort of working standard.

However, given Foo(x) makes a Foo out of x, this is definitely not a
good solution.  We want a Foo.  Any Foo should work...

    class Bar < Foo
       :
    end

...even if it's a Bar.  Inheritence is one of the big three of OOP;
doing the sort of re-creation you have here defeats the point.  Even
C++ typecasting preserves the identity of a thing.

> That's *if* a Foo can be converted from other types. Or, maybe, I'm
> just looking for a particular method call, in which case I can
> defensively program as I did with Text::Format. Can it still be
> bitten by someone who accepts the parameters in a different order or
> expects different things? Sure. But that's not exactly something
> that I can program against in any case ... unless I'm using strong
> typing, and IMO that does the wrong thing.

I'm not sure what you mean by "the wrong thing"; since you've been
focusing solely on strict type checking, that may be it.  I fail to
see how this is "the wrong thing", though.

In any case, you could conceivably use ST to handle this case.  I've
been contemplating a module that augments this and provides call
context and semantics in addition to types.  Duck typing people may
like this more, since it would do implicit type conversions.  You
wouldn't care what arguments a method took; you'd provide it with the
data at hand, coupled with its semantic documentation:

    def foo(*args)
       x, y = find_in_context([:x, Float, :point],
                              [:y, Float, :point])
       :
    end

We could call it in a number of ways:

    # Specify semantics explicitly:
    foo(:x => 1, :y => 2)

    # "Point" would have semantic tagging for :point, :x, and :y:
    point = Point.new(1, 2)
    foo(point)

    # Have one in context:
    context_push Point.new(0, 0)

    Circle.new                      # Both gather their point
    foo                             # from the existing context

Ambiguity and insufficient data would both raise exceptions.
Conceivably these could raise to the user level, and have the user
provide discernment or additional data.

Programming with a context pool is exceedingly useful in a number of
areas, but I'm straying far from the original point.  One of the bits
of information here is still type, and for the _same_reason_ I
discussed above: so a third party can query and handle things.

> Note that I've done much the same thing with Ruwiki recently -- I've
> abstracted out what a Ruwiki::Wiki::Token needs to know into a
> Handler. It responds to certain methods. As the needs for what a
> Wiki Token needs to know increase, the Handler will increase as
> well. I'm not even checking to see if the token handler is a
> specific class. I just expect that it will respond to those methods.

I tried a similar thing once (actually it was quite a bit different in
application, but similar in form), but found it leads to far too much
information redundancy.  I should be able to say, once, "this is what
this means, this is what this wants, this is what it does".  I
shouldn't have to write it again for every class.  Granted, if you
only have one class (Ruwiki::Wiki::Token), then it's not much of a
problem.

But the ability to query the type it wants lets you solve the problem
in a general manner, so you don't have to do it again for _any_ class,
and you can extend the general case with a minimal amount of
additional code.

Basically, when I have 200 classes, I don't want another 200 classes
to do interpretation.  It makes the idea of writing that 201st class
not seem very pleasant.

> As Rich Kilmer said, are you checking for behaviour or namespace?

OK, let's look at it this way.  Say we write things in a duck-typed
manner.  We could provide something similar to ST for efficient
checking:

   def foo(h)
      expect_duck h, :[], :[]=
         :
      h["something"] = ...
         :
   end

Right?  We treat it not by type, but what it acts like.  It provides
us with #[] and #[]=, so (ignoring any semantic issues) it's enough of
a duck for us.

Now, this may begin to get tedious:

    def foo(a, b)
       expect_duck a, [:first, :last, :[], :each],
                   b, [:first, :last, :[], :each]
         :
    end

So, after a time, we start defining common sets so we don't have to do
that every time:

    ARRAY_DUCK = [:first, :last, :[], :each]

    def foo(a, b)
       expect_duck a, ARRAY_DUCK, b, ARRAY_DUCK
          :
    end

Now, you probably see where I'm going with this.  Where I've already
gone, actually.  This is a simple reinvention of classes, just lacking
important semantic information.

You can also treat a class (or module) itself as the behavioral
specification, and with it you gain the important semantic
differentiation between the proverbial ducks and platypuses.
You can simply ask, "is this a Foo?", and know that it will act like
you want.  When you make a thing that acts like a Foo, you can
subclass or include Foo, to show what you mean.

> > It has nothing to do with the #attr= function. Strict type
> > checking at that point is merely a convenience. It's all about
> > getting the input into a useful format without writing n^2
> > functions (for n classes). This is the primary reason I wrote
> > StrongTyping in fact; the strict checking has merely helped with
> > debugging a whole lot.
> 
> It has *everything* to do with the #attr= function in the case given.
> The OP is dealing with an XML document, which means that everything
> is a string and #to_f works. 

Austin, as above, not every type may be a simple string, float,
integer, array, or hash.  There are no other standard #to_* functions.
(Even array and hash are pushing that one.)  It would require either
String know how to interpret every type, or the procs you write
know how to interpret every type.  Eventually you're going to want to
add more types, and this method doesn't really allow for inheritence,
and it's not otherwise very extensible.

<snip>
> The problem here is ultimately that your objects have to know what
> they expect and how they are expected to be used *in general*. If
> you've got Item#cost, you can expect that it will be used in
> mathematic operations. You'll probably do such operations yourself.
> So, why not do some sort of conversion on the data to make it into
> what you expect it will be when you're defining your attribute
> accessor?

The question is where it should be done.  This is a perfect example.
Money should never (ever!) be done with Floats.  People don't like it
when they lose money due to lack of precision.

I've had to write a Currency module which uses integers, but provides
various currency formats and manipulations.  If we had Item#cost, we
could not solve the problem with #to_* conversions:

    class Item
        attr_accessor proc { |x| x.to_?? } :cost
    end

What do we convert to?  What we want is Currency---it doesn't matter
what type.  It could be USD, Euros, Yen, or whatever.  There is no
general #to_currency, and we can't just convert it to an integer,
because we lose what the integer means (200 USD is not Y200).  We
don't really have anything to demand that it responds to; currency is
more or less a number like anything else, it just has a unit attached.

With StrongTyping, it's easy:

    class Item
        attr_accessor Currency, :cost
    end

Now, _before_ we take "$200.05" and assign it to cost, the ST module
allows us to ask what it wants, and we can, as a third party, know how
to convert input type (a String) to the desired type (Currency).
(In this case, for a general solution, I'd recommend something like
the conversion table I discussed in [ruby-talk:74206].)

> A lot of people coming from strict typing backgrounds forget that
> this is done implicitly by the compiler ... or rather, because the
> type is strictly specified it isn't necessary to do such
> conversions. They're done automatically when the types can be
> converted.

Yes, but they're both standard and extensible.  In C++ I can do:

   operator int() {
       return (int)this->something;
   }

and when I "(int)thing", that routine gets called.  OTOH, I don't
think this is really the right solution, as this sort of thing is too
coupled with static typing, and static typing and OOP have no business
being in the same language.

> P.S. It was suggested that:
>   attr_accessor proc { |x| x.to_f }, :cost
> is overkill. Thus, the version I attached last night includes:
>   attr_accessor [:cost] => :to_f
> I may add other enhancements to that mechanism (as providing
> multiple method symbols in an array and chaining them).
<snip> 

Now, with all I've said above, I haven't really addressed
attr-with-proc stuff.  Actually, I think it'd be a pretty neat idea to
be able to tag extra code onto attributes without having to do a
full-out def.

I don't think it's the right solution to this problem, though.

-- 
Ryan Pavlik <rpav@mephle.com>

"Do not question wizards, for they are quick to
 turn you into a toad." - 8BT

In This Thread