Comment On I, Object

Were I on this project, I too would object.

Alex Papadimoulis:

Every once in a while, I like to present a representative line of code from a titanic (an adjective chosen for more than its synonymity with "frickin' huge") application. That's right -- hundreds of codefiles with thousands of classes with hundreds of thousands of lines of code -- all into one, single line. Today's line comes from an application whose team Marcelo recently joined, and is the from the definition of the base class for all objects in their system ...

public abstract class Object : IObject {

I'll leave it as an exercise for the reader to try to imagine how well things took off from here.

 

'abstract' .. no pun intended.

Bus Raker:

Alex Papadimoulis:

Every once in a while, I like to present a representative line of code from a titanic (an adjective chosen for more than its synonymity with "frickin' huge") application. That's right -- hundreds of codefiles with thousands of classes with hundreds of thousands of lines of code -- all into one, single line. Today's line comes from an application whose team Marcelo recently joined, and is the from the definition of the base class for all objects in their system ...

public abstract class Object : IObject {

I'll leave it as an exercise for the reader to try to imagine how well things took off from here.

 

'abstract' .. no pun intended.

And I think everything should be wrapped in a 'code' object too ... just to make it scalable and enterprisey

Alex Papadimoulis:

Today's line [...] is the from the definition of the base class for all objects in their system ...

public abstract class Object : IObject {

So the base class of *all* objects itself implements some sort of interface, named in true honor of hungarian notation with an "I" prefix and obviously only created to be implemented by exactly one class.

Did I miss anything else?

Hungarian notation? What does I stand for then?

This looks more like Asimovian notation for me :)

so todays WTF is that the class doesn't have a closing brace?  Wow, debugging is easy!

Anonymous:

Alex Papadimoulis:

Today's line [...] is the from the definition of the base class for all objects in their system ...

public abstract class Object : IObject {

So the base class of *all* objects itself implements some sort of interface, named in true honor of hungarian notation with an "I" prefix and obviously only created to be implemented by exactly one class.

Did I miss anything else?

I'm dying to know what methods that interface exposes.

Anonymous:

Hungarian notation? What does I stand for then?

Interface?

PS: captcha is 'craptastic' ;]

interface IObject extends IWtf { 

  public IObject getPaula(); 

  public boolean isBrillant(); 

} 

Seriously, without having seen the details, can we even assume that IObject implements the actual interface for Object?

Anonymous:

Anonymous:

Alex Papadimoulis:

Today's line [...] is the from the definition of the base class for all objects in their system ...

public abstract class Object : IObject {

So the base class of *all* objects itself implements some sort of interface, named in true honor of hungarian notation with an "I" prefix and obviously only created to be implemented by exactly one class.

Did I miss anything else?

I'm dying to know what methods that interface exposes.

Probably something like GetType();

Wait, is Object *extending* or implementing IObject? The colon syntax confuses me. Obviously I was thinking IObject is an interface so it must implement. That'd be an extra and completely pointless dependency, betraying a lack of understanding of the point of polymorphism.

Yet, extending the IObject class would be poetic for a WTF - rich in its construction, with a completely ambiguous obtuse meaning. I hope it's extending. Then the code is deliciously special.

Anonymous:

Hungarian notation? What does I stand for then?

This looks more like Asimovian notation for me :)

The three rules of IObject-ics

1. An Object may not disinherit an IObject, or, through indirection allow a subclass to disinherit an IObject
2. An Object must extend the interface given to it by an IObject, except where such extension would conflict with the First Law
3. An Object must implement its own interface, as long as such implementation does not conflict with the First or Second Law

what language is this?
 isn't IObject going to be private?

 what methods can be called thru Object to IObject ?
 ...

 I dont know, is it private or not?

lol Captcha truthiness

.. lol that is a wtf
 

VB sucks...   so does today's WTF

Anonymous:

what language is this?

It's C#. The colon gives it away.



Captcha = enterprisey

I'll leave it as an exercise for the reader to point out that Alex may be getting repetetive. :)

Anonymous:

The colon gives it away.

That's what my proctologist said my problem was.

tiro:

Were I on this project, I too would object.

With such an enterprisey object-oriented paradigm, that's easy:



public abstract class I2Object : IObject {}



See?  Infinitely scalable!

Alex Papadimoulis:

Every once in a while, I like to present a representative line of code from a titanic (an adjective chosen for more than its synonymity with "frickin' huge") application. That's right -- hundreds of codefiles with thousands of classes with hundreds of thousands of lines of code -- all into one, single line. Today's line comes from an application whose team Marcelo recently joined, and is the from the definition of the base class for all objects in their system ...

public abstract class Object : IObject {

I'll leave it as an exercise for the reader to try to imagine how well things took off from here.

Wow, two days in a row of reader exercises.  Maybe Alex thinks we are all getting too fat.

I think I would really like to see what is in the curly braces before I could pass judgement on the WTFness of this though.

Ok, I will tell you whats inside, this is as far as I can leak because of NDA issues.

public override bool Equals(object item)
        {return Equals(this, item);}

Its not a joke by the way.

This code (including the additional bool) is pointless.

There has been much discussion on TheDailyWTF about code that can write itself.

This appears to be one step better: code that does not even need to be written !!

If IObject were a system-supplied base class, then inheriting from it to make an application-wide base class might make sense.

If it's C#, then there already IS an 'object' class, that what makes it extra WTF-ish.

also see:
 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemobjectmemberstopic.asp

Isn't IObject a COM thing?

R.Flowers:

Anonymous:

The colon gives it away.

That's what my proctologist said my problem was.

That deserves a drum roll....ba dum dum psssssshhhhh!

doooh, that's class'y :P

Anonymous:

Anonymous:

what language is this?

It's C#. The colon gives it away.



Captcha = enterprisey

The really bizarre thing is that the .NET framework provides an object class already (with an Object alias in the System namespace), yet they felt the need to make their own...

Anonymous:

Anonymous:

Anonymous:

what language is this?

It's C#. The colon gives it away.



Captcha = enterprisey

The really bizarre thing is that the .NET framework provides an object class already (with an Object alias in the System namespace), yet they felt the need to make their own...

Maybe they needed to do reference counting. ;)

<sigh> hard to get worked up over one line of code...

The only WTF here is that the Object class is public.

Anonymous:

R.Flowers:

Anonymous:

The colon gives it away.

That's what my proctologist said my problem was.

That deserves a drum roll....ba dum dum psssssshhhhh!

That's not a drum roll, that's a ....  oh, wait.  Now I get it.

OneFactor:

Anonymous:

Hungarian notation? What does I stand for then?

This looks more like Asimovian notation for me :)

The three rules of IObject-ics

1. An Object may not disinherit an IObject, or, through indirection allow a subclass to disinherit an IObject
2. An Object must extend the interface given to it by an IObject, except where such extension would conflict with the First Law
3. An Object must implement its own interface, as long as such implementation does not conflict with the First or Second Law

A wonderfully derivitive homage.  My complements!

OneFactor:

Anonymous:

Hungarian notation? What does I stand for then?

This looks more like Asimovian notation for me :)

The three rules of IObject-ics

1. An Object may not disinherit an IObject, or, through indirection allow a subclass to disinherit an IObject
2. An Object must extend the interface given to it by an IObject, except where such extension would conflict with the First Law
3. An Object must implement its own interface, as long as such implementation does not conflict with the First or Second Law

The first rule of IObject is to never talk about IObject. The second rule of IObject is to never talk about IObject.

OneFactor:

Anonymous:

Hungarian notation? What does I stand for then?

This looks more like Asimovian notation for me :)

The three rules of IObject-ics

1. An Object may not disinherit an IObject, or, through indirection allow a subclass to disinherit an IObject
2.
An Object must extend the interface given to it by an IObject,
except where such extension would conflict with the First Law
3. An Object must implement its own interface, as long as such implementation does not conflict with the First or Second Law

Best... Post.. Ever..

Frankly, I fail to see the WTF here. Obviously, this Object class is pointless (and should have an additional isAWeeBitBrillant() method), but harmless.

If there's no real WTF to post on a given day, don't make one up...

I'd have to say that you've outdone yourself with the title of this WTF.

marvin_rabbit:

OneFactor:

Anonymous:

Hungarian notation? What does I stand for then?

This looks more like Asimovian notation for me :)

The three rules of IObject-ics

1. An Object may not disinherit an IObject, or, through indirection allow a subclass to disinherit an IObject
2. An Object must extend the interface given to it by an IObject, except where such extension would conflict with the First Law
3. An Object must implement its own interface, as long as such implementation does not conflict with the First or Second Law

A wonderfully derivitive homage.  My complements!

How do you complement? :)

Anonymous:

R.Flowers:

Anonymous:

The colon gives it away.

That's what my proctologist said my problem was.

That deserves a drum roll....ba dum dum psssssshhhhh!

Except that's a rimshot... were you being deliberately ironic?  My head hurts..

crazyPhil:

Frankly, I fail to see the WTF here. Obviously, this Object class is pointless (and should have an additional isAWeeBitBrillant() method), but harmless.

Surely the WTF is that while everyone occasionally and inadvertently puts in something pointless in the rush to meet a deadline, this application appears to have been deliberately started, on programming day one, with something pointless.

(It may not literally have gone that way, but that's the impression it gives.)

Alex Papadimoulis:

Every once in a while, I like to present a representative line of code from a titanic (an adjective chosen for more than its synonymity with "frickin' huge") application. That's right -- hundreds of codefiles with thousands of classes with hundreds of thousands of lines of code -- all into one, single line. Today's line comes from an application whose team Marcelo recently joined, and is the from the definition of the base class for all objects in their system ...

public abstract class Object : IObject {

I'll leave it as an exercise for the reader to try to imagine how well things took off from here.

I would love to see a little bit more of that code. What were they thinking? Were they even thinking?

Anonymous:

marvin_rabbit:

OneFactor:

Anonymous:

Hungarian notation? What does I stand for then?

This looks more like Asimovian notation for me :)

The three rules of IObject-ics

1. An Object may not disinherit an IObject, or, through indirection allow a subclass to disinherit an IObject
2. An Object must extend the interface given to it by an IObject, except where such extension would conflict with the First Law
3. An Object must implement its own interface, as long as such implementation does not conflict with the First or Second Law

A wonderfully derivitive homage.  My complements!

How do you complement? :)

In this case: with threes-complement.

Anonymous:

Frankly, I fail to see the WTF here. Obviously, this Object class is pointless (and should have an additional isAWeeBitBrillant() method), but harmless.

If there's no real WTF to post on a given day, don't make one up...

Mostly harmless, you mean.
Now it's time to create your custom IObjectWrapper interface.

BiggBru:

Alex Papadimoulis:

Every once in a while, I like to present a representative line of code from a titanic (an adjective chosen for more than its synonymity with "frickin' huge") application. That's right -- hundreds of codefiles with thousands of classes with hundreds of thousands of lines of code -- all into one, single line. Today's line comes from an application whose team Marcelo recently joined, and is the from the definition of the base class for all objects in their system ...

public abstract class Object : IObject {

I'll leave it as an exercise for the reader to try to imagine how well things took off from here.

I would love to see a little bit more of that code. What were they thinking? Were they even thinking?

Every lesson teaching the basics of coding and design should start with the most important rule. Namely, that before acting always ask yourself one question: "Do I really need this thing? Am I the first one to bump into this or that problem?"

And this website could probably close down.

They were **obviously** re-creating the most fundamental of all types in .NET:

from the .NET Framework documentation..."Supports all classes in the .NET Framework class hierarchy and provides low-level services to derived classes. This is the ultimate base class of all classes in the .NET Framework; it is the root of the type hierarchy."

And on top of that they created a public interface, namely IObject, from which to implement.  Hmm....that's brillant!!!

--Thiago

Some people are asking where the wtf is?

Ok:

this is c#, isn't it.

c# has object (or Object)

This "Object" now has to be disambiguated from System.Object through it's namespace: nice.

This "Object" can't be instantiated: you have to implement something that does any real work, fair enough: you are required to pick up the baggage of the IObject interface and implement, whatever that may be, and no matter how irrelevant or inconvenient: nice.

.NET has alwayss had extensive support for smarter ways of handling global requirements for application objects with automatically discoverable information : attributes, databinding and reflection to name a few. Just as an aside, see IComparable in .NET for giggles related to a higher post. So, the wheel re-invented in what looks suspiciously like the output of a ham-fisted Java programmer: Nice.

There are going to have to be some base classes that will attempt to implement IObject correctly, to avoid similar code being cut and pasted 100s of times. This code of course, must be able to cater for any circumstance subclasses may throw at it, presumably through aggregating IOuijaBoard: nice.

I don't need to go on.

I've run out of circusmtances where this approach willl help, unless we are consider the boost to the career of a technical architect besotted with the idea of code-generating the world, and letting the developers pick up the pieces.

 

 

 

 

 

cconroy:

tiro:

Were I on this project, I too would object.

With such an enterprisey object-oriented paradigm, that's easy:



public abstract class I2Object : IObject {}



See?  Infinitely scalable!

Great!

Anonymous:

Some people are asking where the wtf is?

Ok:

this is c#, isn't it.

c# has object (or Object)

(etc.)

That's assuming that anybody is actually using (or being forced to use) this base class, which we don't know. Also it's assuming that the IObject interface is not empty, which we don't know. We can *imagine* a lot of bad things that *could* be in the system in question, but as somebody else said - it's hard to get worked up over this one line of code. To me, this still looks like a very contrived WTF.

Anonymous:

Isn't IObject a COM thing?

Close, all COM objects are required to at least implement IUnknown, which contains methods for getting other interfaces

Anonymous:

Anonymous:

marvin_rabbit:

OneFactor:

Anonymous:

Hungarian notation? What does I stand for then?

This looks more like Asimovian notation for me :)

The three rules of IObject-ics

1. An Object may not disinherit an IObject, or, through indirection allow a subclass to disinherit an IObject
2. An Object must extend the interface given to it by an IObject, except where such extension would conflict with the First Law
3. An Object must implement its own interface, as long as such implementation does not conflict with the First or Second Law

A wonderfully derivitive homage.  My complements!

How do you complement? :)

In this case: with threes-complement.

If twos-complement is for subtraction, what is threes-complement for? detraction?