CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Grant Killian's Blog

No, this has nothing to do with beer -- but maybe it should?

the Bob's blog

Author of Coding Slave, Bob Reselman (aka “the Bob“), is joining the blog community with his Coding Slave blog: http://codingslave.blogspot.com/.  It's “the Bob Blog.”  Say it 10 times fast . . .  It's part socratic introspection, part social commentary, with a dose of technology thrown in.  Rosa Luxembourg would be proud (google it if you don't know who she is): “Love of your own country is patriotism; love a country owned by others is not patriotism, but something else.“   

Check it out if you're in the mood for something smart and semi-colon free (meaning, it's not just about programming).  I was lucky to grab a meal with “the Bob“ last year and he is an unabashed deep thinker in a world that could use a lot more deep thinking. 

In my opinion, one great reason to follow blogs is to foster critical thinking about topics you may not otherwise consider.  This may come as a surprise, but it's not just about finding code you can copy-and-paste.  Go on and take the red pill . . . or was it the blue pill?  I forget.  Check out The Bob's blog.

 



Comments

PassingBy said:

Nice counter !
# January 25, 2005 8:23 AM

John Wood said:

It seems, though, that what you want in that scenario is to use a decimal but to format it properly when you display it (through a view or something) (at least that's how I'd do it).

wrt the runtime casting, couldn't you define a custom type converter? Granted the typed dataset won't do anything with it, but if you customize the dataset then you might be able to make that work.
# January 25, 2005 9:58 AM

Sahil Malik said:

Johnie Boy,

This is gotta be an awfully written post, cuz my meaning totally slipped you by.

You can acheive the above in a zillion ways - none as elegant and straightforward and intuitive as the one above. ONLY BECAUSE. I cannot implement casting to and from an object. Now intuitive is subjective and can be argued until the cows come home - but dude - I am strongly convinced that to a neophyte .net programmer, I'd look to do something lik the above before looking at other avenues - only to hit a brick wall - and others are merely workarounds.

That is what I was trying to get at.
# January 25, 2005 1:22 PM

Bill said:

Amen brother!
# January 25, 2005 2:48 PM

Sahil Malik said:

Amen bro !! Amen !! (Passes the chillum to ol'e billy)
# January 25, 2005 2:54 PM

John Wood said:

Ah I did miss your point.. that's what happens when i read on an empty stomach. You're right you would go straight for writing your object converter and it won't work... and the whole typed dataset thing is becoming a mess because of the lack of generics and nullable types from the beginning. Plus think of all the legacy stuff that's out there already when they do finally fix it. Another fine mess they've gotten us into...
# January 25, 2005 2:55 PM

Sahil Malik said:

Exactly John !! :) Now u get my point.

Now the above example is nothing but the tip of the iceberg .. imagine all those "Objects" inside the DN Framework. :)
# January 25, 2005 2:56 PM

John Wood said:

I was thinking about something like that earlier today... not just all those objects, but all those Hashtable/ArrayList/BaseCollection classes too -- wouldn't it be cool if they could write something that would upgrade all our code for us, detect all these collections and objects, work out what we're putting in them... and turn them into generics for us. Maybe it can fix our bugs too.
# January 25, 2005 3:00 PM

Sahil Malik said:

John,

Unfortunately, I don't that can be done.

Hashtable/Arraylist both can store multiple datatypes in the same instance of the Hashtable or arraylist.

So you could do Arraylist.Add(Dog) and Arraylist.Add(Cat) .. wheraz generics let u do something like this

List<Cat> l;
l.add(Cat1) ;
l.add(Cat2) ;
l.add(Dog) ; // Throws error.

The code ain't quite right but, U know what I mean :)
# January 25, 2005 3:03 PM

Sahil Malik said:

(My hands must be tired .. I wanted to type above .. "I don't think that can be done"
# January 25, 2005 3:05 PM

John Wood said:

Shouldn't that counter actually say "this post has been loaded or refreshed independently or as part of an aggregated feed or page N times" :)
# January 25, 2005 3:05 PM

Sahil Malik said:

Shouldn't you be going to bed now?
# January 25, 2005 3:06 PM

John Wood said:

Well i did ommit that this app would be intelligent enough to figure out the common interface or class encompassing all of the objects that the code appears to add to the collection.. and then suggest changing it. I bet it would cover about 85% of cases... well in my code anyway.
# January 25, 2005 3:07 PM

John Wood said:

Yes mom.
# January 25, 2005 3:10 PM

Sahil Malik said:

John,

Again, System.Collections.Arraylist is largely different and just as important as System.Collections.Generics.* .. I don't think a tool is writable .. but dude .. be my guest .. and make us proud :)

- SM
# January 25, 2005 3:11 PM

Sahil Malik said:

See .. now you wanna suck my tits .. whats wrong with u !!
# January 25, 2005 3:13 PM

Bill said:

Ok, I know I'm not drinking or smoking crack so this must be a real thread. At first it seemed like a real thread - but it's - well.

Ok, at the risk of being an a33hole - Sahil - I totally agree with you but John - you've totally lost me. Why would such a tool be written even if it were possible? The objects referenced behave totally differently - that's why I usually don't lookup values in my ArrayLists with a Key and expect back a value.

I must have missed something.
# January 25, 2005 3:19 PM

Sahil Malik said:

Bill, I agree with you, It's not just a question of the lookup values in the arraylists or hashtables with their keys and values, the uses of these classes are specific and cannot be interchanged with each other.

The Generic collection classes are merely but a better implementation of a specific case/use of these classes. I don't think such a tool would be useful even, I'd be scared to run it.

_ SM
# January 25, 2005 3:22 PM

Bill said:

Sahil - not to hop on my soap box - but yes, your statement is dead on. Generics weren't intended to solve the 'problem' you presented.

I don't mean to be a smart a33 but by the reasonsing used above, why stop at system collections? Why not just convert everything to Object? I mean, you could have the ToString() method for everything.

The common interface would by System.Object - the only way to make any real determination would have to be recursive and this is where you'd end up. But as far as interfaces, what about typical classes that impmlement multiple interfaces? And who would win in an ownership battle - the base class or the interface?

I may have a XBase for some given part of a project, and XBase is MarshalByRefOBject - Accordingly, since we're remoting it - we must have an interface b/c we won't have an assembly reference to the class or base class. Can you imagine the cluster f*** if you even tried to fool .NET with generics? Well, actually there wouldn'tt be b/c they aren't in any way, shape, manner or form intended to fool anything.

Again, I'm missing something here. Hmm, I wonder what should take precedent, MarshalByRefObject or my IBusinessBase?

Glad I'm not writing such a tool.

John, unless I'm missing somethign critical here - I'm totally missing your point. But that happens a lot - so if I am - please help me out ;-)
# January 25, 2005 3:34 PM

John Wood said:

Sahil, I never gave your breasts a passing thought until I read that comment. Thanks for that!

Bill - if i use a hashtable to provide a lookup for customer's names, and i know it holds a (and only a) Customer object, then that would be a candidate to turn into a Hashtable<string,Customer> would it not? So if I can determine that by analyzing the code, then I could make that conversion for me, along with changing where it's called to remove any casts. A long shot, true, but useless? I don't agree...
# January 25, 2005 3:38 PM

Sahil Malik said:

Thats right Bill, the above discussion isn't even about Generics .. now can anyone guess .. what the fudge will really solve the above issue? :)

Hint: Whatever it is, is explicitly disallowed by the .NET CLR Spec.
# January 25, 2005 3:39 PM

John Wood said:

"Why not just convert everything to Object?" - man I think we're all talking about completely different things! Ok that means it's time for bed. I'll get back to this with a clearer head tomorrow (as long as the snow doesn't kill my commute)
# January 25, 2005 3:42 PM

Sahil Malik said:

John,

The easiest way to prove your point would be to go ahead and write the tool.

Has anything like this ever been written before that you can gain clues from? :)

- SM
# January 25, 2005 3:46 PM

Bill said:

John - how could such a best exist? Hash tables need both an index and key don't they? Actually, and I don't mean to be contentious - but I think turning it into a string, customer beast would be - well, already there for you. If SSN is the lookup value - why not make the SNN the Key and the Customer the value? If you're talkinga bout an ArrayList and making it a Hashtable type collection - ok - but I still don't see the point b/c that's there now.

But just look at the collection example. how many different base classes - and interfaces are there at any given implementation? Lots. Who takes precedence in a conversion? Beats me - it depends on usage. I could implement 20 interfaces 19 of which never get used, and the 17th one if the stuff my code is using. But then 2 weeks later, joe new programmer comes in and decides he want's to hit item istead of Key - Kabooom.
# January 25, 2005 3:47 PM

Frans Bouma said:

The problem is that there are multiple ways of specifying something is NULL: System.DBNull.Value, null/Nothing, some 'value' which represents NULL, a nullable type...

The stupid thing is that in ADO.NET they still use DBNull.Value for NULL values, instead of nullable types. (a nullable type is just a struct with a flag, your Money struct (not an object!) should have that flag as well). This means that in the beloved dataset, cells are not filled with a nullable typed value, but with DBNull.Value. Which is stupid as the value is boxed and it should be null/Nothing, the only way you can define NULL in .NET.

It's sad the CLR guys made a shortcut for valuetypes. I mean: you can do: int i=4;object o=i; but you can't do int i=null; while it apparently does inherit from object. If that would have been possible, we wouldn't have had all this misery in the first place.
# January 25, 2005 7:40 PM

Sahil Malik said:

Frans, you've explained it *really* well. See, that is one of the things that I'm saying -

I wish the CLR handled value types being null better than it does - even in 2.0. Not to mention all the code we are stuck with, but even 2.0's int? or <Nullable> didn't really help that situation.

The second point I was trying to make was, the inability to inherit from System.ValueType.

Everything I write is a System.Object, so inside the .NET Framework, where they could have a possibility of getting a null or an unseen data type, they were forced to use an Object. A good example is the DataTable.Expression property, which during row addition time, ends up setting the new column's value to an Object.

So what I'm stuck with is, anything that I write, inherits from System.Object - so I cannot implement an explicit or implicit cast from Object, which means I cannot possibly ever create my own data type that I can use in the Expression; and I am sure more such examples exist all over the framework.

So, are we ready for a .NET Redux framework yet? :)

And I must be clear, I don't think this in itself qualifies as a good enough reason for me to dump .NET Framework, but it is clearly an example where the original .NET framework design falls short.

I would be curious to know though - why did they do this??
# January 25, 2005 10:38 PM

John Wood said:

Bill,
The point is that a generic hashtable would be type safe and in many cases perform better, so all those times I've been lazy and used a plain-old hashtable - I'd be looking to change those to generic hashtables. Just ends up with cleaner, faster and more reliable code.
# January 26, 2005 2:00 AM

John Wood said:

Frans,
I wouldn't really call it a shortcut to value types.. fundamentally we all know that value types are just stored in as few bytes as possible and we like that. If you want to make it nullable, think of the overhead that would incur on every statement that gets or sets that value: You'd no longer be dealing with pure primitive types. The way it's implemented now is the most performant solution, the generics solution to nullable types is nice but as we all know not perfect. It's a hard problem to solve -- and what we have now is certainly not a shortcut!
# January 26, 2005 2:15 AM

John Wood said:

Sahil..
I guess one solution would be to allow you to override what happens when you unbox your value type. Perhaps a constructor in your struct with an object parameter could be implicitly called on every unbox. That way you can check for nulls, set a flag accordingly, or whatever you want. In fact perhaps they could do this without changing the CLR, just have the C# compiler replace any object/valuetype assignments with a call to the struct's constructor passing in the object instead. I'm probably missing something but that seems like it could work?
# January 26, 2005 4:22 AM

Sahil Malik said:

Urrghh !!

John, I'm hella busy at work, but try making this work

Object o = 1.38829 ;
Money m = o ; // m must contain 1.38 at this point.

You'll know what you're missing. Just open up VStudio and write it out .. you'll know what I mean.
# January 26, 2005 4:41 AM

Sahil Malik said:

And I'm not gonna answer for Bill & Frans, but I think they made perfectly valid points. .. either way .. I gotta get bak2wurk !!
# January 26, 2005 4:42 AM

John Wood said:

sahil - understood man.
But for when you get a minute...
Thinking about it further, you're right - this is really about conversion than unboxing, you really need the ability to define an implicit cast for object. If they just allowed that then we'd all be happy campers (also assuming that a null value would be an object type). Sure everything inherits from object, but it can exhaust other types before it goes for the object cast operator. Am I getting it yet?!?!
# January 26, 2005 5:15 AM

Sahil Malik said:

Well .. John .. by being able to do that, you get a good workaround for a major portion of the problems that already exist .. because .NET did not support null values on value types to begin with.

The better solution would have been to allow null values on valuetypes. But we're left with not much choice now.
# January 26, 2005 6:27 AM

Bill said:

John - I never argued otherwise. But in this example you're talking about hash table to hash table conversions. If it sounded like I was arguing against stronger typing - well, wasn't me bro - that day will never come.

But if you had something that generically converted stuff a la your original comments - well, it ain't gonna happen either because it's impossible to determine your intent.
# January 26, 2005 11:20 AM

John Wood said:

Bill - yeah I think there was a misunderstanding there. I never meant anything more than something that could help you convert plain hashtables into genericized hashtables, and maybe plain arraylists into genericized arraylists. Ah forget it, would be too much work anyway!
# January 26, 2005 12:37 PM

Darrell said:

Thanks for the pointer. You are our designated "big thinker". :)
# January 27, 2005 6:47 AM

Grant said:

Thanks but I know it's getting close to Valentines Day and you're just warming up for that fiance of yours!
# January 27, 2005 6:50 AM

Bob Reselman said:

Hi Grant:

Thanks for the attention and support.

It is comforting to know that one's thinking is useful beyond the boundaries of one's own frontal lobes.

Bob
# February 21, 2005 11:42 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add
Check out Devlicio.us!