Comment On Please Compile

At least he was being polite.

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.

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

Think putting in a "Public PleaseGiveMeOneMillionDollars As Boolean" statement will work, too? I mean, if the compiler is taking requests...

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?

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

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...

limelight:

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

One is a integer and the other is a string.

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

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

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.

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?

Anonymous:

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

A singleton class.

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.

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?"

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.

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.

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.

limelight:

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

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

 

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.

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.

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? 

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

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.

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.

"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!"

Not if it's set to false!

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.

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

cconroy:

"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!"

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

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=??;

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".

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.

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.

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.

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.

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.

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...

trwtf here is that it should have been

Public TheJuice As Boolean

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.

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. [*-)]

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!!

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.

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.

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?

...feels weirdly narcissistic quoting myself...

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?

...feels weirdly narcissistic quoting myself...

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.

That should be *write* instead of *use*.

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?

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.

cconroy:

"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!"

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.