Is default constructor always created?

  • Thread starter Thread starter Andrew J. Marshall
  • Start date Start date
A

Andrew J. Marshall

I want to create a class that must receive a parameter when instantiated.
In other words, I do not want it to have a "Public Sub New()".

1) Does VB.NET create a default public constructor if I do not declare one?

2) I've read that I can have a "Private Sub New()" which should take care of
my needs. Comments?

Thanks,
Andrew
 
Andrew,
1) Does VB.NET create a default public constructor if I do not declare
Click to expand...
one?
VB.NET creates a default public constructor if you do not declare ANY
constructors, if you define a constructor in the class, the default public
constructor is not created. Remember constructors are NOT inherited.
2) I've read that I can have a "Private Sub New()" which should take care of
my needs. Comments?
Click to expand...
You only need a Private Sub New if its the only constructor and you want to
prevent others from creating the class. Or you have a Form, Control or
Component as the VS.NET Designers require a default constructor, and you
don't want the default constructor from being used. I would consider making
it Protected in this case.

Hope this helps
Jay
 
I want to create a class that must receive a parameter when instantiated.
In other words, I do not want it to have a "Public Sub New()".

1) Does VB.NET create a default public constructor if I do not declare one?
Click to expand...

Yes, unless you add a parameterized constructor. In that case, the
compiler will not create a default constructor. So basically, all you
have to do is add the constructor you want, and no default will be
created.
2) I've read that I can have a "Private Sub New()" which should take care of
my needs. Comments?
Click to expand...

Well, unless you want to do stuff in the private constructor there is no
need to do this.
 
AFAIK The default blank constructor is only provided as long as you don't
provide any other constructor. If you provide any other constructor (public,
private, with parameters etc.) then it won't automatically put the default
one in - you can still specify it yourself if you want.

It's yet another thing that VB tries to hide from the developer. As a
convention I always manually put a blank constructor in the class if it
supports it - even if it is only a call to MyBase.New() - just for clarity.

HTH,

Trev.
 
Andrew,

* "Andrew J. Marshall said:
I want to create a class that must receive a parameter when instantiated.
In other words, I do not want it to have a "Public Sub New()".

1) Does VB.NET create a default public constructor if I do not declare one?
Click to expand...

It will only be created if you don't create any other ctor.
2) I've read that I can have a "Private Sub New()" which should take care of
my needs. Comments?
Click to expand...

If you want to forbid any instantiation, yes. If you want to forbid
instantiation by using a parameterless ctor, define a parameterized ctor
only and do not define any parameterless ctor.
 
Trev,
It's yet another thing that VB tries to hide from the developer.
Click to expand...
I don't think the "Default constructor" being added is a trait of VB.NET per
se, as Java, C#, and C++ do the same thing.

Hope this helps
Jay
 
Cheers Jay. I stand corrected.

Doesn't mean I like having to define a private or friend constructor just to
override the default behaviour of a class being publicly creatable. I'd much
rather the default behaviour was to not make the class createble unless you
explicitly defined a constructor (which is something the IDE could add in as
part of code completion maybe).

Just my 2c in my little explicit world ;)

Trev.
 
Trev,
I'm sorry that does not make sense! ;-)

If I'm reading you correctly, you are suggesting that you want to have to
add a public default constructor if you want a publicly created class, which
I suspect is what the majority of developers will want. As opposed adding a
private default constructor in the minority of the cases?

I'm excluding the cases where you have non-default constructors
(parameterized constructors) as you have to add them any way.

Hope this helps
Jay
 
I suspect is what the majority of developers will want.
As opposed adding a private default constructor in the
minority of the cases?
Click to expand...

I'm not arguing that a blank public constructor shouldn't be added by
default, I'm arguing that it shouldn't be hidden. It could be added
automatically by the code editor - the same way the IDE sticks in "End If"
constructs. I realize not everyone uses an IDE, and I know this goes against
the grain of most developers creating a class and expecting it to be
creatable by default, but I tend to write code so as to make it as explicit
as possible and this is one of those things that I like to make explicit.
I'd much rather delete the default Public Constructor than implement a
private constructor (that overrides some hidden constructor) in order to
make a class non-creatable.

I don't expect that this will behaviour never be changed, but one of the
reasons I tend to make things explicit is that I've been caught out too many
times in the past by double standards in VB - for example if you use "Dim"
to declare a field at class level leaving out a scope marker - its scope is
private. However if you declare a class without a scope marker, its scope is
friend.

Sorry for rambling on a crappy technicality. I'm just in a talkitive mood
today ;)

Trev.
 
I don't expect that this will behaviour never be changed,

lol. Sorry. I'm suffering from BFS today (Brain Fried Syndrome). It should
read:

"I don't expect that this behaviour will ever be changed"

Trev.
 
Hi Jay,

I understand Trev's point. The very lack of anything being there can lead
to confusion.

I'll give you an example (as I understand it)... when Java first came out if
a class could throw an exception you "had to" create an error handler for
that error regardless of whether you wanted to trap the error or not. You
could pass it along but the concept was "at least you knew you had an error
and you consciously decided to pass it up the chain."

This proved to be too much of a burden (so people worked around it) and I
believe the compiler no longer enforces it as a rule. The concept was
"sound" but in practice it didn't work.

It can't be considered very much work to add a public constructor... at
least one could see it there and not wonder if there was one further down
the class somewhere. As with so many readability issues they mostly don't
affect the person who originally writes the code but for those that come
along afterward.

As Trev points out, it won't change so it isn't a big deal. But look at how
much nicer things are now that you can see the actual code that the form
generates for initializing the form. VB was horrible for hiding this for so
many years, Delphi was great for exposing it right from the start.

Tom
 
Hey Tom,


Tom Leylan said:
Hi Jay,

I understand Trev's point. The very lack of anything being there can lead
to confusion.

I'll give you an example (as I understand it)... when Java first came out if
a class could throw an exception you "had to" create an error handler for
that error regardless of whether you wanted to trap the error or not. You
could pass it along but the concept was "at least you knew you had an error
and you consciously decided to pass it up the chain."
Click to expand...

Unless this was corrected in the last year it still does it (the last
version of Java I worked with was 1.4.1). And there were two ways to deal
with it.

a) When you declared a method you could add a throws clause.
i.e.

void myFunction() extends mybaseclass throws IOException {}

b) you could use try catch

void myFunction() extends mybaseclass
{
try {
...
} catch (IOException e) {}
}

the primary difference is that the latter catches it and does what it wants.
The first though is great for inherited classes because the inherited class
knows from the start all the exceptions that can be thrown during the life
of the method execution.

Some see it as a pain, I liked it because I never had runtime errors, and if
I did, it was because I wanted to, not because I didn't know.

Relevance... 0... just wanted to talk. =)
 
The very lack of anything being there can lead
to confusion.
Click to expand...

I guess "Option REALLY Explicit" is what we need ;) In my little world, this
would mean (among other things)

1) Option Strict On
2) No default constructors
3) No class, method or field definitions without a scope modifier
4) No optional parameters (use overloading instead)

Just my 2c

Trev.
 
I'm gonna disagree on the optional parameters part. =) I always liked that
feature. =) Sure, its just as easy to copy and paste your method signiture
and add a paramter, and then call the one of the other overloaded methods...

but look how much time that took... just to type the idea... when I can
just do

public mySub (param1 as integer, optional param2 as integer =0)

thats just super. =)

-CJ
 
Thanks for the clarification. I recently read Bruce Eckel's book on Java
and there was a discussion. He is proposing that checked exceptions are
probably not necessary, in principal because people end up trying to work
around it instead.

I agree that in principal having to deal with it (regardless of whether
you've done it well) means you cannot be clueless about the possibility of
the exception happening.

Tom
 
public mySub (param1 as integer, optional param2 as integer =0)
thats just super. =)
Click to expand...

Yes, but it's not CLS compliant ;( I gave up on optional parametes because
more often than not I couldn't find a reliable way of detecting whether a
parameter was passed or not. I wasn't over the moon with MSDN's
recommendation to "set an unlikley value as the default" either.

Trev.
 
Trev,
Oh! I follow you.

I can see some merit in for the IDE to do it to help maintain a "shop
standard", as long as it was configurable.

You could possible create a macro that automatically added the default
constructor for you, that either looked for when you added a new class or
that you just press a button to add the default constructor?

Hope this helps
Jay
 
Cheers Jay, I'll have a look.

Is there one for "Option Bugs Off" ;) - that one really bothers me!

Trev.
 
You could possible create a macro that
automatically added the default
constructor for you, that either looked
for when you added a new class or
that you just press a button to add the default constructor?
Click to expand...

Yeah, I suppose that would do the job. ATM, I'm just using the handy feature
of the toolbar that lets you drag & drop pieces of text onto it. I've added
code snippets for most common things that I do (class templates, method and
property templates etc). I know there's plugins that allow you to do this,
but haven't gotten around to investigating them.

Cheers,

Trev.
 
Back
Top