[#14696] Inconsistency in rescuability of "return" — Charles Oliver Nutter <charles.nutter@...>

Why can you not rescue return, break, etc when they are within

21 messages 2008/01/02
[#14699] Re: Inconsistency in rescuability of "return" — Gary Wright <gwtmp01@...> 2008/01/02

[#14738] Enumerable#zip Needs Love — James Gray <james@...>

The community has been building a Ruby 1.9 compatibility tip list on

15 messages 2008/01/03
[#14755] Re: Enumerable#zip Needs Love — Martin Duerst <duerst@...> 2008/01/04

Hello James,

[#14772] Manual Memory Management — Pramukta Kumar <prak@...>

I was thinking it would be nice to be able to free large objects at

36 messages 2008/01/04
[#14788] Re: Manual Memory Management — Marcin Raczkowski <mailing.mr@...> 2008/01/05

I would only like to add that RMgick for example provides free method to

[#14824] Re: Manual Memory Management — MenTaLguY <mental@...> 2008/01/07

On Sat, 5 Jan 2008 15:49:30 +0900, Marcin Raczkowski <mailing.mr@gmail.com> wrote:

[#14825] Re: Manual Memory Management — "Evan Weaver" <evan@...> 2008/01/07

Python supports 'del reference', which decrements the reference

[#14838] Re: Manual Memory Management — Marcin Raczkowski <mailing.mr@...> 2008/01/08

Evan Weaver wrote:

[#14911] Draft of some pages about encoding in Ruby 1.9 — Dave Thomas <dave@...>

Folks:

24 messages 2008/01/10

[#14976] nil encoding as synonym for binary encoding — David Flanagan <david@...>

The following just appeared in the ChangeLog

37 messages 2008/01/11
[#14977] Re: nil encoding as synonym for binary encoding — Yukihiro Matsumoto <matz@...> 2008/01/11

Hi,

[#14978] Re: nil encoding as synonym for binary encoding — Dave Thomas <dave@...> 2008/01/11

[#14979] Re: nil encoding as synonym for binary encoding — David Flanagan <david@...> 2008/01/11

Dave Thomas wrote:

[#14993] Re: nil encoding as synonym for binary encoding — Dave Thomas <dave@...> 2008/01/11

[#14980] Re: nil encoding as synonym for binary encoding — Gary Wright <gwtmp01@...> 2008/01/11

[#14981] Re: nil encoding as synonym for binary encoding — Yukihiro Matsumoto <matz@...> 2008/01/11

Hi,

[#14995] Re: nil encoding as synonym for binary encoding — David Flanagan <david@...> 2008/01/11

Yukihiro Matsumoto writes:

[#15050] how to "borrow" the RDoc::RubyParser and HTMLGenerator — Phlip <phlip2005@...>

Core Rubies:

17 messages 2008/01/13
[#15060] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Eric Hodel <drbrain@...7.net> 2008/01/14

On Jan 13, 2008, at 08:54 AM, Phlip wrote:

[#15062] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Phlip <phlip2005@...> 2008/01/14

Eric Hodel wrote:

[#15073] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Eric Hodel <drbrain@...7.net> 2008/01/14

On Jan 13, 2008, at 20:35 PM, Phlip wrote:

[#15185] Friendlier methods to compare two Time objects — "Jim Cropcho" <jim.cropcho@...>

Hello,

10 messages 2008/01/22

[#15194] Can large scale projects be successful implemented around a dynamic programming language? — Jordi <mumismo@...>

A good article I have found (may have been linked by slashdot, don't know)

8 messages 2008/01/24

[#15248] Symbol#empty? ? — "David A. Black" <dblack@...>

Hi --

24 messages 2008/01/28
[#15250] Re: Symbol#empty? ? — Yukihiro Matsumoto <matz@...> 2008/01/28

Hi,

Re: Symbol#empty? ?

From: Dave Thomas <dave@...>
Date: 2008-01-28 03:50:09 UTC
List: ruby-core #15256
On Jan 27, 2008, at 8:54 PM, Yukihiro Matsumoto wrote:

>  * allowing :""
>  * removing Symbol#empty?

For me, the answer depends on what you (Matz) feel that symbols are.  
Back when they were simple atoms, then clearly #empty? would make no  
sense (not just because :<nothing> was silly, but also because the  
concept of emptiness made no sense for things that were essentially  
one dimensional).

But, now, we have strange things like :"a b", which means symbols are  
more stringlike. And once symbols have a length, they should probably  
respond to empty? too.

But, either way, I feel that the current idea of a "symbol" is  
somewhat confused, and I'm not sure I see the point of the added  
complexity. One the one side, we have the original idea of a symbol  
being something that could be stored in a symbol table (where the  
symbol table was used to store names that were valid in the language).  
Or the other side, we have the idea that symbols are kind of like read- 
only, immediate strings (although I don't see why they were thought to  
be read only, as wouldn't :"abc"[1] = 'd' simply return :"adc", a new  
symbol?).

I'd personally say that right now we seem to be stuck in a compromise  
between the two positions. Symbols are neither one thing nor the  
other. They have a length, which implies that they have a content,  
just like strings. But they have almost no string-like methods, so  
they are crippled strings.

 From my perspective, I'm not sure I see the benefit of all these  
changes. What use cases are we addressing with the ability to do  
File.read("war_and_peace.txt").intern? And what unexpected DOS  
loopholes are we opening in the process?

So, if there's still room for debate, I'd personally be on the side of  
returning to the old Symbols are symbols implementation and losing  
empty?


Dave




In This Thread