• TheBaker (unregistered)

    At least he was being polite.

  • (cs)

    This is not that uncommon with the code I see daily (not my design).  That is that many people don't seem to understand the where classes or structures should be static or not.  Frequently I see people create a class that has no member value storage but maybe a single public method that acts autonomously and could/should be a static method of the class.

    Maybe it was the way it was taught to me, but OO design didn't seem that hard.  I know people who graduated in my class that didn't know the difference between a class an object and a program.  That frightens me.

  • Willie (unregistered)

    Maybe he was used to programming in INTERCAL and thought his program wasn't polite enough.

  • (cs)

    Think putting in a "<font size="2">Public PleaseGiveMeOneMillionDollars As Boolean</font>" statement will work, too? I mean, if the compiler is taking requests...

  • (cs)

    So they basically just made a bunch of global variables that are accessible by prefacing them with "UserInformation.".

    I wonder what the difference between intUserID and strUserID is suppose to be?

  • (cs)

    The real WTF here is the phrase "VB-deprived".

  • (cs) in reply to LuciferSam
    LuciferSam:

    Maybe it was the way it was taught to me, but OO design didn't seem that hard.  I know people who graduated in my class that didn't know the difference between a class an object and a program.  That frightens me.



    According to OO design everything is an object, including program and classes (often called meta objects). Maybe it was you who didn't get it...
  • Anonymous (unregistered) in reply to limelight
    limelight:

    I wonder what the difference between intUserID and strUserID is suppose to be?

    One is a integer and the other is a string.

  • (cs)

    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?

  • fdr (unregistered) in reply to Willie

    Isn't CLWNPA the only right way to call it?

  • (cs) in reply to wintermyute

    Interesting. It's silly (possibly dangerous) to do this, but I see no reason the compiler should reject it. In fact, the C# compiler has no problem with it.

  • (cs)
    Alex Papadimoulis:
      'Don't know why we need this, but won't compile without it
  Public PleaseCompile As Boolean


    So all I have to do is set PleaseCompile = true and all of my programs will compile no matter how many syntax errors are in the code?
  • Your Name (unregistered) in reply to fdr
    Anonymous:
    Isn't CLWNPA the only right way to call it?


    A singleton class.
  • (cs) in reply to ammoQ
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?

    If you don't care about thread safety, this works (assuming you can compile it). Instead of using a dummy member, an explicit default ctor is more intuitive.

    A better solution would be a singleton.
  • Your Name (unregistered) in reply to Your Name

    Oops, meant to quote this post: " Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?"

  • mkb (unregistered) in reply to ammoQ
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?


    In addition to static class members, you could have namespaced globals, or defined constants.
  • (cs) in reply to Anonymous
    Anonymous:
    limelight:

    I wonder what the difference between intUserID and strUserID is suppose to be?

    One is a integer and the other is a string.

    Other than the obvious. What I mean is that they both have the same description, "UserID". This implies that they both contain the same data, only one as a string and one as an integer. Perhaps intUserID is suppose to be the primary key from the database, while strUserID is suppose to be the user's ID, but this is not obvious from the code.

  • (cs) in reply to mkb
    Anonymous:
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?


    In addition to static class members, you could have namespaced globals, or defined constants.

    .Net does not allow variables or constants in a namespace (not within an enclosing class). And I for one am thankful for that.
  • (cs) in reply to limelight
    limelight:

    I wonder what the difference between intUserID and strUserID is suppose to be?

    Isn't it obvious? intUserID holds the row count.

     

  • Bonds - steroids = me (unregistered) in reply to pjsson
    pjsson:

    According to OO design everything is an object, including program and classes (often called meta objects). Maybe it was you who didn't get it...


    I am not sure what you mean by this, but an object is the instantiation of the class. You can think of everything at runtime as an object (though technically not correct, it won't really harm you much), but the class really is different.


  • (cs) in reply to ammoQ

    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?

    Use a class instead of a struct.

  • TDog (unregistered)

    putting aside the obvious...

    When the Public structure is instanced within the application, wouldn't the static variables be created within that instance and therefore work as the programmer probably expected? 

  • (cs)

    Good thing they didn't try to list all the things they don't know. 

  • (cs) in reply to Bonds - steroids = me
    Anonymous:
    pjsson:

    According to OO design everything is an object, including program and classes (often called meta objects). Maybe it was you who didn't get it...


    I am not sure what you mean by this, but an object is the instantiation of the class. You can think of everything at runtime as an object (though technically not correct, it won't really harm you much), but the class really is different.


    Nope, a class is an object too, a metaobject to a regular object, an object that is a pattern of an object, an object factory if you want.

    And that's why people invented metaclasses, which are in fact the classes of classes (and you can instantiate a class from a metaclass, and then instantiate a regular object from the class instanciated from the metaclass).

    What pjsson tells you is that in OO design everything is an object, there is no "but" and no "except", it's everything period.

    Now we do understand that Java does not have a clue, and doesn't understand that a class is an object, or a method is an object, etc (this is actually false BTW, you can manipulate java classes and methods as first class objects through java.lang.Class and java.lang.reflect.Method, but it's kind of awkward and I don't think java has metaclasses), but try to check languages such as Smalltalk, Python or Ruby and you'll see all kinds of wonders such as functions and methods being first-class object (e.g you can define one, pass it around, send it another method/function's argument, return one from a function, ...), classes being first-class objects as well, metaclasses (still first-class objects), ...

    A class is not "different", it's an object and an object factory, that's all there is to it.

  • (cs) in reply to pjsson
    pjsson:
    LuciferSam:

    Maybe it was the way it was taught to me, but OO design didn't seem that hard.  I know people who graduated in my class that didn't know the difference between a class an object and a program.  That frightens me.



    According to OO design everything is an object, including program and classes (often called meta objects). Maybe it was you who didn't get it...

    A class is but a blueprint.  An object is the instantiation of a class.  If you think there is no difference between classes and objects, it really doesn't matter since most development these days don't care about terminology.  According to OO design, everything is an object.  However, classes and structs are blueprints on the object's internals.

  • (cs)

    <font size="2">"Don't know why, but..."-type comments are great.  They say, "Hey, there's some kind of problem here, but at least I got it working.  Good luck fixing it the right way after I've been fired/downsized/promoted to management!"

    </font>

  • Nello? (unregistered) in reply to tmountjr

    Not if it's set to false!

  • (cs) in reply to ammoQ
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?


    You would define your structure with public members, but in your app you would create a static variable *instance* of that structure.

    Basically, this guy got confused on the difference between a class and an object.

  • (cs) in reply to Jeff S

    Oh, almost forgot:  a great WTF !   Maybe this same compiler error was the same reason paula bean had to declare herself as "Brillant" ?

  • (cs) in reply to cconroy

    cconroy:
    <FONT size=2>"Don't know why, but..."-type comments are great.  They say, "Hey, there's some kind of problem here, but at least I got it working.  Good luck fixing it the right way after I've been fired/downsized/promoted to management!"

    </FONT>

    These may be tired to some of you guys, but here are some nice examples of "hack/I don't know/don't ask me" comments:

    Joel on Software/fog creek comments

    We Are Morons: a quick look at the Win2K source

  • (cs) in reply to John Smallberries
    John Smallberries:
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?

    If you don't care about thread safety, this works (assuming you can compile it). Instead of using a dummy member, an explicit default ctor is more intuitive.

    A better solution would be a singleton.


    Maybe I'm missing something...  What's so great about a Singleton in this case?


    Forgive me for using Java, but I'm fortunate enough to be VB-deprived (and that may well be why I'm missing something):

    //non-singleton version
    public final class SharedVariables {
      public static int val1;
      public static int val2;
     
      //hide constructor to prevent instantiation
      private SharedVariables() {}
    }


    //singleton version
    public final class SharedVariables {
      private static SharedVariables instance;
      public static int val1;
      public static int val2;
     
      //hide constructor to prevent instantiation
      private SharedVariables() {}
     
      public SharedVariables getInstance() {
        if (instance == null)
          instance = new SharedVariables();
        return instance;
      }
    }


    The only advantage I see is that with the singleton you could save a little typing by getting an instance and giving it a shorter variable name:

    SharedVariables.val1=??;
    SharedVariables.val2=??;
    SharedVariables.val3=??;
    SharedVariables.val4=??;

     vs.

    SharedVariables sv = SharedVariables.getInstance();
    sv.val1=??;
    sv.val2=??;
    sv.val3=??;
    sv.val4=??;

  • (cs) in reply to kipthegreat
    kipthegreat:
    John Smallberries:
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?

    If you don't care about thread safety, this works (assuming you can compile it). Instead of using a dummy member, an explicit default ctor is more intuitive.

    A better solution would be a singleton.


    Maybe I'm missing something...  What's so great about a Singleton in this case?


    I made the assumption that in the implementation of the singleton you would handle thread synchronization, have accessors around private members, and all that good OO stuff. Since there will actually be an instance, static members lose there relevance.

    That's what I meant by "better".
  • (cs) in reply to Anonymous
    Anonymous:
    limelight:

    I wonder what the difference between intUserID and strUserID is suppose to be?

    One is a integer and the other is a string.

    Mr. Anonymous, if you were serious then you're an idiot. If you were kidding, then you're an idiot with no sense of humor.

    Back to the code...with such a coding genius at the helm, I have no doubt saying that the user ID is stored as an int and a string so that you only have to put

        strUserID = CStr(intUserID)

    once in the code. After that, just access the string member rather than re-doing the processor-intesive operation CStr( ).

    Painful. Just painful.

  • (cs) in reply to kipthegreat
    kipthegreat:
    John Smallberries:
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?

    If you don't care about thread safety, this works (assuming you can compile it). Instead of using a dummy member, an explicit default ctor is more intuitive.

    A better solution would be a singleton.


    Maybe I'm missing something...  What's so great about a Singleton in this case?


    Forgive me for using Java, but I'm fortunate enough to be VB-deprived (and that may well be why I'm missing something):

    //non-singleton version
    public final class SharedVariables {
      public static int val1;
      public static int val2;
     
      //hide constructor to prevent instantiation
      private SharedVariables() {}
    }


    //singleton version
    public final class SharedVariables {
      private static SharedVariables instance;
      public static int val1;
      public static int val2;
     
      //hide constructor to prevent instantiation
      private SharedVariables() {}
     
      public SharedVariables getInstance() {


    I would add "synchronized" to make it thread safe. (I'm sure you know that, but someone might read and copy that example...)




    The only advantage I see is that with the singleton you could save a little typing by getting an instance and giving it a shorter variable name:


    Technically, you might as well call the class "sv", so this advantage is just a matter of convention.
  • (cs) in reply to Jeff S
    Jeff S:
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?


    You would define your structure with public members, but in your app you would create a static variable *instance* of that structure.


    The problem is that there is no global scope. Adding a level of indirection just moves the problem around; each class in your app needs a reference to the struct, and you still have no thread safety.
  • (cs) in reply to A Wizard A True Star
    A Wizard A True Star:
    limelight:

    I wonder what the difference between intUserID and strUserID is suppose to be?

    Isn't it obvious? intUserID holds the row count.

     

    Quoted for truthery.

  • (cs) in reply to John Smallberries

    John Smallberries:
    kipthegreat:
    John Smallberries:
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?

    If you don't care about thread safety, this works (assuming you can compile it). Instead of using a dummy member, an explicit default ctor is more intuitive.

    A better solution would be a singleton.


    Maybe I'm missing something...  What's so great about a Singleton in this case?


    I made the assumption that in the implementation of the singleton you would handle thread synchronization, have accessors around private members, and all that good OO stuff. Since there will actually be an instance, static members lose there relevance.

    That's what I meant by "better".

    Everyone always seems to forget the other benefit of a singleton versues static members -- polymorphism.

  • (cs) in reply to JohnO
    JohnO:

    Everyone always seems to forget the other benefit of a singleton versues static members -- polymorphism.


    Absolutely. Great point. I didn't forget it (and was kinda hinting at it by stating that there would be an actual instance).

    In a discussion where people are a little shaky on the whole "object vs. class" thing, polymorphism seems a little advanced...
  • maht (unregistered)

    trwtf here is that it should have been

    Public TheJuice As Boolean


  • Bonds - steroids = me (unregistered) in reply to masklinn
    masklinn:

    Nope, a class is an object too, a metaobject to a regular object, an object that is a pattern of an object, an object factory if you want.

    And that's why people invented metaclasses, which are in fact the classes of classes (and you can instantiate a class from a metaclass, and then instantiate a regular object from the class instanciated from the metaclass).

    You are confusing your terminology, which is understandable. You do not instantiate an object, an object is an instantiation (of a class). This is OO 101.

    masklinn:

    What pjsson tells you is that in OO design everything is an object, there is no "but" and no "except", it's everything period.

    Now we do understand that Java does not have a clue, and doesn't understand that a class is an object, or a method is an object, etc (this is actually false BTW, you can manipulate java classes and methods as first class objects through java.lang.Class and java.lang.reflect.Method, but it's kind of awkward and I don't think java has metaclasses), but try to check languages such as Smalltalk, Python or Ruby and you'll see all kinds of wonders such as functions and methods being first-class object (e.g you can define one, pass it around, send it another method/function's argument, return one from a function, ...), classes being first-class objects as well, metaclasses (still first-class objects), ...

    A class is not "different", it's an object and an object factory, that's all there is to it.



    Being quite adept a python and ruby, I know exactly what you are talking about, but the fact remains, an object is an instantiation of a class. Think concrete implementation. They are different, but if you have to think of them as the same it won't hurt you at all.
  • (cs) in reply to John Smallberries

    Wow! this has got to be the best one since the for-switch. [H]

    I really have to wonder if the guy really intended global variables for the "shared" fields. [*-)]

  • (cs) in reply to A Wizard A True Star
    A Wizard A True Star:
    limelight:

    I wonder what the difference between intUserID and strUserID is suppose to be?

    Isn't it obvious? intUserID holds the row count.

     

     

    sweet they must be friends and have copied the code!!

  • Anonymous Coward (unregistered) in reply to pjsson
    pjsson:
    LuciferSam:

    Maybe it was the way it was taught to me, but OO design didn't seem that hard.  I know people who graduated in my class that didn't know the difference between a class an object and a program.  That frightens me.



    According to OO design everything is an object, including program and classes (often called meta objects). Maybe it was you who didn't get it...


    Just because X is a Y does not mean that there is no difference between X and Y.


  • I forgot... (unregistered) in reply to kipthegreat
    kipthegreat:
    John Smallberries:
    ammoQ:
    Assuming they really just wanted a bunch of global variables "somehow" tied together, what would be the correct way to do ist?

    If you don't care about thread safety, this works (assuming you can compile it). Instead of using a dummy member, an explicit default ctor is more intuitive.

    A better solution would be a singleton.


    Maybe I'm missing something...  What's so great about a Singleton in this case?


    Forgive me for using Java, but I'm fortunate enough to be VB-deprived (and that may well be why I'm missing something):

    //non-singleton version
    public final class SharedVariables {
      public static int val1;
      public static int val2;
     
      //hide constructor to prevent instantiation
      private SharedVariables() {}
    }


    //singleton version
    public final class SharedVariables {
      private static SharedVariables instance;
      public static int val1;
      public static int val2;
     
      //hide constructor to prevent instantiation
      private SharedVariables() {}
     
      public SharedVariables getInstance() {
        if (instance == null)
          instance = new SharedVariables();
        return instance;
      }
    }


    The only advantage I see is that with the singleton you could save a little typing by getting an instance and giving it a shorter variable name:

    SharedVariables.val1=??;
    SharedVariables.val2=??;
    SharedVariables.val3=??;
    SharedVariables.val4=??;

     vs.

    SharedVariables sv = SharedVariables.getInstance();
    sv.val1=??;
    sv.val2=??;
    sv.val3=??;
    sv.val4=??;



    In the singleton case you can easily add "complex" initialization in the constructor. Also, if you never use the singleton, the variables won't be allocated/initialized.
  • (cs) in reply to John Smallberries
    John Smallberries:
    Interesting. It's silly (possibly dangerous) to do this, but I see no reason the compiler should reject it. In fact, the C# compiler has no problem with it.

    Does anyone care to comment on whether or not the VB compiler is doing the right thing? Does anyone still use VB? Does anyone care?

    <font size="2">...feels weirdly narcissistic quoting myself...</font>
  • (cs) in reply to John Smallberries

    John Smallberries:
    John Smallberries:
    Interesting. It's silly (possibly dangerous) to do this, but I see no reason the compiler should reject it. In fact, the C# compiler has no problem with it.

    Does anyone care to comment on whether or not the VB compiler is doing the right thing? Does anyone still use VB? Does anyone care?

    <FONT size=2>...feels weirdly narcissistic quoting myself...</FONT>

    I do think the compiler is doing the right thing.  But that may be because I still think of structs in a C like way and I have yet to use on in c#.

    No. 

    No.

  • (cs) in reply to JohnO

    That should be write instead of use.

  • (cs) in reply to JohnO
    JohnO:

    John Smallberries:
    Interesting. It's silly (possibly dangerous) to do this, but I see no reason the compiler should reject it. In fact, the C# compiler has no problem with it.


    I do think the compiler is doing the right thing.  But that may be because I still think of structs in a C like way and I have yet to use on in c#.


    ipso facto, you think the C# compiler is doing the wrong thing? Or are the semantics of this construct different in the 2 languages?
  • (cs) in reply to John Smallberries
    John Smallberries:

    Does anyone care to comment on whether or not the VB compiler is doing the right thing? Does anyone still use VB? Does anyone care?


    Considering the nature of structs, a struct without non-static fields has a size of 0 bytes. I wonder how C# allocates an instance of such a struct.
  • (cs) in reply to cconroy
    cconroy:
    <font size="2">"Don't know why, but..."-type comments are great.  They say, "Hey, there's some kind of problem here, but at least I got it working.  Good luck fixing it the right way after I've been fired/downsized/promoted to management!"

    </font>


    Ya, we once had a PC that kept flaking out with memory parity errors.  So our WTF went to fix it, and reported back that it was fixed.  After that it just crashed, with no error.  So our non-WTF guy went to check it, and found that WTF guy had turned off memory parity checking in CMOS.

    And since I know someone is going to mention that the real WTF was having WTF guy around- well, no, the real WTF was that we worked in a union.

Leave a comment on “Please Compile”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article