Well, the point I was going to bring up last night was that one could live very happily within IronPython, following Pythonic customs; but one should be expected to follow the customs that exist in the CLR world when talking with it. Some types I can see free conversions for -- particularly value types. Some types, such as arrays, would be tricker and I suspect impossible in cases: for those I'd desire strong-typing. For stuff that IronPython may expose to the outside world, strong-typing should be a requirement (even if it's declaring the type to be Object), no? C#2 brings on type inference for delegates, so I can see a similar scheme going on. For IronPython I think it'd be closer to a dispatch based on type, which I can see getting very bloaty. I'm not familiar with how Jim addressed this in Jython?
________________________________ From: [EMAIL PROTECTED] on behalf of Richard Monson-Haefel Sent: Wed 4/20/2005 2:22 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions for FAQ or User Guide Well, the way I see it (not that my opinion is all that important, but ...) you should be able to use more explicit typing by declaring the System.Double [] type if you desire, but IronPython should attempt to do the transformation if you choose not to (or neglect) to do so. That way you get both options. Very explicit type conversions or implicit conversions. It becomes a matter of style. The thing to remember, IMO, is that IronPython is a dynamic language and by nature dynamic language are loosely typed. If you require explicit typing, than you are breaking that model, in which case you might as well not use IronPython at all.
<<winmail.dat>>
_______________________________________________ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
