[#5322] O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...>

I just did some benchmarks on push, pop, shift, and unshift

24 messages 2005/07/01
[#5338] Re: O(1) performance for insertions/deletions at the front of an Array/String — Mathieu Bouchard <matju@...> 2005/07/02

On Fri, 1 Jul 2005, Eric Mahurin wrote:

[#5348] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/02

--- Mathieu Bouchard <matju@artengine.ca> wrote:

[#5357] Re: O(1) performance for insertions/deletions at the front of an Array/String — Mathieu Bouchard <matju@...> 2005/07/03

On Sat, 2 Jul 2005, Eric Mahurin wrote:

[#5359] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/03

--- Mathieu Bouchard <matju@artengine.ca> wrote:

[#5361] Re: O(1) performance for insertions/deletions at the front of an Array/String — Mathieu Bouchard <matju@...> 2005/07/03

On Sun, 3 Jul 2005, Eric Mahurin wrote:

[#5362] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/03

--- Mathieu Bouchard <matju@artengine.ca> wrote:

[#5365] Re: O(1) performance for insertions/deletions at the front of an Array/String — Yukihiro Matsumoto <matz@...> 2005/07/04

Hi,

[#5367] Re: O(1) performance for insertions/deletions at the front of an Array/String — Eric Mahurin <eric_mahurin@...> 2005/07/04

--- Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#5368] Re: O(1) performance for insertions/deletions at the front of an Array/String — Yukihiro Matsumoto <matz@...> 2005/07/04

Hi,

[#5372] Re: O(1) performance for insertions/deletions at the front of an Array/String — Florian Gro<florgro@...> 2005/07/04

Yukihiro Matsumoto wrote:

[#5420] Sydney Developer Preview 1 released — Evan Webb <evanwebb@...>

Sydney, an experimental ruby interpreter, has been released!

15 messages 2005/07/11
[#5424] Re: [ANN] Sydney Developer Preview 1 released — Evan Webb <evanwebb@...> 2005/07/12

Thanks everyone for the feedback so far!

Re: Object#=~

From: Eric Mahurin <eric_mahurin@...>
Date: 2005-07-06 18:15:49 UTC
List: ruby-core #5407
--- Eric Hodel <drbrain@segment7.net> wrote:

> On 06 Jul 2005, at 10:06, Eric Mahurin wrote:
> 
> > --- Eric Hodel <drbrain@segment7.net> wrote:
> >
> >> On 06 Jul 2005, at 09:30, Eric Mahurin wrote:
> >>
> >>>> <dooby@d10.karoo.co.uk> writes:
> >>>>
> >>>>> I expected you to say that this was intentionally
> provided as a  
> >>>>> "third state":
> >>>>>
> >>>>> true  - positive pattern match result
> >>>>> nil   - negative pattern match result
> >>>>> false - don't know (no match was done)
> >>>
> >>> Should nil be don't know and false be mismatch?  That
> would be
> >>> consistent with <=> which returns nil if the items aren't
> >>> comparable.  Maybe the same should be done with == and
> ===
> >>> return nil instead of false when the 2 objects can't be
> >>> compared.
> >>
> >> $ ruby -e 'p "f" =~ /x/'
> >> nil
> >
> > "f" vs. /x/ are comparable so I was thinking false might be
> > more  suitable than nil.
> 
> This would not be a backwards compatible change.  daz's
> suggestion  
> simply defines a convention for existing behavior, which
> feels much  
> better to me.

both are changes and both could cause compatibility issues.  I
think either way causing a compatibility issue would be rare,
although I have to admit the unknown==nil/mismatch==false would
probably be more likely.  unknown==nil and mismatch==false
seems more natural and if a change is going to be made it might
as well be done right.

> > And use nil when it is the wrong type
> > of object or doesn't respond to the right methods.  I'm
> > suggesting that comparison operator methods look something
> like
> > this:
> >
> > def ===(obj) # or <=>, ==, =~
> >     return(nil) if obj isn't comparable to self
> >     ... compare returning false instead of nil ...
> > end
> 
> Where in Ruby are two objects not comparable via #=== or #==?

1=="hi"
(1..4)==="hi"

These return false right now, but I think unknown/nil is better
to distinguish from these cases (which are also false):

1==0.0
(1..4)===5

For most other methods, the first case where you are doing
something with an incompatible object results in an exception. 
I think returning nil for equality operators makes sense for
that case.



		
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.  
http://auctions.yahoo.com/

In This Thread