[#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: Gary Wright <gwtmp01@...>
Date: 2008-01-28 14:40:48 UTC
List: ruby-core #15273
On Jan 28, 2008, at 2:50 AM, Dave Thomas wrote:
> Symbol tables are fundamentally an optimization: a way of looking  
> up an identifier. That's why the predominant use of symbols in Ruby  
> (post Rails) is as hash keys, where they serve the same function.  
> What function does :"a<space>b" serve for Ruby programmers?(*) And  
> is the benefit of having it worth the inconsistencies and security  
> issues involved.

By inconsistencies, I assume you mean that s.to_sym works even if the  
string doesn't represent a valid Ruby identifier?  Not sure what  
security issues you are referring to.

> Why not instead say that Symbol is for representing symbols, and  
> have #intern complain if the corresponding strings isn't valid?  
> That would allow :"+(binary)" to make sense, as the underlying  
> symbol is the same as :+.  And then if some application in future  
> has an obscure need to represent the works of Shakespeare as a  
> symbol, they can simply use a hash like everyone else would... :)

String#to_sym is a guaranteed 'perfect' hash though, not a regular  
hash with possible clashes.  If Symbol/String aren't going to provide  
that functionality then someone is going to immediately write a gem/ 
extension that does.

I could understand having a String/Symbol conversion that complained  
about illegal identifiers.  That could be #intern but that would  
break backward compatibility, which is another reason not to make  
#intern/#to_sym more strict than they are.  The only reason that   
"+", "+(binary)", "@+", and so on aren't creating strange problems  
now is the obscure nature of the synonyms.

> (*) orthogonality is not an argument when it comes to Ruby :)

But it isn't irrelevant either.  You seem to be arguing that just  
because one particular Ruby implementation needs to map "+" and "@+"  
to a common hash value and also needs to forbid non-identifier  
strings that all Ruby applications should accept that quirk in their  
use of Symbol-like hashing *or* that they should roll their own  
Symbol implementation (which of course wouldn't have the benefit of  
Symbol literals).

I would argue that there should be some sort of pure Symbol  
implementation as the 'primitive' functionality.  You can build  
'synonyms' on top of that implementation if you need them.  You can't  
do it the other way around.

Gary Wright




In This Thread