[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: array of object insert polices

Peña, Botp

6/1/2005 9:35:00 AM

dave [mailto:dave.m@email.it] wrote:

#and what if an user does x[2] = "i'm an integer :)"

You have to redefine all the others, too.

Eg, add this to integer array

....
def []= (index, other)
p "You entered #{other} thru index #{index}"
if other.class == Fixnum
p "That's an integer you're inserting. go!"
super index, other # call original insert method <<
else
p "nope: i'm sorry, only integers allowed"
end
end

....

irb(main):004:0> x[2]=2
"You entered 2 thru index 2"
"That's an integer you're inserting. go!"
=> 2
irb(main):005:0> x[3]="testing"
"You entered testing thru index 3"
"nope: i'm sorry, only integers allowed"
=> "testing"

It gets uglier as you go on :-) .... So you may have to listen to RobertK's
idea also.

thanks and kind regards -botp





13 Answers

dave

6/1/2005 9:57:00 AM

0


> It gets uglier as you go on :-):-) .... So you may have to listen to
RobertK's idea also.

which are (all) the methods should i filter?
[]=, <<..

-------------------------
class IA < Array
def ensure_int(obj)
raise TypeError, "Not an int: #{obj.inspect}" unless (Integer === obj)
end

def []= (index, other)
ensure_int(other)
super index, other
end
end
----------------------------------

isn't there any hack for this dirty work?


--
>here are more things in heaven and earth,
horatio, than are dreamt of in your philosophy.


Brian Schröder

6/1/2005 10:03:00 AM

0

On 01/06/05, dave <dave.m@email.it> wrote:
>
> > It gets uglier as you go on :-):-) .... So you may have to listen to
> RobertK's idea also.
>
> which are (all) the methods should i filter?
> []=, <<..
>
> -------------------------
> class IA < Array
> def ensure_int(obj)
> raise TypeError, "Not an int: #{obj.inspect}" unless (Integer === obj)
> end
>
> def []= (index, other)
> ensure_int(other)
> super index, other
> end
> end
> ----------------------------------
>
> isn't there any hack for this dirty work?
>
>

You should have a look at the thread:

Uniform vector class, inheriting from Array: How to make sure that
methods return a Vector and not an Array?
http://groups-beta.google.com/group/comp.lang.ruby/browse_frm/thread/8d339eecc8624556/4fafe7b359e0fcfb?q=uniform+vector+class&rnum=1&hl=en#4fafe7...

regards,

Brian

>


--
http://ruby.brian-sch...

Stringed instrument chords: http://chordlist.brian-sch...


dave

6/1/2005 11:13:00 AM

0



> You should have a look at the thread:
> Uniform vector class, inheriting from Array

> Duck typing.  Code that relies on ints in there will soon discover if
> someone puts something non numeric in there.

I had a look at Chapter 23 Duck Typing of Programming Ruby.

I understand that i haven't to validate imput type, this let me
a little bit lost.

>"Code that relies on ints will discover"
..and what if i write a class to calculate a productory and who uses
this class see something like that on the monitor:

"i'm an integer Hahhaaai'm an integer Hahhaaai'm an integer Hahhaaai'm an
integer Hahhaaai'm an integer Hahhaaai'm an integer Hahhaaai'm an integer
Hahhaaai'm an integer Hahhaaai'm an integer Hahhaaa"

(he wronged to parse an imput file `integers: 3 3`).


maybe unit tests can help me?

help me, please.


--
>here are more things in heaven and earth,
horatio, than are dreamt of in your philosophy.


Brian Schröder

6/1/2005 11:43:00 AM

0

On 01/06/05, dave <dave.m@email.it> wrote:
>
>
> > You should have a look at the thread:
> > Uniform vector class, inheriting from Array
>
> > Duck typing. Code that relies on ints in there will soon discover if
> > someone puts something non numeric in there.
>
> I had a look at Chapter 23 Duck Typing of Programming Ruby.
>
> I understand that i haven't to validate imput type, this let me
> a little bit lost.
>
> >"Code that relies on ints will discover"
> ..and what if i write a class to calculate a productory and who uses
> this class see something like that on the monitor:
>
> "i'm an integer Hahhaaai'm an integer Hahhaaai'm an integer Hahhaaai'm an
> integer Hahhaaai'm an integer Hahhaaai'm an integer Hahhaaai'm an integer
> Hahhaaai'm an integer Hahhaaai'm an integer Hahhaaa"
>
> (he wronged to parse an imput file `integers: 3 3`).
>
> maybe unit tests can help me?
>
> help me, please.
>
>

If you parse string input that should be converted to int you would
normally validate the input. Take for example a look at the highline
library for this purpose.

And what should the unit do if it is used in a wrong way? Throwing and
exception is normally a good idea. And this can be achieved simple by
method missing errors.

best regards,

Brian



--
http://ruby.brian-sch...

Stringed instrument chords: http://chordlist.brian-sch...


Robert Klemme

6/1/2005 11:45:00 AM

0

dave wrote:
>> You should have a look at the thread:
>> Uniform vector class, inheriting from Array
>
>> Duck typing. Code that relies on ints in there will soon discover if
>> someone puts something non numeric in there.
>
> I had a look at Chapter 23 Duck Typing of Programming Ruby.
>
> I understand that i haven't to validate imput type, this let me
> a little bit lost.

This is what happens if you calculate the product on an array that
contains non numeric values:

13:21:05 [source]: irbs
>> values=[1,2,3,"4"]
=> [1, 2, 3, "4"]
>> product = values.inject(1) {|x,e|x*e}
TypeError: String can't be coerced into Fixnum
from (irb):2:in `*'
from (irb):2
from (irb):2:in `inject'
from (irb):2:in `each'
from (irb):2:in `inject'
from (irb):2


>
>> "Code that relies on ints will discover"
> ..and what if i write a class to calculate a productory and who uses
> this class see something like that on the monitor:
>
> "i'm an integer Hahhaaai'm an integer Hahhaaai'm an integer
> Hahhaaai'm an integer Hahhaaai'm an integer Hahhaaai'm an integer
> Hahhaaai'm an integer Hahhaaai'm an integer Hahhaaai'm an integer
> Hahhaaa"
>
> (he wronged to parse an imput file `integers: 3 3`).
>
>
> maybe unit tests can help me?

Definitely.

> help me, please.

Maybe you can be a bit more specific on what exactly you are trying to
achieve and then people can come up with more concrete answers.

Kind regards

robert

Gavin Kistner

6/1/2005 12:38:00 PM

0

On Jun 1, 2005, at 3:35 AM, Peña, Botp wrote:
> def []= (index, other)
> p "You entered #{other} thru index #{index}"
> if other.class == Fixnum

As in Robert Klemme's example, you should use Integer and not Fixnum.
(Integer covers both Fixnum and Bignum).

Robert Klemme

6/1/2005 12:54:00 PM

0

Gavin Kistner wrote:
> On Jun 1, 2005, at 3:35 AM, Peña, Botp wrote:
>> def []= (index, other)
>> p "You entered #{other} thru index #{index}"
>> if other.class == Fixnum
>
> As in Robert Klemme's example, you should use Integer and not Fixnum.
> (Integer covers both Fixnum and Bignum).

Plus don't use "other.class == Integer" but "Integer === other" as this
covers sub classes and Integer has no instances.

robert

dave

6/1/2005 1:02:00 PM

0


> Maybe you can be a bit more specific on what exactly you are trying to
> achieve and then people can come up with more concrete answers.

I wanted to understand what i must check and how to have
a stable code.

are these rules right in general?

The imput comes directly from an external source:
- Test with test units.
- Check type and attinence to specifics of data.

The imput doesn't come from directly from an external source:
- Test with test units.
- Don't care about type (duck typing).




--
>here are more things in heaven and earth,
horatio, than are dreamt of in your philosophy.


Robert Klemme

6/1/2005 1:13:00 PM

0

dave wrote:
>> Maybe you can be a bit more specific on what exactly you are trying
>> to achieve and then people can come up with more concrete answers.
>
> I wanted to understand what i must check and how to have
> a stable code.
>
> are these rules right in general?
>
> The imput comes directly from an external source:
> - Test with test units.
> - Check type and attinence to specifics of data.
>
> The imput doesn't come from directly from an external source:
> - Test with test units.
> - Don't care about type (duck typing).

Yeah. These are good rules of thumb - especially when it comes to input
data.

robert

Glenn Parker

6/1/2005 2:30:00 PM

0

dave wrote:
>
> I wanted to understand what i must check and how to have
> a stable code.
>
> are these rules right in general?
>
> The imput comes directly from an external source:
> - Test with test units.
> - Check type and attinence to specifics of data.

Type checking is just plain ugly. It's hard to get it right, and it
tends to constrain the usefulness of your code.

If you need to do it, offer it as a separate, optional method that a
caller can run on their input to your code before the real method is
used. Only the caller really knows the best time and place to test
input, and you will avoid a lot of redundancy and overhead.

I would also consider unit tests that verify proper error-handling when
an incompatible object is encountered, either via an exception or an
error code, or whatever you deem appropriate.

Another option is to automatically invoke a coercion method like "to_i"
on all input.

> The imput doesn't come from directly from an external source:
> - Test with test units.
> - Don't care about type (duck typing).

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoi...