Framework functions - 'object' typed parameters too weak?

Hello all

Here's the prototype for a System.Convert method.

public static int ToInt32(object value);

The documentation states that the parameter 'value' is an Object that
implements the IConvertible interface. It adds that an exception
InvalidCastException is thrown if 'value' does not implement that
interface.

Isn't this odd? Why doesn't the function take an IConvertible
reference? Wouldn't that strengthen the function's contract as this is
what is surely uses and requires?

Thanks for any clarification

Emma Middlebrook
emma_middlebrook@fastmail.fm

BenoitM
Fri Jul 25 02:49:18 CDT 2003

you're right, it would be better...

the only method in the Convert class that should accept an object is
ToString(object value), since it doesn't need a IConvertible...
perhaps they wanted all the method to accept the same kind of arguments ???

anyway it's strange ...

"emma middlebrook" <emma_middlebrook@fastmail.fm> wrote in message
news:e27ae805.0307240544.2418ac71@posting.google.com...
> Hello all
>
> Here's the prototype for a System.Convert method.
>
> public static int ToInt32(object value);
>
> The documentation states that the parameter 'value' is an Object that
> implements the IConvertible interface. It adds that an exception
> InvalidCastException is thrown if 'value' does not implement that
> interface.
>
> Isn't this odd? Why doesn't the function take an IConvertible
> reference? Wouldn't that strengthen the function's contract as this is
> what is surely uses and requires?
>
> Thanks for any clarification
>
> Emma Middlebrook
> emma_middlebrook@fastmail.fm

Ron
Fri Jul 25 01:43:00 CDT 2003

One problem with the explicitly cast is code bloat.


Ron
"BenoitM" <Benoit_Mich@hotmail.Com> wrote in message
news:uiXjtCoUDHA.1676@TK2MSFTNGP10.phx.gbl...
> you're right, it would be better...
>
> the only method in the Convert class that should accept an object is
> ToString(object value), since it doesn't need a IConvertible...
> perhaps they wanted all the method to accept the same kind of arguments
???
>
> anyway it's strange ...
>
> "emma middlebrook" <emma_middlebrook@fastmail.fm> wrote in message
> news:e27ae805.0307240544.2418ac71@posting.google.com...
> > Hello all
> >
> > Here's the prototype for a System.Convert method.
> >
> > public static int ToInt32(object value);
> >
> > The documentation states that the parameter 'value' is an Object that
> > implements the IConvertible interface. It adds that an exception
> > InvalidCastException is thrown if 'value' does not implement that
> > interface.
> >
> > Isn't this odd? Why doesn't the function take an IConvertible
> > reference? Wouldn't that strengthen the function's contract as this is
> > what is surely uses and requires?
> >
> > Thanks for any clarification
> >
> > Emma Middlebrook
> > emma_middlebrook@fastmail.fm
>
>

BenoitM
Fri Jul 25 06:55:56 CDT 2003

what does mean 'code bloat' ?


"Ron Bullman" <ron.bulman@mail.com> wrote in message
news:#fCeBIqUDHA.584@TK2MSFTNGP12.phx.gbl...
> One problem with the explicitly cast is code bloat.
>
>
> Ron
> "BenoitM" <Benoit_Mich@hotmail.Com> wrote in message
> news:uiXjtCoUDHA.1676@TK2MSFTNGP10.phx.gbl...
> > you're right, it would be better...
> >
> > the only method in the Convert class that should accept an object is
> > ToString(object value), since it doesn't need a IConvertible...
> > perhaps they wanted all the method to accept the same kind of arguments
> ???
> >
> > anyway it's strange ...
> >
> > "emma middlebrook" <emma_middlebrook@fastmail.fm> wrote in message
> > news:e27ae805.0307240544.2418ac71@posting.google.com...
> > > Hello all
> > >
> > > Here's the prototype for a System.Convert method.
> > >
> > > public static int ToInt32(object value);
> > >
> > > The documentation states that the parameter 'value' is an Object that
> > > implements the IConvertible interface. It adds that an exception
> > > InvalidCastException is thrown if 'value' does not implement that
> > > interface.
> > >
> > > Isn't this odd? Why doesn't the function take an IConvertible
> > > reference? Wouldn't that strengthen the function's contract as this is
> > > what is surely uses and requires?
> > >
> > > Thanks for any clarification
> > >
> > > Emma Middlebrook
> > > emma_middlebrook@fastmail.fm
> >
> >
>
>

Jon
Fri Jul 25 10:48:45 CDT 2003

Ron Bullman <ron.bulman@mail.com> wrote:
> Shortly, redundant code.
>
> (From Encarta Dictionary (US English) bloat is defined as excessive increase
> [an excessive amount or excessive increase in something])
>
> In this particular case consider situation hundreds of callers calling
> Convert and each explicitly casting, instead of doing that inside the
> Convert.

Why would they need to cast though? How often does the caller actually
not know the type of the parameter? Why is your argument valid for this
example but not for all the other methods in the framework?

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Ron
Fri Jul 25 11:49:33 CDT 2003

Jon,

Aha, semantics! Perhaps I misunderstod the OP's original intention, but is
it totally wrong to interpret that "take an IConvertible reference" means
casting? If so, then clearly my answer is not valid ;-(. (It also means then
that I have misunderstod "Wouldn't that strengthen the function's contract"
to imply the contract between programmer and code, but not the contract
between code and compiler. Still thinking too much C like, where you were
heavily depend also on the contract between programmer and code. How creat
the C# is indeed ;-).

But it still remains open why it's implemented as object instead of
IConvertible. Yes, if its IConvertible, then it will "improve compile-time
safety", but why implemented as object? Perhaps it's finally time for me to
download the SSCLI and study that more carefully.


Ron
"Jon Skeet" <skeet@pobox.com> wrote in message
news:MPG.198b79d63503a0b398a20c@news.microsoft.com...
> Ron Bullman <ron.bulman@mail.com> wrote:
> > Please don't change the context.
>
> I really don't think I did.
>
> OP was spekulating
> > > > > > > Isn't this odd? Why doesn't the function take an IConvertible
> > > > > > > reference? Wouldn't that strengthen the function's contract as
> > this
> > casting to IConvertible would increase code bloat. (Which might be a
problem
> > or not).
>
> Your quoting here is unclear - the "casting to IConvertible" was not
> part of the OP's post, and is usually only necessary simply *because*
> the method signature specifies Object instead of IConvertible.
>
> > Any other toughts related to the OP's question?
>
> My post *did* relate to the OP's question, and to your answer. Here are
> my thoughts again:
>
> o Yes, it would be better if the method took an IConvertible argument
> instead of an Object argument. It would improve compile-time safety.
>
> o No, I don't accept the argument that it would increase code bloat, as
> only very rarely would casting be necessary: for the majority of cases,
> the caller's reference type is known to implement IConvertible, so
> there'd be no need to cast at all.
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet/
> If replying to the group, please do not mail me too

Jon
Fri Jul 25 16:58:06 CDT 2003

Ron Bullman <ron.bulman@mail.com> wrote:
> Aha, semantics! Perhaps I misunderstod the OP's original intention, but is
> it totally wrong to interpret that "take an IConvertible reference" means
> casting?

Yes, in my opinion. He was proposing (as I understood it) that the
method signature be changed from:

public static int ToInt32(object value);
to
public static int ToInt32(IConvertible value);

That certainly wouldn't always involve casting on the caller's side.

> If so, then clearly my answer is not valid ;-(. (It also means then
> that I have misunderstod "Wouldn't that strengthen the function's contract"
> to imply the contract between programmer and code, but not the contract
> between code and compiler.

Right.

> Still thinking too much C like, where you were
> heavily depend also on the contract between programmer and code. How creat
> the C# is indeed ;-).

:)

> But it still remains open why it's implemented as object instead of
> IConvertible. Yes, if its IConvertible, then it will "improve compile-time
> safety", but why implemented as object? Perhaps it's finally time for me to
> download the SSCLI and study that more carefully.

Well, from my copy of Rotor:

public static int ToInt32(object value) {
return value == null? 0: ((IConvertible)value).ToInt32(null);
}

So basically changing it to take IConvertible would be trivial.

My guess is that it was a design mistake in the framework. It's not the
only one, and it's not surprising. I really can't see any good reason
for it being as it is...

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Ron
Fri Jul 25 12:35:14 CDT 2003

Jon,

You are absolutly right! Thanks for guiding me/ us ;-).


Ron
"Jon Skeet" <skeet@pobox.com> wrote in message
news:MPG.198bb82eb7302c098a217@news.microsoft.com...
> Ron Bullman <ron.bulman@mail.com> wrote:
> > Aha, semantics! Perhaps I misunderstod the OP's original intention, but
is
> > it totally wrong to interpret that "take an IConvertible reference"
means
> > casting?
>
> Yes, in my opinion. He was proposing (as I understood it) that the
> method signature be changed from:
>
> public static int ToInt32(object value);
> to
> public static int ToInt32(IConvertible value);
>
> That certainly wouldn't always involve casting on the caller's side.
>
> > If so, then clearly my answer is not valid ;-(. (It also means then
> > that I have misunderstod "Wouldn't that strengthen the function's
contract"
> > to imply the contract between programmer and code, but not the contract
> > between code and compiler.
>
> Right.
>
> > Still thinking too much C like, where you were
> > heavily depend also on the contract between programmer and code. How
creat
> > the C# is indeed ;-).
>
> :)
>
> > But it still remains open why it's implemented as object instead of
> > IConvertible. Yes, if its IConvertible, then it will "improve
compile-time
> > safety", but why implemented as object? Perhaps it's finally time for me
to
> > download the SSCLI and study that more carefully.
>
> Well, from my copy of Rotor:
>
> public static int ToInt32(object value) {
> return value == null? 0: ((IConvertible)value).ToInt32(null);
> }
>
> So basically changing it to take IConvertible would be trivial.
>
> My guess is that it was a design mistake in the framework. It's not the
> only one, and it's not surprising. I really can't see any good reason
> for it being as it is...
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet/
> If replying to the group, please do not mail me too

emma_middlebrook
Wed Jul 30 05:54:41 CDT 2003

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow@email.msn.com> wrote in message news:<OMargfSVDHA.2212@TK2MSFTNGP12.phx.gbl>...
> Jon,
> I suspect changing the signature to:
>
> > public static int ToInt32(IConvertible value);
>
> Would be a mistake because of the System.Data library.
>
> As well as any other framework function that relies on IConvertible would
> then need to encapsulate the cast. ArrayList.ToArray? ICollection.CopyTo?
> Granted for functions inside the framework this is not as big deal, as for
> functions that I may be using heavily.
>
> Given an array of Objects, I can call Convert.To* on any item in the array.
> Whereas if the signature was changed then I need to do the cast to
> IConvertible. Seeing System.Data.DataRow has an array of Object for the
> values (the index/item property), I can call Convert.To* as is, such as:
>
> Dim dr As DataRow
>
> w = Convert.ToInt32(dr.Item(0))
> x = Convert.ToString(dr.Item(1))
> y = Convert.ToBoolean(dr(2))
> z = Convert.ToDouble(dr(3))
>
> Without needing to have a bunch of casts to IConvertible in the above.
>
> > My guess is that it was a design mistake in the framework. It's not the
> > only one, and it's not surprising. I really can't see any good reason
> > for it being as it is...
>
> So in the long run, IConvertible value may appear to make sense, I think it
> would be the 'design mistake'.

Jay

I don't understand. The implementation of ToInt32 involves a cast to
IConvertible *internally* in order to do any useful work so the
method's parameter is too weakly typed *according to the
implementation*. Is this fact actually debatable?

I don't understand the example you give: your calling To* methods
code. What does this example show? You know a priori the format in
which you intend to convert your data row column values because you're
calling particular methods and so you know those methods' signatures!
I don't think this presents an argument against my conjecture.

Hoping that you or someone can explain a little further for me.

Thanks

Emma Middlebrook
emma_middlebrook@fastmail.fm

Jay
Wed Jul 30 08:57:25 CDT 2003


Emma,
> I don't understand. The implementation of ToInt32 involves a cast to
> IConvertible *internally* in order to do any useful work so the
> method's parameter is too weakly typed *according to the
> implementation*. Is this fact actually debatable?
I am not debating that. What I am debating is the suggestion that it was a
design mistake.

> I don't understand the example you give: your calling To* methods
> code. What does this example show? You know a priori the format in
> which you intend to convert your data row column values because you're
> calling particular methods and so you know those methods' signatures!

System.Data.DataRow.Item returns an Object.

Convert.ToInt32 accepts an Object.

The call Convert.ToInt32(dataRow.item(0)) would be calling
Convert.ToInt32(Object obj).

If Convert.ToInt32(Object obj) changed to be Convert.ToInt32(IConvertible
obj) which I agree is more semantically correct:

Convert.ToInt32(dataRow.item(0))

Would receive a compile error, unless I added the cast to IConvertible,
which would again be more semantically correct. However the amount of code I
need to write, just 'doubled', a wrapper function would be called for. I
would probably wrap the entire Convert class. Those wrappers are currently
embedded inside of Convert.ToInt32(Object obj).

The other options would be:
- To change DataRow.Item to be IConvertible instead of Object. Then what
about the case where DataRow is returning an IStream or an Image or some
other class where IConvertible does not make sense?
- To change DataRow to have type safe methods similar to DataReader, which
then looses the benefits of being an indexer.

> I don't think this presents an argument against my conjecture.
I know. ;-) In that you are convinced that it needs to be IConvertible, from
a semantically point of view, I agree. However! I am trying to show that it
would cause extra coding when you attempt to apply the Convert class to
other classes in the Framework such as DataRow.

Hope this helps
Jay

"emma middlebrook" <emma_middlebrook@fastmail.fm> wrote in message
news:e27ae805.0307300254.8ab43@posting.google.com...
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow@email.msn.com> wrote in
message news:<OMargfSVDHA.2212@TK2MSFTNGP12.phx.gbl>...
> > Jon,
> > I suspect changing the signature to:
> >
> > > public static int ToInt32(IConvertible value);
> >
> > Would be a mistake because of the System.Data library.
> >
> > As well as any other framework function that relies on IConvertible
would
> > then need to encapsulate the cast. ArrayList.ToArray?
ICollection.CopyTo?
> > Granted for functions inside the framework this is not as big deal, as
for
> > functions that I may be using heavily.
> >
> > Given an array of Objects, I can call Convert.To* on any item in the
array.
> > Whereas if the signature was changed then I need to do the cast to
> > IConvertible. Seeing System.Data.DataRow has an array of Object for the
> > values (the index/item property), I can call Convert.To* as is, such as:
> >
> > Dim dr As DataRow
> >
> > w = Convert.ToInt32(dr.Item(0))
> > x = Convert.ToString(dr.Item(1))
> > y = Convert.ToBoolean(dr(2))
> > z = Convert.ToDouble(dr(3))
> >
> > Without needing to have a bunch of casts to IConvertible in the above.
> >
> > > My guess is that it was a design mistake in the framework. It's not
the
> > > only one, and it's not surprising. I really can't see any good reason
> > > for it being as it is...
> >
> > So in the long run, IConvertible value may appear to make sense, I think
it
> > would be the 'design mistake'.
>
> Jay
>
> I don't understand. The implementation of ToInt32 involves a cast to
> IConvertible *internally* in order to do any useful work so the
> method's parameter is too weakly typed *according to the
> implementation*. Is this fact actually debatable?
>
> I don't understand the example you give: your calling To* methods
> code. What does this example show? You know a priori the format in
> which you intend to convert your data row column values because you're
> calling particular methods and so you know those methods' signatures!
> I don't think this presents an argument against my conjecture.
>
> Hoping that you or someone can explain a little further for me.
>
> Thanks
>
> Emma Middlebrook
> emma_middlebrook@fastmail.fm

Jon
Wed Jul 30 09:32:23 CDT 2003

Jay B. Harlow [MVP - Outlook] <Jay_Harlow@email.msn.com> wrote:
> The other options would be:
> - To change DataRow.Item to be IConvertible instead of Object. Then what
> about the case where DataRow is returning an IStream or an Image or some
> other class where IConvertible does not make sense?
> - To change DataRow to have type safe methods similar to DataReader, which
> then looses the benefits of being an indexer.

Personally I think there should be a third option: another class which
has wrapper methods which call Convert with a cast, with Convert itself
only taking IConvertible. Now that the framework is in its current
state, it would be better to create a class which has methods taking
IConvertible, and make Convert internally call that after the cast.
That way people who *do* want compile-time safety can get it very
easily.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Jay
Wed Jul 30 13:49:07 CDT 2003

Jon,
Which was actually buried in my first suggestion:

> > However the amount of code I
> > need to write, just 'doubled', a wrapper function would be called for. I
> > would probably wrap the entire Convert class. Those wrappers are
currently
> > embedded inside of Convert.ToInt32(Object obj).

Yes having TypeSafeConvert & NonTypeSafeConvert in the Framework may be the
cleanest implementation, but then we get into explaining why there are two
of them. :-)

I'm at least glad you understand what I am babbling about ;-)

I'm sure someone could come up with better names for TypeSafeConvert &
NonTypeSafeConvert ;-)

Jay

"Jon Skeet" <skeet@pobox.com> wrote in message
news:MPG.1991e7566a22dbf998a227@news.microsoft.com...
> Jay B. Harlow [MVP - Outlook] <Jay_Harlow@email.msn.com> wrote:
> > The other options would be:
> > - To change DataRow.Item to be IConvertible instead of Object. Then what
> > about the case where DataRow is returning an IStream or an Image or some
> > other class where IConvertible does not make sense?
> > - To change DataRow to have type safe methods similar to DataReader,
which
> > then looses the benefits of being an indexer.
>
> Personally I think there should be a third option: another class which
> has wrapper methods which call Convert with a cast, with Convert itself
> only taking IConvertible. Now that the framework is in its current
> state, it would be better to create a class which has methods taking
> IConvertible, and make Convert internally call that after the cast.
> That way people who *do* want compile-time safety can get it very
> easily.
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet/
> If replying to the group, please do not mail me too