[LONG] C# too sharp for me

[arthur.mcginty]

Man I've grown tired with C#/.NET the last three days I spent trying to
put a NULL value in a database. C# initializes all uninitialized
properties to 0 (for numeric types) and didn't have until C# 2 any
concept of NULLs. I keep wondering how you guys built all these .NET
apps on the top of a database. And guess what? If you fail to
initialize a DateTime (maybe because you just don't want to touch it!)
you get it infact initialized to {01/01/0001 0.00.00} but of course
when you try to put it in a SQLServer db you get this error in return:

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and
12/31/9999 11:59:59 PM

Now in C# 2 you have the option to choose to declare something as a
Nullable... but it's just a hack (even if builtin the language) and
using Nullables prevents you from doing all sort of things, and strings
cannot be declared as Nullable but at least they are initialized
correctly if you don't touch them!

I understood just yesterday what's all the buzz around dynamic
languages since, even being a Python amateur, I still didn't get it
fully: I wanted to pass a property like Foo.Number as a parameter to a
method and I would have to use a delegate or an anonymous method
(another new feature... and, yeah, you cannot pass a property by ref
http://msdn2.microsoft.com/en-us/library/w86s7x04) which they tell you
that you can use it everywhere you would use a delegate but no, not
there, not where you need it the most or maybe with odd consequences.
Quoting from Jesse Liberty "Visual C# 2005 a Developer's Notebook"
published by O'Reilly:

<quote>
....what happens if I reference local variables in my anonymous block?
Good question. This can cause quite a bit of confusion and is a natural
trap to fall into, especially if you don't fully understand the
consequences.
C# allows local variables to be captured in the scope of the
anonymous code block, and then they are accessed when the code block
is executed. This can create some odd side effects, such as keeping
objects around after they might otherwise have been collected.
</quote>

Ok properties are not fields/variables but pardon me if I was looking
to implement yet another workaround to my problem.

And you now what: how about not knowing the type of a property you pass
to this function, well, you gotta use a generic (another new feature of
C#2)... and all this for doing somethinig that in Python and Ruby is
not even a problem... ah and did I tell you the best thing? ADO.NET
which is your only chance to talk to a database in the .NET managed
world doesn't support Nullable types: I found maybe by chance or
because, after all, god still loves me, a workaround since as Microsoft
confirmed there are no solutions, only workarounds if you want to pass
a NULL value to a SqlParameter. BTW I thought that using SqlClient you
would just bypass ADO.NET and talk directly to SqlServer if you didn't
mind tying you hands and foots to SqlServer. A guy had to write
Nullable types himself to use NULL values in C# v. 1
(http://nullabletypes.sourceforge.net/)

The only kinda dynamic feature of C# is Reflection which is another
way to say introspection which is one of those features I thought I
would never need even to learn in the C# "we give you everything out
of-the-box world" but actually comes handy in many places due to the
_limitations_ of the .NET platform.

Well, I'm done... this morning I bought a copy of Programming Ruby!

Arthur

[jeremiah johnson]

Not to be too harsh, but bye.

You should give Perl a shot. Its the fastest most wonderful language
for small little utility programs. It is a non-typed, procedural
easy-to-read, easy-to-write (if you know what you're doing) language.

give it a try. 'null' means something there.

http://www.activestate.com/

ar************@ gmail.com wrote:

Man I've grown tired with C#/.NET the last three days I spent trying to
put a NULL value in a database. C# initializes all uninitialized
properties to 0 (for numeric types) and didn't have until C# 2 any
concept of NULLs. I keep wondering how you guys built all these .NET
apps on the top of a database. And guess what? If you fail to
initialize a DateTime (maybe because you just don't want to touch it!)
you get it infact initialized to {01/01/0001 0.00.00} but of course
when you try to put it in a SQLServer db you get this error in return:

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and
12/31/9999 11:59:59 PM

Now in C# 2 you have the option to choose to declare something as a
Nullable... but it's just a hack (even if builtin the language) and
using Nullables prevents you from doing all sort of things, and strings
cannot be declared as Nullable but at least they are initialized
correctly if you don't touch them!

I understood just yesterday what's all the buzz around dynamic
languages since, even being a Python amateur, I still didn't get it
fully: I wanted to pass a property like Foo.Number as a parameter to a
method and I would have to use a delegate or an anonymous method
(another new feature... and, yeah, you cannot pass a property by ref
http://msdn2.microsoft.com/en-us/library/w86s7x04) which they tell you
that you can use it everywhere you would use a delegate but no, not
there, not where you need it the most or maybe with odd consequences.
Quoting from Jesse Liberty "Visual C# 2005 a Developer's Notebook"
published by O'Reilly:

<quote>
...what happens if I reference local variables in my anonymous block?
Good question. This can cause quite a bit of confusion and is a natural
trap to fall into, especially if you don't fully understand the
consequences.
C# allows local variables to be captured in the scope of the
anonymous code block, and then they are accessed when the code block
is executed. This can create some odd side effects, such as keeping
objects around after they might otherwise have been collected.
</quote>

Ok properties are not fields/variables but pardon me if I was looking
to implement yet another workaround to my problem.

And you now what: how about not knowing the type of a property you pass
to this function, well, you gotta use a generic (another new feature of
C#2)... and all this for doing somethinig that in Python and Ruby is
not even a problem... ah and did I tell you the best thing? ADO.NET
which is your only chance to talk to a database in the .NET managed
world doesn't support Nullable types: I found maybe by chance or
because, after all, god still loves me, a workaround since as Microsoft
confirmed there are no solutions, only workarounds if you want to pass
a NULL value to a SqlParameter. BTW I thought that using SqlClient you
would just bypass ADO.NET and talk directly to SqlServer if you didn't
mind tying you hands and foots to SqlServer. A guy had to write
Nullable types himself to use NULL values in C# v. 1
(http://nullabletypes.sourceforge.net/)

The only kinda dynamic feature of C# is Reflection which is another
way to say introspection which is one of those features I thought I
would never need even to learn in the C# "we give you everything out
of-the-box world" but actually comes handy in many places due to the
_limitations_ of the .NET platform.

Well, I'm done... this morning I bought a copy of Programming Ruby!

Arthur

[Tasos Vogiatzoglou]

I would like to see those components with transaction support, with
object pooling support and an event mechanism that are built in ruby
and perl

Regards

[david]

On 2005-09-24, ar************@ gmail.com <ar************ @gmail.com> wrote:

Man I've grown tired with C#/.NET the last three days I spent trying to
put a NULL value in a database.
IMHO, spending three days on a fairly simple procedure like that says
much more about you than the language.
C# initializes all uninitialized
properties to 0 (for numeric types) and didn't have until C# 2 any
concept of NULLs.
The existence of value types is essentially a performance vs. ease of
use issue. As with most trade-offs in programming, the choice that was
made is a good choice for some problem domains and not the optimal
choice for other problem domains.

There's nothing wrong with disagreeing with the choices C# made here.
However, the tone of your post implies that you don't understand the
choices, or that you think the language designers didn't understand
them. Most C# programmers, and certainly the language designers, do
understand the choices made and why they were made, understand many
of the benefits and detriments of those choices, and prefer the C#
way of doing things.
I keep wondering how you guys built all these .NET
apps on the top of a database.
You special-case the null type, and encapsulate the special cases..
And guess what? If you fail to
initialize a DateTime (maybe because you just don't want to touch it!)
you get it infact initialized to {01/01/0001 0.00.00} but of course
when you try to put it in a SQLServer db you get this error in return:

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and
12/31/9999 11:59:59 PM
You did something wrong and instead of silently doing the wrong thing
the system loudly proclaimed the error. That's a Good Thing.
Now in C# 2 you have the option to choose to declare something as a
Nullable... but it's just a hack (even if builtin the language) and
using Nullables prevents you from doing all sort of things, and strings
cannot be declared as Nullable but at least they are initialized
correctly if you don't touch them!

I understood just yesterday what's all the buzz around dynamic
languages since, even being a Python amateur, I still didn't get it
fully:
Python is a very nice language.
I wanted to pass a property like Foo.Number as a parameter to a
method and I would have to use a delegate or an anonymous method
(another new feature... and, yeah, you cannot pass a property by ref
http://msdn2.microsoft.com/en-us/library/w86s7x04)
Properties aren't fields, they're syntactic sugar over functions. Most
C# developers understand this. I must admit, I distrust a design that
would want to pass a field by reference. However, once you do understand
that they're functions, it may be that a simple interface would do what
you want.
which they tell you
that you can use it everywhere you would use a delegate but no, not
there, not where you need it the most or maybe with odd consequences.
Quoting from Jesse Liberty "Visual C# 2005 a Developer's Notebook"
published by O'Reilly:

<quote>
...what happens if I reference local variables in my anonymous block?
Good question. This can cause quite a bit of confusion and is a natural
trap to fall into, especially if you don't fully understand the
consequences.
C# allows local variables to be captured in the scope of the
anonymous code block, and then they are accessed when the code block
is executed. This can create some odd side effects, such as keeping
objects around after they might otherwise have been collected.
</quote>
Closures are very, very powerful and very, very complex. That's another
natural trade-off.
Ok properties are not fields/variables but pardon me if I was looking
to implement yet another workaround to my problem.

And you now what: how about not knowing the type of a property you pass
to this function, well, you gotta use a generic (another new feature of
C#2)... and all this for doing somethinig that in Python and Ruby is
not even a problem...
Static vs. dynamic typing is a fascinating subject, and one that is the
subject of much debate. Intelligent forms of the debate run along the
lines of "I find the solution to x more elegant in language y because
of dynamic typing". Less intelligent forms of the debate run along the
lines of "I can't figure out how to do x in a statically-typed language,
I'd prefer to turn off compiler checks".
ah and did I tell you the best thing? ADO.NET
which is your only chance to talk to a database in the .NET managed
world doesn't support Nullable types: I found maybe by chance or
because, after all, god still loves me, a workaround since as Microsoft
confirmed there are no solutions, only workarounds if you want to pass
a NULL value to a SqlParameter. BTW I thought that using SqlClient you
would just bypass ADO.NET and talk directly to SqlServer if you didn't
mind tying you hands and foots to SqlServer. A guy had to write
Nullable types himself to use NULL values in C# v. 1
(http://nullabletypes.sourceforge.net/)

The only kinda dynamic feature of C# is Reflection which is another
way to say introspection which is one of those features I thought I
would never need even to learn in the C# "we give you everything out
of-the-box world" but actually comes handy in many places due to the
_limitations_ of the .NET platform.
This is pretty interesting to me. Personally, the only time I've used
reflection in .Net is when I'm either explicitly doing some kind of
assembly/code analysis (FxCop-type stuff) or when dynamically loading
assemblies at runtime. For ordinary tasks, I could do without it.

OTOH, I do a lot of VB.Net work, and VB programmers are always asking me
about reflection because they've got a design that requires some type
of late binding. These designs aren't *necessarily* worse, but they
don't fit the toolset well, and IMHO the chosen toolset is going to
have to have some sort of effect on the design process.

OK, actually these designs are usually pretty bad. But I think that's
because programmers who can't adapt to new environments tend to be
bad code designers as well.
Well, I'm done... this morning I bought a copy of Programming Ruby!
Ruby is a very nice language as well, and may fit your style a bit
better. However, being able to understand the C# way of doing things
will benefit you even as a Ruby developer, just as understanding the
Ruby way of doing things would benefit C# programmers. Accepting the
mindset of "I just couldn't understand the way language X does things"
is a dangerous mindset if you're truly interested in improving your
development skills.

Arthur

[Zanna]

<ar************ @gmail.com> ha scritto nel messaggio
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

Man I've grown tired with C#/.NET the last three days I spent trying to
put a NULL value in a database. C# initializes all uninitialized
properties to 0 (for numeric types) and didn't have until C# 2 any
concept of NULLs. I keep wondering how you guys built all these .NET
apps on the top of a database. And guess what? If you fail to
initialize a DateTime (maybe because you just don't want to touch it!)
you get it infact initialized to {01/01/0001 0.00.00} but of course
when you try to put it in a SQLServer db you get this error in return:

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and
12/31/9999 11:59:59 PM

Now in C# 2 you have the option to choose to declare something as a
Nullable... but it's just a hack (even if builtin the language) and
using Nullables prevents you from doing all sort of things, and strings
cannot be declared as Nullable but at least they are initialized
correctly if you don't touch them!
To set a DB field to null just assign DBNull.Value to it!
Without any sort of workaround.
For the date, you cannot pretend that the managing of a date in a language
is the same in an arbitrary DB engine!
And it's a bad practice to assign values in a db field without knowing what
you are assigning.
Nullable types are all another sort of things and nothing to do with DB.

The only kinda dynamic feature of C# is Reflection which is another
way to say introspection which is one of those features I thought I
would never need even to learn in the C# "we give you everything out
of-the-box world" but actually comes handy in many places due to the
_limitations_ of the .NET platform.

C# (and .Net in general) is really well structured OOP language.
If you try to force it to do things the way you want to, and not the way
them should be done, you can't pretend to get the goal.
You should think that something is prohibited, most probably it's because it
makes no sense, it is thinked/designed in a wrong way, it can be done in
another way.

Reflection is really usefull if you need to know the structure of a class
(i.e. I used it to serialize classes in a really "zero effords" way, against
the standard .Net serialization that need really much code).
Since I develop in .Net I don't remember a single case in wich I needed to
pass a parameter "by ref", because in OOP it is quite useless and
symptomatic.

Maybe you prefere Phyton or Ruby because their "compilers" do not complaint
about "dog food programming techniques", but all the things the compiler
can't filter are all yours. :)
--
- .Net Reporting tool http://www.neodatatype.net

[arthur.mcginty]

Zanna wrote:

To set a DB field to null just assign DBNull.Value to it!
Without any sort of workaround.

Yeah, rright! Try testing for NULLs when the runtime already assigned a
0 to your uninitialized property. You would probably write something
like:

if(User.Age == 0)
{
Parameter.Value == DBNull.Value;
}

the above code wouldn't make sense to me because Age can't be 0, but
can be null. Therefore you DO need a workaround here which could be
Nullable types or something else. And, worst, this is not a corner
case. As someone pointed out why would you want Nullable types if not
for dealing with databases or anyway cases (there are many in my
experience) where you could legally have a NULL value.

Think at an overload for a User constructor which is tailored for
processing data from a registration form and therefore only asks for
FirstName, LastName, Email and Password when the User table could
include far more details such as Age which you would want to leave NULL
at the time of the user registration but available for him/her to fill
in in his User Profile page. This is a very common scenario. The same
problem you could have with the DateOfBirth field in the db which you
would have to implement a workaround for, for the reason stated in my
first post.

Arthur

[Zanna]

<ar************ @gmail.com> ha scritto nel messaggio
news:11******** *************@g 47g2000cwa.goog legroups.com...

Yeah, rright! Try testing for NULLs when the runtime already assigned a
0 to your uninitialized property. You would probably write something
like:

if(User.Age == 0)
{
Parameter.Value == DBNull.Value;
}

You can't pretend that DB engine and programming languages manage data in
the same way!

If some languages do it it's a collateral effect, not a feature.

The same thing can appear in different scenario, such as the string: many DB
have different type of strings (SQL has text, ntext, char, varchar,
nvarchar...) with different max lengths.
It's sure you have to check the string length when you assign it.

What's wrong with

if(User.Age == 0)
{
Parameter.Value == DBNull.Value;
}

or

Parameter.Value = (User.Age == 0) ? DBNull.Value : User.Age

?

--
..Net Reporting tool: http://www.neodatatype.net

[Paul E Collins]

<ar************ @gmail.com> wrote:

To set a DB field to null just assign DBNull.Value to it!
Without any sort of workaround.

Yeah, rright! Try testing for NULLs when the runtime
already assigned a 0 to your uninitialized property.

Gee, did you ever consider initialising your variables?

P.

[Søren Reinke]

"jeremiah johnson" <na*******@gmai l.com> wrote in message
news:eY******** ******@TK2MSFTN GP09.phx.gbl...

Not to be too harsh, but bye.

You should give Perl a shot. Its the fastest most wonderful language for
small little utility programs. It is a non-typed, procedural
easy-to-read, easy-to-write (if you know what you're doing) language.
Haha that was a good one :)

Never seen any 'easy to read' perl script yet' okay maybe a 'hello world'.

Perl is not and has never been easy to read, and easy to write, hmm that
goes for every language you know.
MC68000 Assembler is very easy to write as well (for me)

give it a try. 'null' means something there.

As it also does in C#.net.

DBNull is the value to send to the DB.

/Søren

[Bill Butler]

"Paul E Collins" <fi************ ******@CL4.org> wrote in message
news:dh******** **@nwrdmz02.dmz .ncs.ea.ibs-infra.bt.com...

<ar************ @gmail.com> wrote:

> To set a DB field to null just assign DBNull.Value to it!
> Without any sort of workaround.

Yeah, rright! Try testing for NULLs when the runtime
already assigned a 0 to your uninitialized property.

Gee, did you ever consider initialising your variables?

Stop for a second and listen to his point, because it is valid.

If AGE is an optional DB field, then you may not have a value to initialize it with.
You can pick some DEFAULT age to stand for the case of no age entered, but that is EXACTLY the age
== 0 thing.

Thus you are left doing the if(age == DEFAULT_AGE) thing.

In some ways there is an impedance mismatch between DB data and dotnet Data

Bill