• JayC (unregistered) in reply to hoodaticus
    hoodaticus:
    JayC:
    Yeah...I know this is late... but... I still don't by the argument that Static Classes Are Evil. I found this code snippet of mine, and the only thing I can figure out wrong about it may be the exception *might* be too generic. And I didn't make it an extension method, either, because the XPathNavigator (and frankly all XML related objects in .NET) have way to many functions for me to keep track of and it'd get lost in the mess. If a function doesn't change anything's state, why not make it static and put it in a static class?
            public static string SafeSelectSingleNodeValue(XPathNavigator f, string XPath, string DefaultSValue)
            {
                try
                {
                    return f.SelectSingleNode(XPath).Value;
                }
                catch (Exception)
                {
                    return DefaultSValue;
                }
            }
    
    
    Is this the best you people can do? Nagesh had the right idea. Cross-cut concerns perhaps belong in statics. This, however, is not a cross-cut concern. It's a fucking method of XPathNavigator. Gee, how would I add a method to a class I don't own?

    Perhaps I could FUCKING INHERIT.

    You are the precise example of what I'm talking about when I say juniors should be banned from making static classes until they learn OOP.

    Have you ever heard that Composition of is much more favorable than Inheritance as a design pattern? Inheritance is to be avoided in many instances where composition would do.

    Why the hell would I inherit? That's the dumbest solution imaginable. This solution applies to * ANY XPathNavigator AND Anything That Inherits From It*. It is incredibly simple and it doesn't change anythings state. An inheriting solution, for this particular instance, by definition, sucks, as all the selection XPathNavigator methods don't return MyBSXPathNavigators, it returns XPathNavigators.

    Tell me, seriously, why would I inherit.

    And you're cursing me, that's completely uncalled for.

  • (cs) in reply to JayC
    JayC:
    And you're cursing me, that's completely uncalled for.
    Fuck you.
  • JayC (unregistered) in reply to hoodaticus
    hoodaticus:
    JayC:
    And you're cursing me, that's completely uncalled for.
    Fuck you.

    Geez, talk about a bad mood!

  • (cs) in reply to JayC
    JayC:
    hoodaticus:
    JayC:
    Yeah...I know this is late... but... I still don't by the argument that Static Classes Are Evil. I found this code snippet of mine, and the only thing I can figure out wrong about it may be the exception *might* be too generic. And I didn't make it an extension method, either, because the XPathNavigator (and frankly all XML related objects in .NET) have way to many functions for me to keep track of and it'd get lost in the mess. If a function doesn't change anything's state, why not make it static and put it in a static class?
            public static string SafeSelectSingleNodeValue(XPathNavigator f, string XPath, string DefaultSValue)
            {
                try
                {
                    return f.SelectSingleNode(XPath).Value;
                }
                catch (Exception)
                {
                    return DefaultSValue;
                }
            }
    
    
    Is this the best you people can do? Nagesh had the right idea. Cross-cut concerns perhaps belong in statics. This, however, is not a cross-cut concern. It's a fucking method of XPathNavigator. Gee, how would I add a method to a class I don't own?

    Perhaps I could FUCKING INHERIT.

    You are the precise example of what I'm talking about when I say juniors should be banned from making static classes until they learn OOP.

    Have you ever heard that Composition of is much more favorable than Inheritance as a design pattern? Inheritance is to be avoided in many instances where composition would do.

    Why the hell would I inherit? That's the dumbest solution imaginable. This solution applies to * ANY XPathNavigator AND Anything That Inherits From It*. It is incredibly simple and it doesn't change anythings state. An inheriting solution, for this particular instance, by definition, sucks, as all the selection XPathNavigator methods don't return MyBSXPathNavigators, it returns XPathNavigators.

    Tell me, seriously, why would I inherit.

    And you're cursing me, that's completely uncalled for.

    This is exactly the problem with OOP. Inheritance is often an anti-pattern (because it binds unrelated constructs too tightly), and without inheritance, plain OOP is just a procedural paradigm with a weird algebra bolted on. You end up using the language of classes to perform structuring and typing, instead of having an assortment of structuring and typing constructs. In other words, OO programmers end up injecting typing and structuring constructs into a "looser" language, meaning that the programmer is responsible for maintaining the typing and structuring invariants.

    This is why Microsoft and Oracle are slowly adding strong typing and functional programming features to their flagship languages. It is obvious that the creation of ad hoc types facilitates expressivity and correctness. Results regarding the computational feasibility of ad hoc typing have been known to computer science and mathematics since the 1930s. Unfortunately, the procedure-focused electrical engineers that dominated CS in the 1950s - 1990s have poisoned millions of minds. Admittedly, there was good reason for CS to be EE-centric for all those years -- designing complex electronics is obviously the domain of electronics engineering. On the other hand, to use the misattributed Djikstra quote, “Computer science is no more about computers than astronomy is about telescopes.”

  • Reow (unregistered)

    Let me guess... one of your KPIs is LoC?

  • gabs (unregistered)

    mother of pointers ಠ_ಠ

  • Dennistyday (unregistered)
    Comment held for moderation.
  • Alfredtor (unregistered)
    Comment held for moderation.

Leave a comment on “The Global Workaround”

Log In or post as a guest

Replying to comment #362274:

« Return to Article