[c#] namespace objecten uitbreiden (hoe ?)

[shades]

Is het in c# mogelijk om bv system.string of de stringbuilder te voorzien van nieuwe methodes of properties ? Ik heb al flink zitten zoeken in de msdn maar weet niet goed waarnaar.

Ik zou bijvoorbeeld de Left(len) willen implementeren. Het kan wel gewoon met substring maar als de string korter is dan de opgegeven lengte dan krijg je een error. Dit kan je wel weer afvangen maar mooier is om gewoon dit door Left() te laten doen

Het gaat hier dus niet om of het wel of niet handig is om het Left() toe te voegen maar hoe het moet (en of het kan)

Voorbeeldje

C#:

string str = "12345";
str = str.Left(10); // str = "12345"

[gorgi_19]

Als de classes niet sealed zijn, kan je custom classes maken, welke de stringbuilder / string inheriten.

[TlighT]

Maar String is sealed, dus dat zal niet gaan. Gebruikelijk is om een helper klasse te maken met static methods en een private constructor, StringUtil oid.

[shades]

Okay, string.Left() zal dus niet gaan maar stringutl.Left dus wel

zoiets dus : neem ik aan

C#:

public class stringutl : string
{
    public static string left(int Length)
    {
    }
}

string str = "12345";
str = stringutl.left(10);

[whoami]

Als de classes sealed zijn, kan je een nieuwe class maken die dus niet inherit van String/StringBuilder (want dat gaat niet), maar een String of StringBuilder hebben

[shades]

whoami schreef op 10 september 2004 @ 08:56:
Als de classes sealed zijn, kan je een nieuwe class maken die dus niet inherit van String/StringBuilder (want dat gaat niet), maar een String of StringBuilder hebben

eum

C#:

public class StringUtl
{
    public static string Left(string strString, int intLength)
    {
        try
        {
            strString = strString.Substring(intLength) ;
        }
        catch {}
        return strString;
    }
}

[gorgi_19]

Zo voorzie je de class niet van nieuwe methods, maar maak je een helper class. Iets anders dan je eerst had, maar afaik de enige mogelijkheid.

Sowieso, als ik me goed herinner gaat deze methodiek die je nu hanteert trouwens op z'n muil als je

C#:

StringUtl.Left("MyString",20) 

gebruikt.

[ Voor 19% gewijzigd door gorgi_19 op 10-09-2004 09:15 ]

[Woy]

Volgens mij gaat die altijd op z'n muil aangezien je aan strString niks mag assignen aangezien het geen "ref" of "out" parameter is. Je zult eerst even een eigen reference moeten declareren.

En als je een hoger getal meegeeft als de length gaat het idd nog meer fout.

[LoekD]

rwb schreef op 10 september 2004 @ 09:32:
Volgens mij gaat die altijd op z'n muil aangezien je aan strString niks mag assignen aangezien het geen "ref" of "out" parameter is. Je zult eerst even een eigen reference moeten declareren.

En als je een hoger getal meegeeft als de length gaat het idd nog meer fout.

Da's natuurlijk zo'n vergissing..
(je mag best een parameter wijzigen in je method)

edit:

Bovendien is een string een value-type.. geen reference.

[ Voor 13% gewijzigd door LoekD op 10-09-2004 10:58 ]

[whoami]

Hij returned toch de gewijzigde string? Ik zie er geen probleem in.
Wat ik wel vindt is dit :

code:

try
{
   // do something
}
catch{}

return ...

Struisvogeltactiek...

[gorgi_19]

whoami schreef op 10 september 2004 @ 10:59:

Hij returned toch de gewijzigde string? Ik zie er geen probleem in.
Wat ik wel vindt is dit :

code:

try
{
   // do something
}
catch{}

return ...

Struisvogeltactiek...

Sowieso is toch het enige wat fout kan gaan de lengte

[whoami]

Als de doorgegeven string null is zal het ook wel foutlopen.

[Woy]

LoekD schreef op 10 september 2004 @ 10:57:
[...]


Da's natuurlijk zo'n vergissing..
(je mag best een parameter wijzigen in je method)

edit:

Bovendien is een string een value-type.. geen reference.

Ok je hebt gelijk, ik dacht dat de compiler dat niet toe zou laten.

Zelf zou ik ieder geval nooit mijn parameter wijzigen maar gewoon een extra variabele declareren.

Als de doorgegeven string null is zal het ook wel foutlopen.

Valt wel mee toch, dan zal hij waarschijnlijk gewoon null returnen, en dat vindt ik nog niet eens zo gek.

[whoami]

Nope, hij zal een NullValueException geven op lijn 7.

[shades]

Lijkt mij dat het volgende gebeurt: Ik wil van "12345" de linker 20 karakters.
Met de try wordt die aangepast maar de try lukt niet omdat er een fout optreed. Dan de catch.. die doet niets.

De functie geeft dus (indien "12345",20) gewoon "12345" terug. Ik zie niet wat hier fout aan is. Wanneer de try wel goed gaat wordt de string aangepast en gereturnd.. precies wat er moet gebeuren. Misschien dat ik nog rekening moet houden met het feit dat substring zero-based...

[gorgi_19]

shades schreef op 10 september 2004 @ 14:08:
Lijkt mij dat het volgende gebeurt: Ik wil van "12345" de linker 20 karakters.
Met de try wordt die aangepast maar de try lukt niet omdat er een fout optreed. Dan de catch.. die doet niets.

De functie geeft dus (indien "12345",20) gewoon "12345" terug. Ik zie niet wat hier fout aan is. Wanneer de try wel goed gaat wordt de string aangepast en gereturnd.. precies wat er moet gebeuren. Misschien dat ik nog rekening moet houden met het feit dat substring zero-based...

Vang dan netjes die fout af. try-catch-statements zijn niet bedoeld voor normale zaken die je verwacht als vervanging voor een if-statement.

[shades]

gorgi_19 schreef op 10 september 2004 @ 14:09:
[...]

Vang dan netjes die fout af. try-catch-statements zijn niet bedoeld voor normale zaken die je verwacht als vervanging voor een if-statement.

_{Ik had misschien zowel binnen de try als de catch "return strString;" moeten opnemen voor de duidelijkheid maar in praktijk werkt het ook zo.}

Okay maar het is wel een stuk korter... of ben je (ik dus in dit geval) een prutser

[Woy]

Nope, hij zal een NullValueException geven op lijn 7.

als ik bijvoorbeeld de volgende methode hebt

C#:

private string Test( string test )
{
    return test;
}

en die aanroep met

C#:

Console.Write( Test( null ) );

Dan gaat dat gewoon goed.

of bedoel je op deze regel

C#:

strString = strString.Substring(intLength) ;

Daar zal dan wel een NullReferenceException komen maar die wordt door het catch blok opgevangen.

[bramseltje]

Beter dan de try-catch methode:
maak een functie die eerst de lengte controleert.

dus

C++:

public class StringUtil
{
  // iets met members ofzo

  public static /* wrom static? */ String Left(String str, int Len)
  {
    if(Len > str.Length())
    {
       // doe het een...
    }
    else
    {
        // doe het ander...
    }
    return str;
  }
}

Maar da's wel heel veel voorgezegd...

[ Voor 10% gewijzigd door bramseltje op 10-09-2004 16:08 ]

[shades]

Bramseltje schreef op 10 september 2004 @ 16:08:
Beter dan de try-catch methode:
maak een functie die eerst de lengte controleert.

dus
[.. code weggehaald ..]
Maar da's wel heel veel voorgezegd...

Maar dat kon ik zelf ook wel verzinnen het lijkt me niet handig om eerste de class te moeten creeeren voordat Left() aangeroepen kan worden.. Ging me in eerste instantie dus om of string uit te breiden was