I'm writing a family of classes which all inherit most of their methods and
code (including constructors) from a single base class. When attempting to
instance one of the derived classes using parameters, I get CS1501 (no method
with X arguments). Here's a simplified example which mimics the
circumstances:
namespace InheritError {
// Random base class.
public class A {
protected int i;
// Random contructor w/o parameters.
public A() {
this.i = 5;
}
// Random contructor *with* parameters.
public A(int initial) {
this.i = initial;
}
}
// Random derived class.
public class B : A {
public int Inc() {
// Instantiation of derived class using base class constructor w/
parameters.
return new B(this.i + 1); // CS1501
}
}
}
(I'm not normally calling the constructor from inside one of the class'
methods; that's just to make the code more compact.)
How can I make the derived classes correctly inherit the base constructors?
I'm aware that setting up "public B() : base()" constructors would allow
these calls to work, but adding a half-dozen different codeless constructors
to each of about two dozen derived classes will make the code both uglier and
harder to work with. e.g. Having to change twenty-five source files if I
need to add a new constructor instead of just one is just plain silly when
twenty-four of them contain no code in the constructors, plus I will be
making these classes available to outside developers and accidental omission
of one or more constructors could produce some difficult-to-locate bugs.
Surely there's another way to do this?
45  6292 
You cannot because, unbeknownst to you as a developer, the default
constructor is always called for all parent objects.
"Ben Blank" <Be******@discussions.microsoft.com> wrote in message
news:B6**********************************@microsof t.com... I'm writing a family of classes which all inherit most of their methods
and code (including constructors) from a single base class. When attempting
to instance one of the derived classes using parameters, I get CS1501 (no
method with X arguments). Here's a simplified example which mimics the
circumstances:
namespace InheritError {
// Random base class.
public class A {
protected int i;
// Random contructor w/o parameters.
public A() {
this.i = 5;
}
// Random contructor *with* parameters.
public A(int initial) {
this.i = initial;
}
}
// Random derived class.
public class B : A {
public int Inc() {
// Instantiation of derived class using base class constructor w/
parameters.
return new B(this.i + 1); // CS1501
}
}
}
(I'm not normally calling the constructor from inside one of the class'
methods; that's just to make the code more compact.)
How can I make the derived classes correctly inherit the base
constructors? I'm aware that setting up "public B() : base()" constructors would allow
these calls to work, but adding a half-dozen different codeless
constructors to each of about two dozen derived classes will make the code both uglier
and harder to work with. e.g. Having to change twenty-five source files if I
need to add a new constructor instead of just one is just plain silly when
twenty-four of them contain no code in the constructors, plus I will be
making these classes available to outside developers and accidental
omission of one or more constructors could produce some difficult-to-locate bugs.
Surely there's another way to do this?
"Peter Rilling" wrote: You cannot because, unbeknownst to you as a developer, the default
constructor is always called for all parent objects.
I'm afraid I don't take the meaning of your remark. I'm *trying* to get the
parent class' constructors called, but that's not happening.
Use base syntax.
public MyClass() : base()
{
}
--
William Stacey, MVP http://mvp.support.microsoft.com
"Ben Blank" <Be******@discussions.microsoft.com> wrote in message
news:02**********************************@microsof t.com... "Peter Rilling" wrote: You cannot because, unbeknownst to you as a developer, the default
constructor is always called for all parent objects.
I'm afraid I don't take the meaning of your remark. I'm *trying* to get
the parent class' constructors called, but that's not happening.
Sorry, I misread the question. Let me look it over closer and see if I can
suggest anything.
"Ben Blank" <Be******@discussions.microsoft.com> wrote in message
news:02**********************************@microsof t.com... "Peter Rilling" wrote: You cannot because, unbeknownst to you as a developer, the default
constructor is always called for all parent objects.
I'm afraid I don't take the meaning of your remark. I'm *trying* to get
the parent class' constructors called, but that's not happening.
On Fri, 10 Dec 2004 10:03:03 -0800, Ben Blank wrote: I'm afraid I don't take the meaning of your remark. I'm *trying* to get the
parent class' constructors called, but that's not happening.
See section 3.4 of the C# language specification:
"Members of a type are either declared in the type or inherited from the
base class of the type. When a type inherits from a base class, all members
of the base class, except instance constructors, destructors and static
constructors, become members of the derived type. The declared
accessibility of a base class member does not control whether the member is
inherited ¡X inheritance extends to any member that is not an instance
constructor, static constructor, or destructor."
If you want to call the parent class constructor, you are going to need an
object of that type, not the derived class.
--
Tom Porterfield
I'm afraid that you're out of luck -- you'll have to either copy forward the
constructor declarations and call base (just as you suggested), or you will
have to provide a separate "Init" method that must be called after the
constructor.
If you scan the groups, you will see that this question has been asked a few
times before. It might be a little enlightening, as there are arguments
both for and against allowing constructor inheritance. Personally, I side
with you. If you are creating anything of any depth, the current layout
renders parameterized constructors virtually worthless. In fact, failure to
reimplement a constructor and call base is probably in our top 3 most common
quality defects (or it was until we went back and began factoring out
parameterized constructors altogether). At our shop, we ended up updating
our guidelines to strongly discourage the use of parameterized constructors.
"Ben Blank" <Be******@discussions.microsoft.com> wrote in message
news:02**********************************@microsof t.com... "Peter Rilling" wrote: You cannot because, unbeknownst to you as a developer, the default
constructor is always called for all parent objects.
I'm afraid I don't take the meaning of your remark. I'm *trying* to get
the
parent class' constructors called, but that's not happening.
"Tom Porterfield" wrote: ... except instance constructors, destructors and static constructors ...
Well, shoot. I was really hoping that wasn't going to be the answer.
Is there another way to 'force' (or specify) inheritance? I know that
CodeDOM can generate code, but it was complex enough at first glance that I
didn't pursue it further at the time. Do you think it would provide a way to
automate adding explicit constructors? I'd still like to find a way to
preserve the readability and maintainability of the derived classes, if it's
possible.
"J.Marsch" wrote: I'm afraid that you're out of luck -- you'll have to either copy forward the
constructor declarations and call base (just as you suggested), or you will
have to provide a separate "Init" method that must be called after the
constructor.
If you scan the groups, you will see that this question has been asked a few
times before. It might be a little enlightening, as there are arguments
both for and against allowing constructor inheritance. Personally, I side
with you. If you are creating anything of any depth, the current layout
renders parameterized constructors virtually worthless. In fact, failure to
reimplement a constructor and call base is probably in our top 3 most common
quality defects (or it was until we went back and began factoring out
parameterized constructors altogether). At our shop, we ended up updating
our guidelines to strongly discourage the use of parameterized constructors.
I effectively have an Init method already, but was trying to collapse "x =
new y();x.Init(z)" into "x = new y(z)". I suppose that if I can't find
another way, I can always make those Init methods return the object itself,
so "x = new y().Init(z)" possible, at least. Slightly less elegant, but
almost as good.
Peter Rilling <pe***@nospam.rilling.net> wrote: You cannot because, unbeknownst to you as a developer, the default
constructor is always called for all parent objects.
Not it's not. The parameterless constructor is only called if you don't
specify a different constructor to call.
However, you can't inherit constructors for other reasons.
See http://www.pobox.com/~skeet/csharp/constructors.html
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Ctors are not inherited, but they can be called by the derived class:
class B : A
{
public B(int i) : base(i) {}
public B Inc() { return new B(i + 1); }
}
--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
"Ben Blank" <Be******@discussions.microsoft.com> wrote in message
news:B6**********************************@microsof t.com... I'm writing a family of classes which all inherit most of their methods
and code (including constructors) from a single base class. When attempting
to instance one of the derived classes using parameters, I get CS1501 (no
method with X arguments). Here's a simplified example which mimics the
circumstances:
namespace InheritError {
// Random base class.
public class A {
protected int i;
// Random contructor w/o parameters.
public A() {
this.i = 5;
}
// Random contructor *with* parameters.
public A(int initial) {
this.i = initial;
}
}
// Random derived class.
public class B : A {
public int Inc() {
// Instantiation of derived class using base class constructor w/
parameters.
return new B(this.i + 1); // CS1501
}
}
}
(I'm not normally calling the constructor from inside one of the class'
methods; that's just to make the code more compact.)
How can I make the derived classes correctly inherit the base
constructors? I'm aware that setting up "public B() : base()" constructors would allow
these calls to work, but adding a half-dozen different codeless
constructors to each of about two dozen derived classes will make the code both uglier
and harder to work with. e.g. Having to change twenty-five source files if I
need to add a new constructor instead of just one is just plain silly when
twenty-four of them contain no code in the constructors, plus I will be
making these classes available to outside developers and accidental
omission of one or more constructors could produce some difficult-to-locate bugs.
Surely there's another way to do this?
"J.Marsch" wrote: It might be a little enlightening, as there are arguments
both for and against allowing constructor inheritance. Personally, I side
with you. If you are creating anything of any depth, the current layout
renders parameterized constructors virtually worthless.
Perhaps what the language needs are, e.g., "inherit" and "dontinherit"
keywords. While I'm not sure I disagree with the argument for making
constructors non-inherited by default, completely omitting that functionality
is simply monstrous in terms of maintanability and sharability of code.
Allowing the author of the base class to mark constructors as inherited or
non-inherited (Possibly even other methods, too? That's a debate for wiser
heads than mine.) would seem to bridge the gap between consistency and
flexibility.
In any event, I appreciate the time and effort put into this by everyone who
has responded. It's been a very enlightening discussion.
Ben Blank <Be******@discussions.microsoft.com> wrote: "J.Marsch" wrote: It might be a little enlightening, as there are arguments
both for and against allowing constructor inheritance. Personally, I side
with you. If you are creating anything of any depth, the current layout
renders parameterized constructors virtually worthless.
Perhaps what the language needs are, e.g., "inherit" and "dontinherit"
keywords. While I'm not sure I disagree with the argument for making
constructors non-inherited by default, completely omitting that functionality
is simply monstrous in terms of maintanability and sharability of code.
Allowing the author of the base class to mark constructors as inherited or
non-inherited (Possibly even other methods, too? That's a debate for wiser
heads than mine.) would seem to bridge the gap between consistency and
flexibility.
In any event, I appreciate the time and effort put into this by everyone who
has responded. It's been a very enlightening discussion.
It shouldn't be up to the base class though - that doesn't know what
the derived class needs. If a derived class absolutely *must* have a
certain parameter, why should the base class be able to say that it
doesn't care and so the derived class shouldn't either?
*Possibly* a derived class should be able to say "I'll inherit all
constructors" but that would only really be appropriate (IMO) if you
don't need *any* code to run in the derived class's constructor.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Does anyone know of an O-O language that allows for constructor
inheritance? C++ doesn't, Java doesn't, and C# doesn't. Has anyone had
practical experience with it and could say how well or how badly it
plays out?
"Jon Skeet [C# MVP]" wrote: It shouldn't be up to the base class though - that doesn't know what
the derived class needs. If a derived class absolutely *must* have a
certain parameter, why should the base class be able to say that it
doesn't care and so the derived class shouldn't either?
*Possibly* a derived class should be able to say "I'll inherit all
constructors" but that would only really be appropriate (IMO) if you
don't need *any* code to run in the derived class's constructor.
That depends on the purpose of the base class and whether it expects to be
derived from; perhaps it is the base class which *must* have the particular
parameter -- and handles all the logic for it -- even when derived from.
I'll admit my thinking here is oriented toward abstact classes (as that's the
situation which inspired my original question), where the base class is a
vehicle for the derived classes. If the base class wholly defines the
structure and purpose of the derived classes, it makes little sense to
require each derivation to "sign off" on that structure when it has no say in
it.
Take, for the sake of argument, an abstract class Car. Now, you can't
instance Car directly because it lacks the details neccesary -- wheels,
seats, a manufacturer, etc. -- which are all described in Car but defined in
its derived classes. Then you have derived classes ToyotaCorolla, DodgeRam,
and FordEscort. It makes no sense to require each derived class of Car to
describe how a Driver is installed (no pun intended), yet you cannot create a
"new DodgeRam(myDriver)" without explicity telling DodgeRam to inherit Car's
constructor. The *option* should be there, of course, in case a particular
type of Car needs to do something special with Driver, but the core handling
will always be the same (i.e. " : base(Driver)" should *always* be present)
and the requirement to state it explicitly when there *is* no special
handling actually makes the code harder to work with. If someone creates a
new class JeepWrangler but forgets to add "public JeepWrangler(Driver
newDriver) : base(newDriver) {}" to his code, the omission may not even be
noticed until someone tries to create a new instance with the Driver already
in it. And unless the author of JeepWrangler is familiar with this whole
mess, he's going to be left scratching his head, as have so many others.
I'm not necessary arguing in favor of "inherit"/"dontinherit" -- that is
simply my knee-jerk reaction to the problem and I've no doubt there could be
serious problems with such a scheme -- but I do feel there should be some
manner of allowing base classes this kind of control and derived classes this
flexibility.
Bruce Wood <br*******@canada.com> wrote: Does anyone know of an O-O language that allows for constructor
inheritance? C++ doesn't, Java doesn't, and C# doesn't. Has anyone had
practical experience with it and could say how well or how badly it
plays out?
I believe SmallTalk does, but its whole type system is somewhat
different, IIRC. (I've never actually learned ST myself, but it's been
mentioned in similar threads.)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Bruce Wood wrote: Does anyone know of an O-O language that allows for constructor
inheritance? C++ doesn't, Java doesn't, and C# doesn't. Has anyone had
practical experience with it and could say how well or how badly it
plays out?
Delphi ( for win32 ) has virtual constructors.
And yes, it is very useful for the situations / app architectures as
described in the thread above.
Interestingly, Anders H was the main language architect of Delphi as
well as being one of the major designers of C#, so its not as if
virtual constructors were just overlooked, I would imagine that its
exclusion was quite deliberate, I don't now why though.
Regards Tim.
Yep, Delphi allowed inherited constructors. Having worked on that side of
the fence, I can say that the cases where that helped seemed to far
outnumber the cases where it hurt.
"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com... Does anyone know of an O-O language that allows for constructor
inheritance? C++ doesn't, Java doesn't, and C# doesn't. Has anyone had
practical experience with it and could say how well or how badly it
plays out?
Ben, I think that you and I have about the same position on this one. There
are definitely compelling arguments on both sides of the fence. It's been a
little over a year since we first encountered this issue. In hindsight, I
have to say that while there were a few cases where we needed to hide a
constructor, in the majority of cases the lack of constructor inheritance
has hurt more than helped. I'm sure that there are others out there who
would have exactly the opposite results, so I suppose that perhaps the
decision really is a wash.
"Ben Blank" <Be******@discussions.microsoft.com> wrote in message
news:25**********************************@microsof t.com... "Jon Skeet [C# MVP]" wrote: It shouldn't be up to the base class though - that doesn't know what
the derived class needs. If a derived class absolutely *must* have a
certain parameter, why should the base class be able to say that it
doesn't care and so the derived class shouldn't either?
*Possibly* a derived class should be able to say "I'll inherit all
constructors" but that would only really be appropriate (IMO) if you
don't need *any* code to run in the derived class's constructor.
That depends on the purpose of the base class and whether it expects to be
derived from; perhaps it is the base class which *must* have the
particular
parameter -- and handles all the logic for it -- even when derived from.
I'll admit my thinking here is oriented toward abstact classes (as that's
the
situation which inspired my original question), where the base class is a
vehicle for the derived classes. If the base class wholly defines the
structure and purpose of the derived classes, it makes little sense to
require each derivation to "sign off" on that structure when it has no say
in
it.
Take, for the sake of argument, an abstract class Car. Now, you can't
instance Car directly because it lacks the details neccesary -- wheels,
seats, a manufacturer, etc. -- which are all described in Car but defined
in
its derived classes. Then you have derived classes ToyotaCorolla,
DodgeRam,
and FordEscort. It makes no sense to require each derived class of Car to
describe how a Driver is installed (no pun intended), yet you cannot
create a
"new DodgeRam(myDriver)" without explicity telling DodgeRam to inherit
Car's
constructor. The *option* should be there, of course, in case a
particular
type of Car needs to do something special with Driver, but the core
handling
will always be the same (i.e. " : base(Driver)" should *always* be
present)
and the requirement to state it explicitly when there *is* no special
handling actually makes the code harder to work with. If someone creates
a
new class JeepWrangler but forgets to add "public JeepWrangler(Driver
newDriver) : base(newDriver) {}" to his code, the omission may not even be
noticed until someone tries to create a new instance with the Driver
already
in it. And unless the author of JeepWrangler is familiar with this whole
mess, he's going to be left scratching his head, as have so many others.
I'm not necessary arguing in favor of "inherit"/"dontinherit" -- that is
simply my knee-jerk reaction to the problem and I've no doubt there could
be
serious problems with such a scheme -- but I do feel there should be some
manner of allowing base classes this kind of control and derived classes
this
flexibility.
Ravichandran J.V. <jv************@yahoo.com> wrote: A simple thumb rule in .Net is the like constructor will invoke its like
base contructor and all instantiation will go up all the way to the base
System.Object class.
I don't see how that's relevant to inheritance of constructors though.
Out of interest, do you still maintain that constructors are inherited
in derived classes?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"J.Marsch" <je****@ctcdeveloper.com> wrote in message
news:Ox**************@TK2MSFTNGP14.phx.gbl... Yep, Delphi allowed inherited constructors. Having worked on that side of
the fence, I can say that the cases where that helped seemed to far
outnumber the cases where it hurt.
Ah, but that's not how features are weighed in language design (or at
least not in C++ & C#). It balancing "how difficult is the workaround?" (in
this case, not very) versus "How much damage could it do?" (in this case, a
lot).
--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
Ravichandran J.V. <jv************@yahoo.com> wrote: I am glad to know you still remember me.
Oh certainly.
" don't see how that's relevant to inheritance of constructors though. "
There you go again.
There I go again what? Could you point out the relevance of the fact
that constructor chaining happens to constructor inheritance? The two
are pretty much independent concepts as far as I can see - you could
have constructor inheritance without constructor chaining, and you can
have constructor chaining without constructor inheritance (as indeed we
have).
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi Jon,
I have copied/pasted the OP's first query below in case you have lost
track of it.
"When attempting to instance one of the derived classes using
parameters, I get CS1501 (no method with X arguments). "
Let me give you an example of my own in the way constructors work in
inheritance that also demonstrates why the OP got the error.
public class Base
{
public Base(int i)
{
}
}
public class Derived:Base
{
public Derived(int x)
{
}
}
public class Test
{
public static void Main()
{
Derived ob=new Derived(10);
}
}
When "Derived ob=new Derived(10);" is executed in the Test class, the
compiler will look for a default constructor to overload the derived's
constructor right ? Plus it also looks for a default constructor so as
to initiate the base System.Object's constructor as only like
constructors can invoke like constructors, right? But, because there is
no base default constructor and the System.Object constructor cannot be
invoked, the above example code will generate an error, right? The error
can be rectified by simply providing for a default constructor in the
base class or by invoking the base' overloaded constructor from the
Derived's overloaded constructor as below
public class Derived:Base
{
public Derived(int x):base(x)
{
}
}
I am sure with this kind of example the OP would find it easier to
understand what it means when working with constructors. Most probably,
the OP was initializing an object and sending some value to a class
where no matching constructor was present for the compiler. Something
like,
Derived ob=new Derived(12,12);
because the Derived class has only one overloaded constructor that being
one with a single int parameter.
"Could you point out the relevance of the fact
that constructor chaining happens to constructor inheritance?"
I do not understand what you mean by chaining and inheritance. But at a
guess, my above answer should be sufficient as an answer to your
question.
with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Lets get back to basics here. And also lets forget about field initializers for the time being and concentrate purely on constructors. When you have a class heirarchy and you create an instance of the most dervied class all of the base classes (direct and indirect) must also have a constructor called to allow them to initialize their own state. So take this example
class MyBase
{
public MyBase()
{
Console.WriteLine("MyBase.ctor");
}
}
class Derived : MyBase
{
public Derived()
{
Console.WriteLine("Derived.ctor");
}
}
class MoreDerived : Derived
{
public MoreDerived()
{
Console.WriteLine("MoreDerived.ctor");
}
}
MoreDerived d = new MoreDerived();
This will print out
MyBase.ctor
Derived.ctor
MoreDerived.ctor
Notice they execute in base ->derived order. Also System.Object's constructor will execute first it just doesn't print out anything.
Now, if you don't supply a constructor in your code, the C# compiler will generate a defauklt constructor for you which simply calls the base class constructor. The problem comes when you declare a non-default constructor in a base class but do not provide a default constructor. In this case the compiler does not generate one for you (unlike C++) so now there is a problem. There is no way for the compiler to emit a call to the base class constructor as it has no idea what parameters to pass to the base class. This is why you have to explicitly specify how you want the base class contructor invoked using the base keyword. So lets revisit the previous example - this time we'll change the Dervied class to only have a non-default constructor and remove the explcit constructor from MyBase:
class MyBase
{
}
class Derived : MyBase
{
public Derived(int x)
{
Console.WriteLine("Derived.ctor");
}
}
class MoreDerived : Derived
{
public MoreDerived()
{
Console.WriteLine("MoreDerived.ctor");
}
}
MoreDerived d = new MoreDerived();
This will not compile as the compiler does not know how to invoke the Derived constructor. We could add a default constructor to Dervived, but it may make no sense to have a constructor that takes no parameters for that class. So instead we state explicitly how we want the constructor in Derived to be invoked:
class MoreDerived : Derived
{
public MoreDerived()
: base(42)
{
Console.WriteLine("MoreDerived.ctor");
}
}
This now compiles and the following will execute when an instance of MoreDerived is created
System.Object default ctor
MyBase compiler generated default ctor
Derived(int x) ctor
MoreDerived default ctor
So when you say
"the compiler will look for a default constructor to overload the derived's constructor right ?"
I can't see how this fits into the mechanism of how construction works at all.
Regards
Richard Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk
Hi Jon,
I have copied/pasted the OP's first query below in case you have lost
track of it.
"When attempting to instance one of the derived classes using
parameters, I get CS1501 (no method with X arguments). "
Let me give you an example of my own in the way constructors work in
inheritance that also demonstrates why the OP got the error.
Ravichandran J.V. <jv************@yahoo.com> wrote: I have copied/pasted the OP's first query below in case you have lost
track of it.
"When attempting to instance one of the derived classes using
parameters, I get CS1501 (no method with X arguments). "
Let me give you an example of my own in the way constructors work in
inheritance that also demonstrates why the OP got the error.
I'm perfectly well aware of why the OP got the error. (See
http://www.pobox.com/~skeet/csharp/constructors.html for my own
explanation.)
public class Base
{
public Base(int i)
{
}
}
public class Derived:Base
{
public Derived(int x)
{
}
}
public class Test
{
public static void Main()
{
Derived ob=new Derived(10);
}
}
When "Derived ob=new Derived(10);" is executed in the Test class, the
compiler will look for a default constructor to overload the derived's
constructor right ?
No. It will look for a parameterless constructor in the base class, as
there is no explicit call to another constructor in either the base
class or the derived class.
Plus it also looks for a default constructor so as
to initiate the base System.Object's constructor as only like
constructors can invoke like constructors, right?
Not sure what you mean by that.
But, because there is
no base default constructor and the System.Object constructor cannot be
invoked, the above example code will generate an error, right?
The System.Object constructor is irrelevant here.
The error
can be rectified by simply providing for a default constructor in the
base class or by invoking the base' overloaded constructor from the
Derived's overloaded constructor as below
The base doesn't have any overloaded constructors - it just has a
constructor.
My point is that constructor chaining is independent from constructor
inheritance.
public class Derived:Base
{
public Derived(int x):base(x)
{
}
}
I am sure with this kind of example the OP would find it easier to
understand what it means when working with constructors.
Not really. The OP seemed to understand what was going on, and just
wanted to know whether or not there was a way of inheriting
constructors, which there isn't.
<snip>
"Could you point out the relevance of the fact
that constructor chaining happens to constructor inheritance?"
I do not understand what you mean by chaining and inheritance. But at a
guess, my above answer should be sufficient as an answer to your
question.
Nope. Constructor chaining is where one constructor calls another
(either in the same type or the base type). It's mandatory in C#, but
is completely separate from the question of whether constructors are
inherited (which they aren't).
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
I won't argue (very strongly) against the merits of the C# decision -- there
is a very good supporting argument. What I can say is that I first stumbled
on to the constructor issue a little over a year ago. At the time, I was
nonplussed. It didn't work the way that I expected it to, but I understood
the argument. Today, I can balance that view with a little bit of
hindsight. I can easily say that (in my own development environment), not
having inheritable constructors has caused more damage and more pain (and I
mean bugs here, not just "oooh, I have to type") than having them would
have.
Again, your ability to agree with that statement will vary with your
situation -- it certainly will not be true for everyone. All too true here,
though.
"James Curran" <Ja*********@mvps.org> wrote in message
news:e%****************@TK2MSFTNGP12.phx.gbl... "J.Marsch" <je****@ctcdeveloper.com> wrote in message
news:Ox**************@TK2MSFTNGP14.phx.gbl... Yep, Delphi allowed inherited constructors. Having worked on that side
of
the fence, I can say that the cases where that helped seemed to far
outnumber the cases where it hurt.
Ah, but that's not how features are weighed in language design (or at
least not in C++ & C#). It balancing "how difficult is the workaround?"
(in
this case, not very) versus "How much damage could it do?" (in this case,
a
lot).
--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
J.Marsch <je****@ctcdeveloper.com> wrote: I won't argue (very strongly) against the merits of the C# decision -- there
is a very good supporting argument. What I can say is that I first stumbled
on to the constructor issue a little over a year ago. At the time, I was
nonplussed. It didn't work the way that I expected it to, but I understood
the argument. Today, I can balance that view with a little bit of
hindsight. I can easily say that (in my own development environment), not
having inheritable constructors has caused more damage and more pain (and I
mean bugs here, not just "oooh, I have to type") than having them would
have.
Were those bugs from types which were created with a "surprising"
constructor due to an overload which you didn't expect (eg going for a
declared constructor taking an object parameter rather than a base
class's constructor taking a string parameter) or due to reflection?
It's the kind of thing which I can't imagine creating that many more
bugs.
I do think it would help if VS.NET had better tools for creating
"dummy" constructors, in the same way that Eclipse has - in Eclipse's
Java tooling you can just check which of the base class's constructors
you want to provide in the subclass.
In terms of the language decision, I think it's the right way round,
personally. An alternative would be to make it both the base class
*and* the derived class's choice, so that both of them have to say
"yes" before constructors are inherited.
(Personally, virtually the only time I wish I could have inherited
constructors is with exceptions.)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"I'm perfectly well aware of why the OP got the error. (See http://www.pobox.com/~skeet/csharp/constructors.html for my own
explanation.)"
I am not so sure looking at your replies. You probably started off from
the middle and forgot the original post, is what I could make out from
your reply. But I am sure you will not agree! :)
"No. It will look for a parameterless constructor in the base class, as
there is no explicit call to another constructor in either the base
class or the derived class."
Jon, I don't see why you have to disagree on everything. A parameterless
constructor was so called in the C++ days; nowadays it is called the
default constructor. I am sure you will have an argument to this as
well. Plus it also looks for a default constructor so as
to initiate the base System.Object's constructor as only > like
constructors can invoke like constructors, right?
"Not sure what you mean by that."
What I mean is, what you probably have written in your own article. Any
constructor, at the time of instantiation, goes all the way up the
object hierarchy till system.object.
But, because there is no base default constructor and the
System.Object constructor cannot be invoked, the above >example code
will generate an error, right?
"The System.Object constructor is irrelevant here."
If you talk of "constructor chaining" (as you so name it, quite kinkily
if I may say), I don't see how you can leave the base System.Object
class as without it you cannot talk about constructor creation in
inheritance (and I DO NOT MEAN constructor inheritance.).
If you don't agree, I request you to kindly create two classes (let me
call them Class1 and Class2). Have an 'int' public member in Class1.
Create an instance of Class2 and using this instance try to
Console.Write the 'int' member with the instance of Class2. Please
notice the error and then we can debate on whether System.Object is
relevant here or not.
The error can be rectified by simply providing for a >default
constructor in the base class or by invoking the >base' overloaded
constructor from the Derived's overloaded >constructor as below
"The base doesn't have any overloaded constructors - it just has a
constructor."
"My point is that constructor chaining is independent from constructor
inheritance."
Unlike you, I agree that the two are entirely different but I neither
contested on this issue nor was this issue introduced by anyone nor by
me at all. You introduced both the terms yourself.
You have a way of introducing your own issue and blaming me that I
disagree on it. If you do wish to prove your own point or make me
understand, please do provide an article on the web and I will be glad
to go through it.
"Nope. Constructor chaining is where one constructor calls another
(either in the same type or the base type). "
Again, I am not contesting on "Chaining" or "constructor inheritance".
What do you mean by (either in the same type or the base type)?
If the Derived class has an overloaded constructor but the base does not
have a default constructor, then creating a "constructor of the same
type" will not work because "chaining" does not work just like that. You
have to explain how the "chaining" actually works, which is what I did
with that example.
Again, the following is the OP's post. Please do explain why should a
query be posted if it was not for a clarification of the error of
passing a parameter to a class that does not have an overloaded
constructor. This confusion of the OP obviously meant that a little
extra help was required by the OP and hence, I posted my own code to
illustrate.
The original OP's post is
-------------------------
"When attempting to instance one of the derived classes using
parameters, I get CS1501 (no method with X arguments). "
----------------------------------------------------------
"Not really. The OP seemed to understand what was going on, and just
wanted to know whether or not there was a way of inheriting
constructors, which there isn't.".
You can't simply disagree on everything, my dear Watson!:)The OP uses
the words, "get" in ("I get CS1501"). Anyone who was aware of what was
going on would not enumerate an error if all he wanted to know was
whether constructors or inherited or not.
So, please do agree that you did not read the OP's original post at all
but picked up the thread from the middle.
with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Ravichandran J.V. <jv************@yahoo.com> wrote: "I'm perfectly well aware of why the OP got the error. (See
http://www.pobox.com/~skeet/csharp/constructors.html for my own
explanation.)"
I am not so sure looking at your replies. You probably started off from
the middle and forgot the original post, is what I could make out from
your reply. But I am sure you will not agree! :)
"No. It will look for a parameterless constructor in the base class, as
there is no explicit call to another constructor in either the base
class or the derived class."
Jon, I don't see why you have to disagree on everything. A parameterless
constructor was so called in the C++ days; nowadays it is called the
default constructor. I am sure you will have an argument to this as
well.
Well, the spec is slightly unclear. I find it helpful to use "default
constructor" to mean a constructor which is supplied when no other ones
are, and "parameterless constructor" to mean a constructor which takes
no parameters. However, what I was disagreeing with wasn't your
parameterless/default terminology as "the compiler will look for a
default constructor to overload the derived's constructor right ?"
In what way is the compiler trying to overload the derived class's
constructor? What do you even mean by that?
Plus it also looks for a default constructor so as
to initiate the base System.Object's constructor as only > like
constructors can invoke like constructors, right?
"Not sure what you mean by that."
What I mean is, what you probably have written in your own article. Any
constructor, at the time of instantiation, goes all the way up the
object hierarchy till system.object.
But where does the "as only like constructors can invoke like
constructors" part come in?
But, because there is no base default constructor and the
System.Object constructor cannot be invoked, the above >example code
will generate an error, right?
"The System.Object constructor is irrelevant here."
If you talk of "constructor chaining" (as you so name it, quite kinkily
if I may say), I don't see how you can leave the base System.Object
class as without it you cannot talk about constructor creation in
inheritance (and I DO NOT MEAN constructor inheritance.).
Absolutely - and constructor creation in inheritance is off the topic
of constructor inheritance, which is the topic of the thread (see the
subject line). The System.Object constructor is also totally irrelevant
to the derived class's constructor, as only the base class's
constructors are considered - you can't "skip" the base class, so the
System.Object constructor is only relevant to the base class.
If you don't agree, I request you to kindly create two classes (let me
call them Class1 and Class2). Have an 'int' public member in Class1.
Create an instance of Class2 and using this instance try to
Console.Write the 'int' member with the instance of Class2. Please
notice the error and then we can debate on whether System.Object is
relevant here or not.
It's not relevant to constructor inheritance - the topic of the thread.
The error can be rectified by simply providing for a >default
constructor in the base class or by invoking the >base' overloaded
constructor from the Derived's overloaded >constructor as below
"The base doesn't have any overloaded constructors - it just has a
constructor."
"My point is that constructor chaining is independent from constructor
inheritance."
Unlike you, I agree that the two are entirely different but I neither
contested on this issue nor was this issue introduced by anyone nor by
me at all. You introduced both the terms yourself.
No, you introduced the business of constructor chaining (whatever you
want to call it) into the thread, which (as the subject suggests) was
the original topic of the thread. Your original post in the thread had
*nothing* to do with constructor inheritance, and *everything* to do
with constructor chaining. Here it is:
<quote>
A simple thumb rule in .Net is the like constructor will invoke its
like base contructor and all instantiation will go up all the way to
the base System.Object class.
</quote>
Now, please explain the relevance of that to constructor inheritance.
You have a way of introducing your own issue and blaming me that I
disagree on it. If you do wish to prove your own point or make me
understand, please do provide an article on the web and I will be glad
to go through it.
In what way did I introduce the issue of constructor chaining? See your
original post on the thread, quoted above!
"Nope. Constructor chaining is where one constructor calls another
(either in the same type or the base type). "
Again, I am not contesting on "Chaining" or "constructor inheritance".
What do you mean by (either in the same type or the base type)?
That one constructor can call another in the same class (using
this(...) instead of base(...)).
If the Derived class has an overloaded constructor but the base does not
have a default constructor, then creating a "constructor of the same
type" will not work because "chaining" does not work just like that. You
have to explain how the "chaining" actually works, which is what I did
with that example.
Given your article on constructors on Devdex, I'm not sure you entirely
understand constructor chaining. (In particular the claim that "To be
able to access the base class' overloaded constructors, you need to
implement (it is similar to overriding although the terminology is
different in this case) the base class' default constructor".)
Again, the following is the OP's post. Please do explain why should a
query be posted if it was not for a clarification of the error of
passing a parameter to a class that does not have an overloaded
constructor. This confusion of the OP obviously meant that a little
extra help was required by the OP and hence, I posted my own code to
illustrate.
Um, no. By the time you posted, the OP's question had been answered by
several people, who all understood that the OP was basically asking why
constructor inheritance wasn't in C#, and whether there was some way of
enabling it that he'd missed.
The original OP's post is
-------------------------
"When attempting to instance one of the derived classes using
parameters, I get CS1501 (no method with X arguments). "
----------------------------------------------------------
No. That's a very small *part* of the post. Please read the whole
thing, and you'll see that the OP knew why he was getting the error,
but wanted to know if C# had any way round it without creating lots of
"dummy" constructors.
"Not really. The OP seemed to understand what was going on, and just
wanted to know whether or not there was a way of inheriting
constructors, which there isn't.".
You can't simply disagree on everything, my dear Watson!:)The OP uses
the words, "get" in ("I get CS1501"). Anyone who was aware of what was
going on would not enumerate an error if all he wanted to know was
whether constructors or inherited or not.
See my previous paragraph - he was aware of what was going on, and was
asking whether there was any way round the issue other than the way he
already knew about.
So, please do agree that you did not read the OP's original post at all
but picked up the thread from the middle.
LOL - you should really read the other replies in the thread, which all
*did* understand what the OP was talking about. (Hence the productive
discussion that the OP and I had elsewhere in the thread.)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
> (Personally, virtually the only time I wish I could have inherited constructors is with exceptions.)
Yah, that one is huge.
Were those bugs from types which were created with a "surprising"
constructor due to an overload which you didn't expect (eg going for a
declared constructor taking an object parameter rather than a base
class's constructor taking a string parameter) or due to reflection?
A little of both. We are building a development framework, and we expect
people working at the application level to be inheriting our base classes.
One of our most common quality problems occurs when someone (usually a
downlevel developer -- an internal person consuming our tools) adds the
constructor but fails to call :base(x), such that the object never fully
initializes.
Note on that: for a lot of classes, you would get compile error on this
one, but some of our classes need to support COM Interop, so they support a
parameterless constructor, expecting a follow-up an initialize method as an
alternative method of construction. In those cases, since a parameterless
constructor is present, you don't get a compile error if you fail to call
base(x), but since the calling code is passing the param, it thinks that
initialization is handled. We don't often have to change the parameter that
is passed to a ctor, usually the developer is just trying to add some
initialization code, so define the ctor and fail to follow up with base(x).
I'm sure you can see how this situation would push us in the direction of
just always using parameterless constructors with follow-up calls to
initialize.
Or, more commonly, they fail to "carry forward" all of the constructor
definitions -- thinking narrowly that no one will use this version of the
ctor. Then you get fun stuff happening if the object happens to be
instanced by an activator in an object factory.
Rarely, but occasionally, we will have a refactor that would have us wanting
to add a new constructor to a base class. That's quite painful if you have
a bunch of child classes, but it's mostly clerical work, since tools like
reflector and even the object browser make it easy enough to track down all
of the children (the difference here is that you are actively adding a new
ctor, so you know that you need to track down every child)
See, all of these are kind of weird cases. I agree that you run into
equally troubling issues when you have a constructor in the base class that
is no longer relevant in a child class, which is why I don't complain very
loudly about this issue.
However, when we look at lies, damn lies, and statistics, I just have to say
that in hindsight (now that our toolkit is farther along), we only have a
few classes where we needed to hide a constructor, but many where we would
have wanted to inherit a constructor. So given a situation that is sticky
any way you slice it, our majority vote would have been in favor of
inheritance.
I do think it would help if VS.NET had better tools for creating
"dummy" constructors, in the same way that Eclipse has - in Eclipse's
Yes, I think that would help. Also, I wonder if one could create an FXCop
rule to slueth out classes that 'hide" an inherited constructor, or that
fail to call base(). That would go a long way.
An alternative would be to make it both the base class
*and* the derived class's choice, so that both of them have to say
"yes" before constructors are inherited.
Yes, that would work as well. I suppose that sort of thing would be
implemented as an attribute.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... J.Marsch <je****@ctcdeveloper.com> wrote: I won't argue (very strongly) against the merits of the C# decision --
there
is a very good supporting argument. What I can say is that I first
stumbled
on to the constructor issue a little over a year ago. At the time, I was
nonplussed. It didn't work the way that I expected it to, but I
understood
the argument. Today, I can balance that view with a little bit of
hindsight. I can easily say that (in my own development environment),
not
having inheritable constructors has caused more damage and more pain (and
I
mean bugs here, not just "oooh, I have to type") than having them would
have.
Were those bugs from types which were created with a "surprising"
constructor due to an overload which you didn't expect (eg going for a
declared constructor taking an object parameter rather than a base
class's constructor taking a string parameter) or due to reflection?
It's the kind of thing which I can't imagine creating that many more
bugs.
I do think it would help if VS.NET had better tools for creating
"dummy" constructors, in the same way that Eclipse has - in Eclipse's
Java tooling you can just check which of the base class's constructors
you want to provide in the subclass.
In terms of the language decision, I think it's the right way round,
personally. An alternative would be to make it both the base class
*and* the derived class's choice, so that both of them have to say
"yes" before constructors are inherited.
(Personally, virtually the only time I wish I could have inherited
constructors is with exceptions.)
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
J.Marsch <je****@ctcdeveloper.com> wrote: (Personally, virtually the only time I wish I could have inherited
constructors is with exceptions.) Yah, that one is huge.
Were those bugs from types which were created with a "surprising"
constructor due to an overload which you didn't expect (eg going for a
declared constructor taking an object parameter rather than a base
class's constructor taking a string parameter) or due to reflection?
A little of both. We are building a development framework, and we expect
people working at the application level to be inheriting our base classes.
One of our most common quality problems occurs when someone (usually a
downlevel developer -- an internal person consuming our tools) adds the
constructor but fails to call :base(x), such that the object never fully
initializes.
<snip - understood>
See, all of these are kind of weird cases. I agree that you run into
equally troubling issues when you have a constructor in the base class that
is no longer relevant in a child class, which is why I don't complain very
loudly about this issue.
However, when we look at lies, damn lies, and statistics, I just have to say
that in hindsight (now that our toolkit is farther along), we only have a
few classes where we needed to hide a constructor, but many where we would
have wanted to inherit a constructor. So given a situation that is sticky
any way you slice it, our majority vote would have been in favor of
inheritance.
Are you just considering classes which derive from your own, however,
or *all* classes? Don't forget that all classes would have a
parameterless constructor if constructors were inherited, as Object
does. That's why I'd want it to at least be opt-in, preferrably on the
part of both the base class and the derived class (sort of like
virtual/override modifiers on methods). I do think it would help if VS.NET had better tools for creating
"dummy" constructors, in the same way that Eclipse has - in Eclipse's
Yes, I think that would help. Also, I wonder if one could create an FXCop
rule to slueth out classes that 'hide" an inherited constructor, or that
fail to call base(). That would go a long way.
Not sure what you mean by those, given that constructors aren't
inherited - were you considering the case if a change had already been
made to .NET? For the latter - all constructors implicitly either call
base(...) or this(...) for some value of "..." - what you'd probably
want to check is that all constructors which take parameters and which
match a constructor with the same parameters in the base class call
that constructor. At a guess, anyway :) An alternative would be to make it both the base class
*and* the derived class's choice, so that both of them have to say
"yes" before constructors are inherited.
Yes, that would work as well. I suppose that sort of thing would be
implemented as an attribute.
Or possibly a simple modifier on the class/constructor definition. (It
might be good to let the base class decide *which* constructors were
inheritable, and the derived class to decide whether or not to inherit
all such constructors or not.)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
> Are you just considering classes which derive from your own, however, or *all* classes? Don't forget that all classes would have a
parameterless constructor if constructors were inherited, as Object
does. That's why I'd want it to at least be opt-in, preferrably on the
part of both the base class and the derived class (sort of like
virtual/override modifiers on methods).
That's an excellent point. It could be very irritating if all classes were
forced to have a parameterless constructor. This would be yet another
reason that I don't bark very loudly about constructors as they are today--
it's a pretty sticky issue to make them inheritable.
Not sure what you mean by those, given that constructors aren't
inherited - were you considering the case if a change had already been
made to .NET? For the latter - all constructors implicitly either call
base(...) or this(...) for some value of "..." - what you'd probably
want to check is that all constructors which take parameters and which
match a constructor with the same parameters in the base class call
that constructor. At a guess, anyway :)
That's my fault, I shouldn't have referred to them as "inherited". Your
guess is pretty much what I had in mind. One additional scenario: hmm. I
tried to describe this in English, but erased it. Easier to show in code:
consider:
public class Parent
{
public Parent()
{
}
public Parent(object theParam)
{
}
}
public class Child: Parent
{
public Child() {}
public Child(object theParam) {}
public Child(string theParam) {}
}
It might be kind of handy if all 3 of the constructors in Child were
considered suspect (get a warning from FXCop or something) because because
none of them explicitly calls a constructor on base. That's not necessarily
a problem -- it might be intentional, but I would like to have that
situation called to my attention. In some cases, it might be fine, but in
others it might be a bug, or it might be a flag indicating that we need to
consider refactoring a class.
That last one (refactor flag) is the thing that's on my mind the most
lately. We've been adding developers, and it's becoming increasingly
difficult to stay on top of standards, and to know when an issue at the
application level is really an indicator of a need for change at the
framework level -- it's easy to see when you're working on both, but there's
more risk of it being swept under the rug as the team expands.
Or possibly a simple modifier on the class/constructor definition. (It
might be good to let the base class decide *which* constructors were
inheritable, and the derived class to decide whether or not to inherit
all such constructors or not.)
Agreed.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... J.Marsch <je****@ctcdeveloper.com> wrote: > (Personally, virtually the only time I wish I could have inherited
> constructors is with exceptions.)
Yah, that one is huge.
> Were those bugs from types which were created with a "surprising"
> constructor due to an overload which you didn't expect (eg going for a
> declared constructor taking an object parameter rather than a base
> class's constructor taking a string parameter) or due to reflection?
A little of both. We are building a development framework, and we expect
people working at the application level to be inheriting our base
classes.
One of our most common quality problems occurs when someone (usually a
downlevel developer -- an internal person consuming our tools) adds the
constructor but fails to call :base(x), such that the object never fully
initializes.
<snip - understood>
See, all of these are kind of weird cases. I agree that you run into
equally troubling issues when you have a constructor in the base class
that
is no longer relevant in a child class, which is why I don't complain
very
loudly about this issue.
However, when we look at lies, damn lies, and statistics, I just have to
say
that in hindsight (now that our toolkit is farther along), we only have a
few classes where we needed to hide a constructor, but many where we
would
have wanted to inherit a constructor. So given a situation that is
sticky
any way you slice it, our majority vote would have been in favor of
inheritance.
Are you just considering classes which derive from your own, however,
or *all* classes? Don't forget that all classes would have a
parameterless constructor if constructors were inherited, as Object
does. That's why I'd want it to at least be opt-in, preferrably on the
part of both the base class and the derived class (sort of like
virtual/override modifiers on methods).
> I do think it would help if VS.NET had better tools for creating
> "dummy" constructors, in the same way that Eclipse has - in Eclipse's
Yes, I think that would help. Also, I wonder if one could create an
FXCop
rule to slueth out classes that 'hide" an inherited constructor, or that
fail to call base(). That would go a long way.
Not sure what you mean by those, given that constructors aren't
inherited - were you considering the case if a change had already been
made to .NET? For the latter - all constructors implicitly either call
base(...) or this(...) for some value of "..." - what you'd probably
want to check is that all constructors which take parameters and which
match a constructor with the same parameters in the base class call
that constructor. At a guess, anyway :)
>An alternative would be to make it both the base class
> *and* the derived class's choice, so that both of them have to say
> "yes" before constructors are inherited.
Yes, that would work as well. I suppose that sort of thing would be
implemented as an attribute.
Or possibly a simple modifier on the class/constructor definition. (It
might be good to let the base class decide *which* constructors were
inheritable, and the derived class to decide whether or not to inherit
all such constructors or not.)
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
J.Marsch <je****@ctcdeveloper.com> wrote: Are you just considering classes which derive from your own, however,
or *all* classes? Don't forget that all classes would have a
parameterless constructor if constructors were inherited, as Object
does. That's why I'd want it to at least be opt-in, preferrably on the
part of both the base class and the derived class (sort of like
virtual/override modifiers on methods).
That's an excellent point. It could be very irritating if all classes were
forced to have a parameterless constructor. This would be yet another
reason that I don't bark very loudly about constructors as they are today--
it's a pretty sticky issue to make them inheritable.
Of course, in OO environments which don't have a common ancestor class,
it's much less of a problem.
Not sure what you mean by those, given that constructors aren't
inherited - were you considering the case if a change had already been
made to .NET? For the latter - all constructors implicitly either call
base(...) or this(...) for some value of "..." - what you'd probably
want to check is that all constructors which take parameters and which
match a constructor with the same parameters in the base class call
that constructor. At a guess, anyway :)
That's my fault, I shouldn't have referred to them as "inherited". Your
guess is pretty much what I had in mind. One additional scenario: hmm. I
tried to describe this in English, but erased it. Easier to show in code:
<snip - yup>
That last one (refactor flag) is the thing that's on my mind the most
lately. We've been adding developers, and it's becoming increasingly
difficult to stay on top of standards, and to know when an issue at the
application level is really an indicator of a need for change at the
framework level -- it's easy to see when you're working on both, but there's
more risk of it being swept under the rug as the team expands.
You might find DevAdvantage helpful to you - I don't know if it's got
the precise rule you're after in this case, but you may well be able to
create your own if not, and if it doesn't provide enough abilities,
it's definitely worth telling them.
See http://www.devadvantage.com
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Well, the spec is slightly unclear. I find it helpful to use "default
constructor" to mean a constructor which is supplied when no other ones
are, and "parameterless constructor" to mean a constructor which takes
no parameters."
I agree with your definition of a default constructor as well as the one
for parameterless constructor. In what way is the compiler trying to overload the derived >class's
constructor? What do you even mean by that?
Can you answer me if you can overload a signature of any member of a
class if the same signature did not exist in some form ? I will answer
to your question after your answer.
But where does the "as only like constructors can invoke >like
constructors" part come in?
I need a clarification from you if we can continue to argue on
constructors in inheritance or should we only contest on the simple fact
that if the OP wanted to know only about whether constructors are
inherited or not, why wouldn't the OP simply ask "Are constructors
inherited or not ?"
In what way did I introduce the issue of constructor >chaining? See
your original post on the thread, quoted >above!
I introduced only the behavior of the constructors but you made it an
issue of chaining and inheritance.
Um, no. By the time you posted, the OP's question had been >answered by
several people, who all understood that the OP >was basically asking why
constructor inheritance wasn't in >C#, and whether there was some way of
enabling it that >he'd missed.
What do you mean, um no? Are you limited in your vocab only to the usage
of disagreeing and disagreeable words?
Even if >By the time you posted, the OP's question had been >answered by
several people> is your opinion, it still does not matter because as I
have already noted the OP is somewhat confused and extra help is not
something that you can object to because the thread is devoted to the
OP's query and not to service your quest for more points to argue.
<quote>
A simple thumb rule in .Net is the like constructor will invoke its
like base contructor and all instantiation will go up all the way to
the base System.Object class.
</quote>
Now, please explain the relevance of that to constructor >inheritance.
My explanation, as I have already written, is not on inheritance but on
how constructors behvae and what are the likely errors that can occur.
Knowing this the OP can easily form his own understanding of
constructors. But, if you want me to conform to your own understanding
then I will - constructors are not inherited in C#.
Given your article on constructors on Devdex,
There is no such article. I have already had it taken off ever since you
pointed out the error (let me assure you the error was a typo but again,
I am sure you will not agree to that!:))
I'm not sure you entirely understand constructor chaining.
Um (taking a tip from you), no, I wouldn't say that because you have not
yet answered MY question as to why an error pertaining to System.Object
should appear when you try to access a public member of a class with the
instance of another class and neither class participate in inheritance.
And please do not think that I am seeking an answer I know why the error
appears but what I want to know is your understanding of the error so
that I can better explain to you whether or not I understand constructor
chaining.
<quote>
The System.Object constructor is also totally irrelevant
to the derived class's constructor, as only the base class's
constructors are considered - you can't "skip" the base class, so the
System.Object constructor is only relevant to the base class.
</quote>
Please refer to the previous paragraph and upon your reply, we can
contest whether System.Object is relevant to constructor chaining or not
and please do not reply that the thread is on inheritance and not
chaining or whatever.
<Quote>
implement (it is similar to overriding although the terminology is
different in this case) the base class' default constructor".)
</Quote>
If you put it this way, I am quite sure you are right but I will have to
check whether I have really written implement because you have a way of
attributing your own thoughts and blame them as mine. I agree that the
implements word makes it sound as if the base' constructor is being
overridden in the derived class but let me check whether I really used
those words as you claim. If I did, I can only say that you are
absolutely right and as an explanation let me put it this way that it
was more due to a probable human typo error and nothing else.
The original OP's post is
-------------------------
"When attempting to instance one of the derived classes using
parameters, I get CS1501 (no method with X arguments). "
----------------------------------------------------------
<Quote>
No. That's a very small *part* of the post.
</Quote>
But it is an illuminating part.
with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Ravichandran J.V. <jv************@yahoo.com> wrote: "Well, the spec is slightly unclear. I find it helpful to use "default
constructor" to mean a constructor which is supplied when no other ones
are, and "parameterless constructor" to mean a constructor which takes
no parameters."
I agree with your definition of a default constructor as well as the one
for parameterless constructor.
Good.
In what way is the compiler trying to overload the derived >class's
constructor? What do you even mean by that?
Can you answer me if you can overload a signature of any member of a
class if the same signature did not exist in some form ? I will answer
to your question after your answer.
You don't overload a signature - you overload either a method or a
constructor. If it's a method, there has to be another method with the
same name (not signature). If it's a constructor, there has to be
another constructor.
However, I still don't see what you mean when you talk about the
"compiler trying to overload" anything.
But where does the "as only like constructors can invoke >like
constructors" part come in?
I need a clarification from you if we can continue to argue on
constructors in inheritance or should we only contest on the simple fact
that if the OP wanted to know only about whether constructors are
inherited or not, why wouldn't the OP simply ask "Are constructors
inherited or not ?"
I'm happy to debate whatever you want, but I do contest your "simple
fact". The OP realised that constructor inheritance was at least not
provided by default by C#, but wanted to know if there was any way of
getting it.
In what way did I introduce the issue of constructor >chaining? See
your original post on the thread, quoted >above!
I introduced only the behavior of the constructors but you made it an
issue of chaining and inheritance.
The only behaviour of constructors you talked about in your original
post was chaining.
Um, no. By the time you posted, the OP's question had been >answered by
several people, who all understood that the OP >was basically asking why
constructor inheritance wasn't in >C#, and whether there was some way of
enabling it that >he'd missed.
What do you mean, um no? Are you limited in your vocab only to the usage
of disagreeing and disagreeable words?
I mean "I disagree with your statement", fairly obviously. While my
vocabulary clearly isn't limited to "disagreeing and disagreeable
words" I don't see why I shouldn't voice my disagreement.
Even if >By the time you posted, the OP's question had been >answered by
several people> is your opinion, it still does not matter because as I
have already noted the OP is somewhat confused and extra help is not
something that you can object to because the thread is devoted to the
OP's query and not to service your quest for more points to argue.
<quote>
A simple thumb rule in .Net is the like constructor will invoke its
like base contructor and all instantiation will go up all the way to
the base System.Object class.
</quote>
Now, please explain the relevance of that to constructor >inheritance.
My explanation, as I have already written, is not on inheritance but on
how constructors behvae and what are the likely errors that can occur.
Things that the OP had demonstrated his understanding of in his first
post, and which have little to do with what he was actually asking.
Knowing this the OP can easily form his own understanding of
constructors. But, if you want me to conform to your own understanding
then I will - constructors are not inherited in C#.
Ah, great. Does that mean you retract your various insults on the
thread ages ago where you accused me all manner of stupidities for
believing what the spec says (i.e. that they're not inherited)? You
might want to go back and read that thread, by the way. It's easy to
find - just search on groups.google.com for the exact phrase "The
destructor is the only object of a base class that is not inherited"
(part of one of your articles).
Note that I don't want you to conform to my understanding - I want you
to conform to what the language specification says, which is clearly
demonstrated in numerous programs.
Given your article on constructors on Devdex,
There is no such article. I have already had it taken off ever since you
pointed out the error (let me assure you the error was a typo but again,
I am sure you will not agree to that!:))
It still seems to be there:
http://www.developersdex.com/gurus/a...459.asp?Page=1
It's also still in your list of articles:
http://www.developersdex.com/gurus/default.asp?p=3133
And yes, I disagree with it being a typo, as you've stated it more than
once. You stated something very similar in the newsgroup thread a long
time ago: "It is a means to achieve inheritance because without
implementing the base' default construcotrs, the derived class cannot
inherit the overloaded constructors of the base." (What you meant by
that exactly is hard to say, given that constructors aren't inherited
anyway.)
I'm not sure you entirely understand constructor chaining.
Um (taking a tip from you), no, I wouldn't say that because you have not
yet answered MY question as to why an error pertaining to System.Object
should appear when you try to access a public member of a class with the
instance of another class and neither class participate in inheritance.
Could you give an example? To answer your previous challenge though:
using System;
class Test
{
static void Main()
{
Class2 c2 = new Class2();
c2.member = 5;
Console.WriteLine (c2.member);
}
}
class Class1
{
public int member;
}
class Class2 : Class1
{
}
I can't see anything in your challenge which isn't covered there, but
the code compiles and runs with no problem.
I'm still not sure what the relevance to the OP's question is though.
And please do not think that I am seeking an answer I know why the error
appears but what I want to know is your understanding of the error so
that I can better explain to you whether or not I understand constructor
chaining.
<quote>
The System.Object constructor is also totally irrelevant
to the derived class's constructor, as only the base class's
constructors are considered - you can't "skip" the base class, so the
System.Object constructor is only relevant to the base class.
</quote>
Please refer to the previous paragraph and upon your reply, we can
contest whether System.Object is relevant to constructor chaining or not
and please do not reply that the thread is on inheritance and not
chaining or whatever.
It's relevant to constructor chaining when writing a class deriving
from System.Object. It's not relevant when writing a class deriving
from any other class. The reason your earlier sample code wouldn't
compile has nothing to do with System.Object's constructors - it's
because the class you called Base doesn't have a parameterless
constructor, and that's the constructor that the Derived constructor is
trying to call. Changing the Derived constructor to:
public Derived(int x) : base (x)
{
}
would make it compile fine. The error also has nothing to do with the
line "Derived ob=new Derived(10);" - that line itself is fine, as the
Derived class *does* have a constructor which takes an int parameter.
<Quote>
implement (it is similar to overriding although the terminology is
different in this case) the base class' default constructor".)
</Quote>
If you put it this way, I am quite sure you are right but I will have to
check whether I have really written implement because you have a way of
attributing your own thoughts and blame them as mine.
So you've said before without ever actually demonstrating, as far as I
can remember.
I agree that the implements word makes it sound as if the base'
constructor is being overridden in the derived class but let me check
whether I really used those words as you claim. If I did, I can only
say that you are absolutely right and as an explanation let me put it
this way that it was more due to a probable human typo error and
nothing else.
You can check it on the article you say you've removed. I cut and
pasted the quote directly from that. It's not due to a typo though -
your sample code clearly shows that you meant what you said. You really
believed that in order for a derived class to use a constructor from
the base class which takes parameters, you had to have a parameterless
constructor in the derived class.
If it were just a typo, you wouldn't have this bit (on the second
page):
<quote>
Hence, to make the call
public b(float f,int k):base(f,k)
work, the derived class 'b', too, must have the default constructor
implemented in it
</quote>
I hope you understand constructors better than you did when you wrote
the article, but you clearly didn't understand them then. The original OP's post is
-------------------------
"When attempting to instance one of the derived classes using
parameters, I get CS1501 (no method with X arguments). "
----------------------------------------------------------
<Quote>
No. That's a very small *part* of the post.
</Quote>
But it is an illuminating part.
Not without taking the rest of the post into context - the rest of the
post which clearly shows that the OP knew why he was getting that error
message.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Good."
I am glad that you approve but please be as agreeable as I am.
"You don't overload a signature - "
I don't have access to my computer otherwise I would have copied/pasted
the exact error that a compiler generates - No matching signature found
or something similar is the error when you try to early bind a call to a
non-existent method and similarly, "a method with the same
name/signature already exists...". I will post back on the exact error
that appears.
"I don't see why I shouldn't voice my disagreement."
You can but please refrain from attributing opinions that are never
voiced by me, which is what you do and which is what and why I objected
to in our previous interaction as well but you simply would not stop.
"Ah, great. Does that mean you retract your various insults on the
thread ages ago where you accused me all manner of stupidities.."
I never insulted you as I said I only objected to your attributing all
kinds of things which you claimed were posted by me. But if you insist,
I do not mind retracting any statements I made against you.
"It is a means to achieve inheritance because without
implementing the base' default construcotrs, the derived class cannot
inherit the overloaded constructors of the base." (What you meant by
that exactly is hard to say, given that constructors aren't inherited
anyway.)
It was written way back in 2001 but the argument arose because I knew
constructors were not inherited so how did that statement come into the
article is something I cannot explain. These articles were part of a
book (Let me say humbly that I, too, can write a book (even if you think
that it must be full of mistakes!) and is titled C+C++=C# ! What I am
trying to understand is how that statement got into the article! But,
since it was a mistake on my part I will accept that what you have
quoted above is correct and I can only explain that it was a typo error
because I cannot think of any other reason to explain it.
It's also still in your list of articles: http://www.developersdex.com/gurus/default.asp?p=3133
I will remove it from the list.
"To answer your previous challenge though:"
This is what I meant when I said, "There you go again!" in this same
thread and what I mean when I say "Please do not attribute
qualities/opinions that are not mine."
I simply posted a question to you and you bloat it to a challenge.
"It's relevant to constructor chaining when writing ..."
writing what???
with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Ravichandran J.V. <jv************@yahoo.com> wrote: "Good."
I am glad that you approve but please be as agreeable as I am.
I'll leave it to anyone else reading this thread to decide how
agreeable you are - especially bearing in mind the quotes from the 2002
thread I've included below.
"You don't overload a signature - "
I don't have access to my computer otherwise I would have copied/pasted
the exact error that a compiler generates - No matching signature found
or something similar is the error when you try to early bind a call to a
non-existent method and similarly, "a method with the same
name/signature already exists...". I will post back on the exact error
that appears.
Yes - but that's not saying that you overload a signature. You can't
overload a method when the same signature already exists, and you can't
call a method if there isn't one with a matching signature. Neither of
those indicate that "overloading a signature" is valid terminology.
"I don't see why I shouldn't voice my disagreement."
You can but please refrain from attributing opinions that are never
voiced by me, which is what you do and which is what and why I objected
to in our previous interaction as well but you simply would not stop.
That's about the third time you've said that in this thread, but you
never provide any examples. Please do so, or stop making the
allegation.
"Ah, great. Does that mean you retract your various insults on the
thread ages ago where you accused me all manner of stupidities.."
I never insulted you as I said I only objected to your attributing all
kinds of things which you claimed were posted by me. But if you insist,
I do not mind retracting any statements I made against you.
Never insulted me? Good grief! Here are some choice quotes from that
thread:
<quote>
You have very little idea of
what OOPS is, Jon, and I am quite sure you keep thinking that everybody
must be like you - half-knowledged and who pass their own wrong claims
onto others - and jump around making a noise.
</quote>
<quote>
Why don't you get the knowledge part straight and then argue on your
doubts ?
</quote>
<quote>
And kindly refrain from commenting on my OOPS knowledge, as I have
already proved you wrong twice on both - 1. your understanding of
English 2. on your knowledge of OOPS - and I don't want nor do I like
to be called wrong by absolutely ill-equipped of programmers.
</quote>
<quote>
As I said, you are so ill-equipped in knowledge, I don't see how your
agreement to my statements should make any difference as you are so
wrong you better correct yourself before staking any claim to be my
equal.
</quote>
<quote>
You are being childish
</quote>
Bear in mind with all these claims of how "ill-equipped in knowledge" I
supposedly was that you were repeating, time and time again, that
constructors *are* inherited. You were also making the claim that you
say must have been a typo in the Devdex article, namely (to quote
another post):
<quote>
A base class may have more than just a default constructor and to be
able to make us of the base class' other (overloaded) constructors, you
need to implement the base class' default constructor first.
</quote>
As for attributing things to you - again, please give examples. I'm
very careful with how I quote people. Of course, I may have
misunderstood you a few times, given the way you were misusing
terminology.
"It is a means to achieve inheritance because without
implementing the base' default construcotrs, the derived class cannot
inherit the overloaded constructors of the base." (What you meant by
that exactly is hard to say, given that constructors aren't inherited
anyway.)
It was written way back in 2001 but the argument arose because I knew
constructors were not inherited so how did that statement come into the
article is something I cannot explain.
If you knew constructors weren't inherited, why did you make statements
directly to the contrary in October 2002? Here are a few examples:
<quote>
You cannot leave it away if you want to because if you do, you will not
be able to inherit the other constructors of the base.
</quote>
<quote>
Kindly explain, if you know how to, HOW DID THE MESSAGE "Hello World !"
GET DISPLAYED IN THE CONSOLE OF YOUR PC IF, AS YOU CLAIM, "CLASSES
DON'T INHERIT CONSTRUCTORS." ?????
</quote>
<quote>
OOOOH, "may or may not agree with me"? When you do not even know the
basic of OOPS on derived classes inheriting base class' constructors or
not ! OOOF !
</quote>
(That was you disagreeing with my statement that constructors aren't
inherited.)
<quote>
The destructor is the only object of a base class that is not
inherited.
</quote>
<quote>
Similarly, in the case of the constructors, as in my posted class, in
the earlier posts, the base' default constructor is inherited which is
how the derived class can access it
</quote>
<quote>
So, (after having proved it I can say SO), the derived class does
inherit constructors and I am not, NOT, contradicting nor questioning
the lang. specs.
</quote>
<quote>
I hope we have agreed on the point that a
constructor is only called explicitly with ":Base()" and since there is
no such statement it means that the derived class' instance inherited
the base class' constructor.
</quote>
(Note the double mistake in that sentence - a parameterless base classs
constructor is called implicitly if there is no ": base(...)" part.)
These articles were part of a
book (Let me say humbly that I, too, can write a book (even if you think
that it must be full of mistakes!) and is titled C+C++=C# ! What I am
trying to understand is how that statement got into the article! But,
since it was a mistake on my part I will accept that what you have
quoted above is correct and I can only explain that it was a typo error
because I cannot think of any other reason to explain it.
If it's a typo error, why did you make the same mistake several times
in different places, and provide code to try to back up the spurious
claim?
It's also still in your list of articles:
http://www.developersdex.com/gurus/default.asp?p=3133
I will remove it from the list.
"To answer your previous challenge though:"
This is what I meant when I said, "There you go again!" in this same
thread and what I mean when I say "Please do not attribute
qualities/opinions that are not mine."
In what way is that an "opinion" or "quality"?
I simply posted a question to you and you bloat it to a challenge.
Actually, you didn't post a question. You made a request. I reckon the
word challenge isn't misconstruing anything here.
Now, any reason you haven't responded to the fact that I fulfilled your
request without any error messages occurring?
"It's relevant to constructor chaining when writing ..."
writing what???
A class deriving from System.Object, as my post said. Does the Devdex
interface you use not allow you to see the full post? I strongly
suggest you start using a proper newsreader if that's the case. (In
fact, I suggest that anyway - it would be easier to reply to your posts
if you quoted in the normal Usenet way.)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote:
<snip> "It's relevant to constructor chaining when writing ..."
writing what???
A class deriving from System.Object, as my post said. Does the Devdex
interface you use not allow you to see the full post? I strongly
suggest you start using a proper newsreader if that's the case. (In
fact, I suggest that anyway - it would be easier to reply to your posts
if you quoted in the normal Usenet way.)
I've just checked, and indeed Devdex does arbitrary truncate articles
without telling anyone. To read the full articles, either use one of
the many other C# group web mirrors (eg http://msdn.microsoft.com/newsgroups/default.aspx?
dg=microsoft.public.dotnet.languages.csharp) or (preferrably, IMO) use
a proper newsreader (I like Microplanet Gravity myself, which is freely
available now, but Outlook Express will do if you use that for mail)
and use the server news.microsoft.com. It's a *much* nicer experience
than the nasty Devdex user interface. Of course, you won't get Devdex
"guru points" that way, but I hope you don't value those above being
able to actually read full articles.
I'm afraid it looks like you've missed some of the later points in my
previous posts too, due to this. You'll be able to see those fully with
either of the approaches above, of course - I'd be happy to respond to
your thoughts regarding anything you missed before.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] wrote: use a proper newsreader (I like Microplanet Gravity myself, which is
freely available now, but Outlook Express will do if you use that for
mail) and use the server news.microsoft.com. It's a much nicer
Another free one (and also includes source, albeit Delphi source) is
here http://www.wilsonc.demon.co.uk/d9xananews.htm it's very nice.
Cheers Tim.
On 23/12/2004 Tim Jarvis wrote: Jon Skeet [C# MVP] wrote:
use a proper newsreader (I like Microplanet Gravity myself, which is
freely available now, but Outlook Express will do if you use that
for mail) and use the server news.microsoft.com. It's a much nicer
Another free one (and also includes source, albeit Delphi source) is
here http://www.wilsonc.demon.co.uk/d9xananews.htm it's very nice.
Cheers Tim.
I second that :-)
Seems to be a well kept secret though.
--
Jeff Gaines
Posted with XanaNews 1.17.1.2 http://www.wilsonc.demon.co.uk/delphi.htm
<quote>
Kindly explain, if you know how to, HOW DID THE MESSAGE "Hello World !"
GET DISPLAYED IN THE CONSOLE OF YOUR PC IF, AS YOU CLAIM, "CLASSES DON'T
INHERIT CONSTRUCTORS." ?????
</quote>
<quote>
OOOOH, "may or may not agree with me"? When you do not even know
thebasic of OOPS on derived classes inheriting base class' constructors
or not ! OOOF !
</quote>
(That was you disagreeing with my statement that constructors aren't
inherited.) Sorry about the statement that you do not know anything
about OOPS.
I do agree that they do seem to be quite baseless and irrational. But
let me assure you that I retract all these above statements and please
do accept my apologies for them.
"As for attributing things to you - again, please give examples. I'm
very careful with how I quote people. Of course, I may have
misunderstood you a few times, given the way you were misusing
terminology." I'm very careful with how I quote people.
No, you are not careful. I am not as painstaking as you to pick on those
statements and quote again but there are quite a few instances where you
have misconstrued my statements and misquoted me quite a few times
(which you yourself agree to above and which is why I accept that my
responses were irrational and baseless), which was one of the reasons
why I took to answering you irrationally.
Please let me assure you you have more than a few times misunderstood me
and at all times failed to rectify them saying, as usual, "No", "No not
that", No that is not the way it works", "No, your coding lacks...",
"No, that is not correct" "No, that is not what I said"(even when I
would copy/paste your own words) (which you still do but what you do not
think important is that a reply is to an OP and not to you, seeking your
personal opinion on how well I have answered or how well I code.) and
neither have you been all that refrained in your own comments about me,
about the way I code, about my naming conventions and even about the way
I give my examples.
Even recognized websites have examples that start with "class a" to
which you object, quite strongly, which was another reason why I had to
disagree with you on all counts and reply irrationally.
In all fairness, I have read all your posts and am quite sure that you
are quite knowledged, learned in your own right (these words I use
mainly to impress upon you that all that was written was irrational that
was more out of provocation caused by your frequent criticism of my
personal style of coding which is my own than any real intent to insult
you. You will agree with me that while posting my example or sample code
I need not bother about conventions but you pick on it as if it were the
be all and end all of everything. I know you will not agree with me
because for you, please correct me if I am wrong, agreeing means a
submission of some sort to the other's opinion.)
Actually, you didn't post a question. You made a request. >I reckon the
word challenge isn't misconstruing anything >here.
Oh yeah, your misconstruing does not mean anything but mine always does!
"Challenge" can be used in place of "request" or "question" but does not
mean anything while, if I do the same it means lots of miscontrued
statements. Please be more objective.
If it's a typo error, why did you make the same mistake >several times
in different places, and provide code to try >to back up the spurious
claim?
I did not make any spurious claim nor back it up with code. I was just
arguing with you.:) You surely cannot call me a stupid programmer "who
does not know any conventions and a poor coding style" and expect me to
agree with you, do you?
with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
>I've just checked, and indeed Devdex does arbitrary >truncate articles
without telling anyone. To read the full >articles, either use one of
the many other C# group web >mirrors Of course, you won't get Devdex "guru points" that way, but >I hope you
don't value those above being able to actually >read full articles.
You seem to make some point with the "guru points" ( this is not the
first time that you have mentioned it) and you may be quite right
actually on that !:)
Anyway, thanks for the tip (about the newsgroup). Actually, things here
are not as rosy as to be able to use Outlook for a newsgroup...not such
great connections as you must surely have at your disposal.
with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it! This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Warren Peace |
last post by:
'Tis my first time trying to install PHP on my Win XP machine...
Apache/2.2.3(Win32) PHP/5.2.0
Main problem is that with my lack of PHP experience,
I'm not sure if my syntax is incorrect, or if...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
