Quote Originally Posted by xld
They are, but you only code them once, and then re-use them And if you are any good, you think about them, so you make them flexible, extendible, and powerful - all words it is difficult to apply to UDTs.
I totally agree, classes are a much better approach. And I tend to favor them over even standard modules. But I am not taking the stance that UDTs have more value than a class. They don't. I am taking the stance the UDTs have a value in some circumstances.

[quote=xld]I would argue that if it is not for production, you would be unlikely to need UDTs. But more to the point, no you wouldn't create a rectangle class, you would create a polygon class. Far more useful.
/[quote]
And that is my whole point. This, is why UDTs are useful.

If all I need is a Rectangle, and I come back two hours later and you are still coding up "One Shape Class to Rule Them All", I'm going to be like: "Dude, none of our forms, controls, screens, etc will be anything other than 4 sides of 2 equal values. If, in the future, we need need to add code for all of those octogonal forms we use, then build that shape class... And if you really feel the need, you can replace our rectacgle UDT with a wrapper that interacts with the shape class. But while we are still using rectangles.... Stop wasting time." (Well IRL, I wouldn't be quite that direct. But I'd be thinking it )

The whole point of OOP is to keep code self-documenting, self-scoping, so it's easy to understand and maintain after the original developers have moved on. UDTs meet those goals in a very simplistic fashion. You can do more with a class, and when you need to do more, use one. But IMHO you should always use the simplest tool needed to accomplish the task.

I'd further point out than even fully OOP languages make use of data structures.