Why can't I inherit from DateTime?

[Frank Rizzo]

Any ideas?

[Nurchi BECHED]

Because System.DateTime is a sealed class which means that you
cannot extend (inherit from) it.

But why in the world would you want to extend DateTime?

In the worst case, create a class, and make a DateTime field.

Hope this helps.
Good luck.

On Tue, 22 Feb 2005 18:25:32 -0800, Frank Rizzo <no**@none.co m> wrote:

Any ideas?

--
Regards,
Nurchi BECHED

P.S.
C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do,
it blows away your whole leg."
--Bjarne Stroustrup

[Jeff Louie]

???? According to the docs DateTime is a value type, a struct and you
cannot extend a struct.

Regards,
Jeff

Because System.DateTime is a sealed class which means that you cannot

extend (inherit from) it.<

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Michael S]

"Frank Rizzo" <no**@none.co m> wrote in message
news:On******** ******@TK2MSFTN GP12.phx.gbl...

Any ideas?

Have a look at value types and reference types, called structs versus
classes in C#.
In many ways, a struct is quite an opposite of a class.

Here are some differences.

A class instance is allocated with reference on stack or heap, with the
object always on heap. A struct instance is allocated directly on stack (for
local instances in methods) or embedded in an object on heap.

A class is inheritable. A struct is implicitly sealed and always inherits
from Object. (This answers your question)

A class can be cast to itself and to any superclass of it's type. A struct
can only be boxed into Object and unboxed to it's sealed type.

A class supports polymorhpism. Structs have limited support for polymorfism
as you can override or reindtroduce methods on the Object class. However,
the abstract or virtual keyword makes non sense on value types and are so
forbidden in C#.

A class instance is garbage collected. A struct instance on stack is simply
removed when a method ends or are implictly collected from heap when when an
class instance is garbage collected.

A class is a beautiful thing. structs sucks! =)

Hope this helps

- Michael S

[Richard Blewett [DevelopMentor]]

You forgot one - and this is the reason for their existance - With no boxing, structs are faster and smaller which is why all the primatives are valuetypes and things like System.Drawing. Point

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

"Frank Rizzo" <no**@none.co m> wrote in message
news:On******** ******@TK2MSFTN GP12.phx.gbl...

Any ideas?

Have a look at value types and reference types, called structs versus
classes in C#.
In many ways, a struct is quite an opposite of a class.

Here are some differences.

A class instance is allocated with reference on stack or heap, with the
object always on heap. A struct instance is allocated directly on stack (for
local instances in methods) or embedded in an object on heap.

A class is inheritable. A struct is implicitly sealed and always inherits
from Object. (This answers your question)

A class can be cast to itself and to any superclass of it's type. A struct
can only be boxed into Object and unboxed to it's sealed type.

A class supports polymorhpism. Structs have limited support for polymorfism
as you can override or reindtroduce methods on the Object class. However,
the abstract or virtual keyword makes non sense on value types and are so
forbidden in C#.

A class instance is garbage collected. A struct instance on stack is simply
removed when a method ends or are implictly collected from heap when when an
class instance is garbage collected.

A class is a beautiful thing. structs sucks! =)

Hope this helps

- Michael S

[Joanna Carter \(TeamB\)]

"Richard Blewett [DevelopMentor]" <ri******@NOSPA Mdevelop.com> a écrit dans
le message de news: #r************* *@TK2MSFTNGP14. phx.gbl...

You forgot one - and this is the reason for their existance - With no

boxing, structs are faster and smaller which is why all the primatives are
valuetypes and things like System.Drawing. Point

So, if I design my own value types that include events, etc and have
implicit conversion operators to simplify code e.g. IntegerType, StringType,
FloatType, etc; Am I better using structs or classes ?

If I rely on implicit operators, does remove some of the requirement for
boxing ?

Joanna

--
Joanna Carter
Consultant Software Engineer

[Michael S]

"Joanna Carter (TeamB)" <jo*****@nospam forme.com> wrote in message
news:uN******** ******@TK2MSFTN GP09.phx.gbl...

"Richard Blewett [DevelopMentor]" <ri******@NOSPA Mdevelop.com> a écrit
dans
le message de news: #r************* *@TK2MSFTNGP14. phx.gbl...

You forgot one - and this is the reason for their existance - With no

boxing, structs are faster and smaller which is why all the primatives are
valuetypes and things like System.Drawing. Point

Indeed Richard and Joanna.

I added that last tidbit that structs sucks just for letting someone make
this point (about Points *S*).
However, I think there is seldom reason for defining your own value types.
Every time I start by thinking of a type as a struct I usually wind up
making it a class. I typically ask my self, - Can I assure that an instance
of this type won't be passed to a method as an Object. Most structs seldom
pass that test.

I think structs will be more used in .NET 2.0 as generic types as List<T>
and such will cope with the boxing problem. When this happens I think people
will use structs for business entities and data entities, and not interfaces
as Java typically does things.

I'd rather see a Customer as a struct and not an class or interface. The
struct says - "I am a customer and I do this and that and I am written in
stone so you can always expect the same behavour from me!" I think this
makes more sense than having an class go: - "I am perhaps a customer or
something more special than that and I may do what you expect if not
something completly overriden." Interfaces though are worst in my view: - "I
am sorta like a customer and I behave in a customerlike way. But exactly
what I do is hidden from you and may change at anytime depending on the
factory that (perhaps) loaded me dynamically. You'll never know!"

In of .NET 1.1, I don't use structs for the above purposes as it's
performance problem in regards to boxing is quite costly.

As I have always admired your articles and posts in the delphi OO group,
Johanna; I hope you comment on the above.

- Michael S

[Richard Blewett [DevelopMentor]]

The boxing will only occur if you pass the value to a method that takes System.Object, if you take an interface based reference or you call one of the System.Object virtual methods that you haven't overridden.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

"Richard Blewett [DevelopMentor]" <ri******@NOSPA Mdevelop.com> a ?crit dans
le message de news: #r************* *@TK2MSFTNGP14. phx.gbl...

You forgot one - and this is the reason for their existance - With no

boxing, structs are faster and smaller which is why all the primatives are
valuetypes and things like System.Drawing. Point

So, if I design my own value types that include events, etc and have
implicit conversion operators to simplify code e.g. IntegerType, StringType,
FloatType, etc; Am I better using structs or classes ?

If I rely on implicit operators, does remove some of the requirement for
boxing ?

Joanna

[RichGK]

"Richard Blewett [DevelopMentor]" <ri******@NOSPA Mdevelop.com> wrote in
message news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

You forgot one - and this is the reason for their existance - With no boxing, structs are faster and smaller which is why all the primatives are
valuetypes and things like System.Drawing. Point
Regards

Richard Blewett - DevelopMentor

So why make DateTime a struct? Its not what I'd consider a primitive.

[Michael S]

"Richard Blewett [DevelopMentor]" <ri******@NOSPA Mdevelop.com> wrote in
message news:Oi******** ******@TK2MSFTN GP12.phx.gbl...

The boxing will only occur if you pass the value to a method that takes
System.Object, if you take an interface based reference or you call one of
the System.Object virtual methods that you haven't overridden.

Regards

That 'only' is not as harmless as it seems. Heavily used classes as
ArrayList and HashTable is really hurt by boxing value types. When those
general classes becomes generic classes in .NET 2.0 this problem will be no
more.

In .NET 1.1 I use structs on large classes with many members to group
members in a ordely fashion. So for me structs are just for readability,
while it may become quite useful in NET 2.0.

- Michael S