Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Add Array#first= and Array#last= to std lib

Reply
Thread Tools

Add Array#first= and Array#last= to std lib

 
 
Robert Klemme
Guest
Posts: n/a
 
      12-28-2007
2007/12/28, Yu-raku-an <(E-Mail Removed)>:
> Hi, Robert,
>
> In this case, I think the best way for you is to do it by yourself.
> You can override an existing class in Ruby, even the one is a standard
> library class.


I am aware of that, thanks. The whole point of this discussion was to
find out whether there are serious reasons why one should not have
this in the standard lib. Array#first and #last *are* in the standard
lib already and at the moment I do not see any reason why Array#first=
and Array#last= should not be.

Kind regards

robert


--
use.inject do |as, often| as.you_can - without end

 
Reply With Quote
 
 
 
 
Sebastian Hungerecker
Guest
Posts: n/a
 
      12-28-2007
Robert Klemme wrote:
> On 27.12.2007 22:58, Sebastian Hungerecker wrote:
> > bbiker wrote:
> >> There's is no need for Array#last= or Array#first=
> >> since you can simply use an_array[-1] += 1 or an_array[0] += 1

> >
> > There is no need for Array#last or Array#first
> > since you can simply use an_array[-1] or an_array[0]

>
> With the same argument you can throw out a lot of library methods
> because there is "no need" for them. I do not count that as an argument
> against.


I'm not quite sure whether you're talking to bbiker or me, but if you're
talking to me:
Yes, that was the point I was trying to make. I'm on your side, remember?
(Well, mostly anyway)


--
Jabber: http://www.velocityreviews.com/forums/(E-Mail Removed)
ICQ: 205544826

 
Reply With Quote
 
 
 
 
Sebastian Hungerecker
Guest
Posts: n/a
 
      12-28-2007
Robert Klemme wrote:
> I do not see why allowing last= would make lasts(n)= necessary.


For consistency. I believe that any method foo= should be equivalent to the
method foo except for the fact that it sets the value instead of getting it,
which in this case isn't possible (without changing the language). I mean,
that's not a major problem, but it'd feel a tad incosistent to me.


--
Jabber: (E-Mail Removed)
ICQ: 205544826

 
Reply With Quote
 
Sebastian Hungerecker
Guest
Posts: n/a
 
      12-28-2007
Robert Klemme wrote:
> So far the only argument against I have seen so far is the question
> about assignment to an empty array. =A0In that case I'd say, either raise
> an exception or silently add the element. =A0Have to think about this a b=

it.

I really don't think that's much of an argument. Since last=3D would be=20
equivalent to [-1]=3D in every other case, it should behave like it in
this case as well (meaning raise an exception) and if last=3D uses []=3D
(which I assume, it would) that would automatically be the case anyway.


=2D-=20
Jabber: (E-Mail Removed)
ICQ: 205544826

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      12-28-2007
2007/12/28, Sebastian Hungerecker <(E-Mail Removed)>:
> Robert Klemme wrote:
> > I do not see why allowing last= would make lasts(n)= necessary.

>
> For consistency. I believe that any method foo= should be equivalent to the
> method foo except for the fact that it sets the value instead of getting it,
> which in this case isn't possible (without changing the language). I mean,
> that's not a major problem, but it'd feel a tad incosistent to me.


You're right. Actually I was not aware that you could actually use an
argument with last. Thanks for pointing that out!

And I agree, that changes the situation a bit. As a workaround you
could implicitly use the number of elements when assigning an Array
but I doubt it's a good idea. What if you wanted the last element to
be that array and not replace the last n elements? That situation
could not be distinguished. Hm...

Re your other posting: yes, making last= behave like [-1]= is
certainly a good idea. So it's "throw an exception".

irb(main):004:0> a=[]
=> []
irb(main):005:0> a[-1]=123
IndexError: index -1 out of array
from (irb):5:in `[]='
from (irb):5
from :0

Also a tad inconsistent:

irb(main):006:0> a[0]=123
=> 123
irb(main):007:0> a
=> [123]

So at least I now have an idea why last= is absent from the std lib.
So the discussion was definitively worthwhile.

Kind regards

robert

--
use.inject do |as, often| as.you_can - without end

 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      12-28-2007


On Dec 28, 6:39 am, "Robert Klemme" <(E-Mail Removed)>
wrote:
> 2007/12/28, Sebastian Hungerecker <(E-Mail Removed)>:
>
> > Robert Klemme wrote:
> > > I do not see why allowing last= would make lasts(n)= necessary.

>
> > For consistency. I believe that any method foo= should be equivalent to the
> > method foo except for the fact that it sets the value instead of getting it,
> > which in this case isn't possible (without changing the language). I mean,
> > that's not a major problem, but it'd feel a tad incosistent to me.

>
> You're right. Actually I was not aware that you could actually use an
> argument with last. Thanks for pointing that out!
>
> And I agree, that changes the situation a bit. As a workaround you
> could implicitly use the number of elements when assigning an Array
> but I doubt it's a good idea. What if you wanted the last element to
> be that array and not replace the last n elements? That situation
> could not be distinguished. Hm...


> So at least I now have an idea why last= is absent from the std lib.
> So the discussion was definitively worthwhile.


I see it from a different pov: Wasted Semantics. Regardless of the
fact that #first and #last can take an _optional_ argument, #first=
and #last= are both semantically obvious and would take up essentially
no new space in the ruby "dictionary" (to use a Forth term). So, NOT
having them is a waste of resources.

Also, it's not inconceivable that they could provide some added value
by being different form [0], [-1] by not throwing an error.

T.

 
Reply With Quote
 
Robert Dober
Guest
Posts: n/a
 
      12-29-2007
On Dec 27, 2007 7:52 PM, Trans <(E-Mail Removed)> wrote:
>
>
>
> On Dec 27, 12:54 pm, MonkeeSage <(E-Mail Removed)> wrote:
> > On Dec 27, 9:55 am, Sebastian Hungerecker <(E-Mail Removed)>
> > wrote:
> >
> > > George wrote:
> > > > What would you expect this to do?

> >
> > > > [].last = 1

> >
> > > The same thing as "[][-1] = 1", I'd imagine.
> > > The problem I'm seeing would be this: If you allow arr.last = x, you'd also
> > > have to allow arr.last(n) = x if you want to be consistent, but that's not
> > > syntactically possible.

> >
> > > --
> > > NP: Katatonia - Endtime
> > > Jabber: (E-Mail Removed)
> > > ICQ: 205544826

> >
> > Agree. It's tempting to treat #first / #last as 0 / -1, but in
> > actuality they are method calls and simply return a value; they don't
> > subscript an array. Setting #last is not semantically different than
> > [1,2,3].pop = 4, it's just that #last is just a bit more subtle.

>
> I don't see what you are getting at here. #pop is destructive, #last
> is not. What does #last return when it is called? It returns a
> reference to the last element. So why would #last= do anything other
> then set the reference of the last element? Seems obvious to me. So we
> can't do last(n) = x, due to syntax constraints, oh well. It would
> still be convenient to have the obvious n=1, no arg case. I find that
> my programs are usually easier to read when I can use words rather non-
> alphabetic symbols.
>
> T.
>

Amen, big +1, I guess lots of us define #last= and #first=, I do it,
it is just that readable and I did not even check the
doc before trying to use it first, I hate to be disappointed by my
favorite language

Cheers
Robert
>




--

http://ruby-smalltalk.blogspot.com/

---
All truth passes through three stages. First, it is ridiculed. Second,
it is violently opposed. Third, it is accepted as being self-evident.
Schopenhauer (attr.)

 
Reply With Quote
 
bbiker
Guest
Posts: n/a
 
      12-29-2007
On Dec 28, 6:39*am, Robert Klemme <(E-Mail Removed)> wrote:
> 2007/12/28, Sebastian Hungerecker <(E-Mail Removed)>:
>
> > Robert Klemme wrote:
> > > I do not see why allowing last= would make lasts(n)= necessary.

>
> > For consistency. I believe that any method foo= should be equivalent to the
> > method foo except for the fact that it sets the value instead of gettingit,
> > which in this case isn't possible (without changing the language). I mean,
> > that's not a major problem, but it'd feel a tad incosistent to me.

>
> You're right. Actually I was not aware that you could actually use an
> argument with last. Thanks for pointing that out!
>
> And I agree, that changes the situation a bit. *As a workaround you
> could implicitly use the number of elements when assigning an Array
> but I doubt it's a good idea. *What if you wanted the last element to
> be that array and not replace the last n elements? *That situation
> could not be distinguished. Hm...
>
> Re your other posting: yes, making last= behave like [-1]= is
> certainly a good idea. *So it's "throw an exception".
>
> irb(main):004:0> a=[]
> => []
> irb(main):005:0> a[-1]=123
> IndexError: index -1 out of array
> * * * * from (irb):5:in `[]='
> * * * * from (irb):5
> * * * * from :0
>
> Also a tad inconsistent:
>
> irb(main):006:0> a[0]=123
> => 123
> irb(main):007:0> a
> => [123]
>
> So at least I now have an idea why last= is absent from the std lib.
> So the discussion was definitively worthwhile.
>
> Kind regards
>
> robert
>
> --
> use.inject do |as, often| as.you_can - without end


I mho, making #last= and #first= adds nothing to ruby, the ability is
already available. So why bloat ruby unnecessarily?
 
Reply With Quote
 
MonkeeSage
Guest
Posts: n/a
 
      12-29-2007
On Dec 27, 1:58 pm, Sebastian Hungerecker <(E-Mail Removed)>
wrote:
> MonkeeSage wrote:
> > On Dec 27, 1:38 pm, Sebastian Hungerecker wrote:
> > > MonkeeSage wrote:
> > > > IOW, #pop returns a value, and this is just what #last does.

>
> > > How is [] different in that regard? That only returns a value, too.

>
> > Exactly. It's not... [] = 3 => syntax error...

>
> That [] there is an emtpy array. That's not the [] I was talking about.
> I'm sorry if I wasn't clear, let me rephrase:
> You seemed to say that while there is a method Array#[]= (which I assume,
> you're ok with, since you haven't stated otherwise), there shouldn't be a
> method Array#last= since Array#last only returns a value like Array#pop does.
> Now my question to you is: How is Array#[] different in that regard than
> Array#last? I mean some_array[-1] also only returns a value. But you don't
> have a problem with people being able to write some_array[-1] = some_value
> do you?
>
> --
> Jabber: (E-Mail Removed)
> ICQ: 205544826


Sebastian (and Robert),

I guess I wasn't being very clear. By saying that #last just returns a
value like #pop, my point was that #last is the semantic equivalent of
the example I gave: "def l(a); a[-1]; end". I should have probably
compared it to #length rather than #pop since #pop is destructive.

I wasn't arguing for or against #last=, per se; I was only trying to
explain why it doesn't make sense, _to me_, "Unless the semantics [of
#last] change," to have #last=. I.e., #[] subscripts the array and
returns the value of the index, but #last returns the value of
subscripting the array at index #length-1; it is another level of
abstraction removed from #[]; so with those semantics, #last= would be
like #length= (or #pop=), and you end up with exceptions when the
value is immutable.

Regards,
Jordan
 
Reply With Quote
 
Gary Wright
Guest
Posts: n/a
 
      12-30-2007

On Dec 29, 2007, at 6:24 PM, MonkeeSage wrote:
> I wasn't arguing for or against #last=, per se; I was only trying to
> explain why it doesn't make sense, _to me_, "Unless the semantics [of
> #last] change," to have #last=. I.e., #[] subscripts the array and
> returns the value of the index, but #last returns the value of
> subscripting the array at index #length-1; it is another level of
> abstraction removed from #[]; so with those semantics, #last= would be
> like #length= (or #pop=), and you end up with exceptions when the
> value is immutable.



Why do you shift your terminology when talking about last? Using
your terminology but my mental model of arrays:

#[n] subscripts the array with n and returns the value of the index
#[-1] subscripts the array with (length-1) and returns the value of
the index
#last subscripts the array with (length-1) and returns the value of
the index

Why do you rephrase that last case as:

#last returns the value of subscripting the array at index #length-1

Are you suggesting that #last does something distinctly different than
subscripting via -1? If not then it would seem your argument against
last=
would apply just as well to 'array[-1] = x'. Are you suggesting that
element assignment with negative subscripts also don't make sense to
you?

Objections to last= and first= based on redundancy is one thing, but
you seem to be objecting based on semantics and I'm trying to understand
that objection because the semantics seem to be quite natural to me.

Gary Wright

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
/usr/bin/ld: ../../dist/lib/libjsdombase_s.a(BlockGrouper.o)(.text+0x98): unresolvable relocation against symbol `std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostre silverburgh.meryl@gmail.com C++ 3 03-09-2006 12:14 AM
error: 'std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private Geoffrey S. Knauth C++ 6 01-18-2006 11:48 AM
xServices::CServices<TImp>::StHoldClientList::StHoldClientList(std::set<TImp*, std::less<TImp*>, std::allocator<TImp*> >&)': Vinu C++ 4 07-07-2005 06:08 AM
xServices::CServices<TImp>::StHoldClientList::StHoldClientList(std::set<TImp*, std::less<TImp*>, std::allocator<TImp*> >&)': Vinu C++ 0 07-06-2005 12:45 PM
std::map<int,std::set<std::string> > Wrong? (Segmentation fault.) Peter Jansson C++ 5 03-17-2005 06:34 AM



Advertisments