#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.
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`).
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
···
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`).
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.
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).
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.
There's probably a misunderstanding: you seem to talk about internal type
checking for which I completely agree to you. But dave was talking about
external data here IMHO. And it's generally considered good practice to
check data entered by users or coming into an application via other
external sources to make the application robust.
There's probably a misunderstanding: you seem to talk about internal type
checking for which I completely agree to you. But dave was talking about
external data here IMHO. And it's generally considered good practice to
check data entered by users or coming into an application via other
external sources to make the application robust.
Good practice should be a guideline, not a mantra. There are good reasons for checking external data, but they don't always apply, and checking every argument to every function on every invokation can be a real waste.
Sometimes you want to give a caller immediate feedback about an input error, but sometimes you may be happy to let them proceed, allowing the *possibility* of failure later on. Actual failure may depend very much on exactly what the caller chooses to do and what kind of objects they provide. With duck-typing, there is always a fair chance that some portion of your API may peform properly, even with objects that were never anticipated.
For example, I might insert Integer-like objects, that do not support "<=>", into an IntegerArray object. As long as I don't rely on some kind of "sort_members" method, it seems like I should be OK.
When argument testing really is necessary, a compromise is to offer the testing function to the caller as a separate utility. That way, callers can test their input when they think it is necessary, but skip the test when they know it isn't. This also allows the caller to push past the limits of your original API design by using arguments that satisfy the necessary subset of duck-typing for some subset of your API, even if they can't pass the full argument testing predicate.
There's probably a misunderstanding: you seem to talk about internal
type checking for which I completely agree to you. But dave was
talking about external data here IMHO. And it's generally
considered good practice to check data entered by users or coming
into an application via other external sources to make the
application robust.
Good practice should be a guideline, not a mantra. There are good
reasons for checking external data, but they don't always apply, and
checking every argument to every function on every invokation can be a
real waste.
I get the feeling that for some reason you think you have to object me.
Maybe I was not clear enough or whatever, but I'm far from propagating
mantras. And I completely agree with you that type checking should not
normally be built into methods. Offering type checking as separate
functionality is certainly a good practice and makes people's lives
easier. I definitely stick with my prior statement that *if* you want to
make an application robust you *should* check data whose source you do not
know or cannot control. Of course you can make it robust in different
ways, for example wrap processing of user data in a begin rescue block and
catch any exceptions to prevent termination. But depending on the nature
and complexity of processing a user might not be able to figure from an
exception what was wrong with his input. So from a user's perspective
it's certainly the preferrable experience to get a notice that this and
that was wrong about his input.
.... So you may have to listen to RobertK's
.... So you may have to listen to