[#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 16:09:44 UTC
List: ruby-core #15275
On Jan 28, 2008, at 10:04 AM, Dave Thomas wrote:
>> 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.
> Here a I was meaning a Hash object, not to_hash.

You were talking about 'the works of Shakespere' as a symbol, which I  
assumed meant the mapping of an arbitrary string to a smaller value  
for fast comparisons.  That isn't a Ruby Hash object it is a  
mathematical hash function.  So I guess I just don't understand what  
you meant by that example.

> I just don't see the need to burden the language with a complex  
> feature with dubious semantics to implement a little used feature  
> that can be implemented trivially using existing constructs. So, I  
> agree with you--a gem is where this belongs.

How can a 'complex feature' also be implemented 'trivially'?
How can you provide the string literal notational convenience with a  
gem?
How can you avoid the per object overhead of a full instance of Object?
Do you really think that String#to_sym is 'little used'?

I don't see the need for the Ruby interpreter to export the dubious  
Perfect-Hash-Except-for-some-Ruby-Specific-Synonyms semantics to  
implement a feature only needed by the Ruby interpreter that can be  
implemented trivially using a pure-Symbol and a Hash table: it is  
just a two-level hash:

      Canonical[Symbol[string]]     # convert string to canonical  
internal symbol

You can't easily do it the other way around. Might as well not use  
Canonical at all and roll your own.  So either everyone rolls their  
own, or everyone uses some popular gem, in which case it should  
probably be in core anyway.

This is somewhat academic.  In the real world there are three options:

   a) leave Symbol alone with its current RubyInternalSymbol  
semantics ("@+"...)
   b) make Symbol 'pure' and change Ruby's internals
   c) make Symbol 'strict' and break lots of programs

I can live with 'a', would prefer 'b', and think 'c' is a bad idea.


In This Thread