Q: Inherit string type, possible?

[Visual Systems AB \(Martin Arvidsson\)]

Hi!

Is it possible to alter the string type?

Basicly what i want to do is to create my own string type. lets call it
sqlString, when i use this
it will always use replace on the string assigned...

Instead of using:

string mystring = "fdfds'fdfd";
mystring.replace("'","''");

i want to do automaticly replace when i assign the value to the sqlString
type.

Hmm, hope you get what i want to do...

Regards
Martin

 

[Daniel O'Connell [C# MVP]]

Hi!

Is it possible to alter the string type?

No.

Basicly what i want to do is to create my own string type. lets call it
sqlString, when i use this
it will always use replace on the string assigned...

Instead of using:

string mystring = "fdfds'fdfd";
mystring.replace("'","''");

i want to do automaticly replace when i assign the value to the sqlString
type.

You would be better off just creating a seperate type that takes a string
via a constructor and does the work and then spits the string out by
overloading ToString(). You could use implicit conversion operators to make
it look closer to waht yo uwant, but you can't change string itself to do
so.

Better yet, just write a utility method that does the work so you can write

string mystring = FormatSqlString("fdfds'fdfd");

and be done with it.

 

[The Crow]

you would be better if you use parameterized commands. (whether you call
stored procedures or dynamic sql.). it does this replacements and much more
for you. (it prevents sql injection automatically.) and code maintanance
will be much easer.

 

[Michael S]

Hi Martin.
In C# 3.0 you will be able to extend the string class.
However, I would use SqlParameter as The Crow suggests.

Happy Selecting
- Michael S

 

[Jon Skeet [C# MVP]]

In C# 3.0 you will be able to extend the string class.

Just to be clear on this, C# 3.0 won't *really* let you extend the
string class. You won't be able to add extra member variables, override
methods etc. What it *will* do is give you some syntactic sugar to call
your own static methods. So:

string x = "x";
x.Foo("wibble");

will be compiled into:

string x = "x";
MyClass.Foo(x, "wibble");

Personally I hope that the syntax changes to make it clearer what's
going on. Something like:

x..Foo("wibble");

I also hope that the way extension methods are "imported" changes to
give much more control (and make things more explicit). I'd be
surprised if that bit doesn't change, to be honest.

However, I would use SqlParameter as The Crow suggests.

Agreed.

Jon

 

[Michael S]

Just to be clear on this, C# 3.0 won't *really* let you extend the
string class.

Aaight. And I think the way they did this with the 'this' keyword on a
static method was nicely done.
Also, I didn't miss the warning in the specs that said - Don't overuse this
feature you fool....

- Michael S

 

[Michael S]

Using Reflection and CodeDOM I'll write a class that Extends all classes in
the .NET framework with a .Please() and a .OrElse() method that does
nothing. This will allow for nifty coding like.

myCommand.ExecuteNonQuery();
myCommand.Please();

myConnection.Close();
myConnection.OrElse();

I often feel like I need to inspire or threaten my objects. Now I can do
that! =)

Happy Extending
- Michael S

 

[Daniel O'Connell [C# MVP]]

Personally I hope that the syntax changes to make it clearer what's

going on. Something like:

x..Foo("wibble");

I wonder if x:Foo("wibble") or x::Foo("wilbble") could be used here without
any syntactic or semantic trouble

 

[Michael S]

I wonder if x:Foo("wibble") or x::Foo("wilbble") could be used here
without any syntactic or semantic trouble

Yuk, that would make it look like C++. =)

Happy Coding
- Michael S

 

[Jon Skeet [C# MVP]]

I wonder if x:Foo("wibble") or x::Foo("wilbble") could be used here without
any syntactic or semantic trouble

x::Foo("wibble") would suggest a namespace of "x" to me (given the
global::Stuff of 2.0). Other than that it would probably be okay.
x:Foo("wibble") could have difficulties with the ternary operator. How
would you parse:

string y = z==null ? x:Foo("wibble"):"wibble";

(Whitespace could be anywhere in that.)

It's certainly worth trying to think up some more options though. Nick
suggested -> to me at the summit, but that's already used for pointers
in C#.

I suspect that this part of the language spec will stick as it was
(using just ".") but that the way of importing it will change.

I must get round to blogging about the "Evil" class some time...

 

[Daniel O'Connell [C# MVP]]

x::Foo("wibble") would suggest a namespace of "x" to me (given the
global::Stuff of 2.0). Other than that it would probably be okay.
x:Foo("wibble") could have difficulties with the ternary operator. How
would you parse:

Forgot about the ternery operator. I so rarely use it. Anyway, I don't know
if :: would cause that much trouble considering how rarely namespacing is
used within C#(although there is the whole C++ issue).

string y = z==null ? x:Foo("wibble"):"wibble";

(Whitespace could be anywhere in that.)

It's certainly worth trying to think up some more options though. Nick
suggested -> to me at the summit, but that's already used for pointers
in C#.

There has to be something, I agree. I considered -> as well but came to the
same conclusion, and => is used in lambda expressions. I don't really like
the double dots since I do that all to often just due to attention dropping.

I suspect that this part of the language spec will stick as it was
(using just ".") but that the way of importing it will change.

Most likely, its still worth some brain time though.

 

[Guest]

The right choice for you is to add your dynamic values as Parameter objects
to the command's parameters collection.

The main advantage of using parameters over concatenation is that if the
sqlString is provided a string like "select * from table1;insert" (Just an
example...there could be another insert operation after the semi-colon, while
you may have made provision only for a DataReader!), the DB Engine will
attempt to parse it, wasting its time, and you will get to know of it only at
run-time.

Regards,

Jv