Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>Why can't I call a constructor directly AT THE END of another constructor whereas I can call AT THE BEGINNING.</p> </blockquote> <p>Well, let's break it down into two cases. (1) you're calling a "this" constructor, and (2) you're calling a "base" constructor.</p> <p>Suppose you're in the first case. The typical usage pattern for this scenario is to have a bunch of ctors that take different arguments and then all "feed" into one master ctor (often private) that does all the real work. Typically the public ctors have no bodies of their own, so there's no difference between calling the other ctor "before" or "after" the empty block.</p> <p>Suppose you're in the first case and you <em>are</em> doing work in each ctor, and you want to call other ctors at times other than the start of the current ctor. </p> <p>In that scenario you can easily accomplish this by extracting the work done by the different ctors into methods, and then calling the methods in the ctors in whatever order you like. That is superior to inventing a syntax that allows you to call other ctors at arbitrary locations. There are a number of design principles that support this decision. Two are:</p> <p>1) Having two ways to do the same thing creates confusion; it adds mental cost. We often have two ways of doing the same thing in C#, but in those situations we want the situation to "pay for itself" by having the two different ways of doing the thing each be compelling, interesting and powerful features that have clear pros and cons. (For example, "query comprehensions" vs "fluent queries" are two very different-looking ways of building a query.) Having a way to call a ctor the way you'd call any other method seems like having two ways of doing something -- calling an initialization method -- but without a compelling or interesting "payoff". </p> <p>2) We'd have to add new language syntax to do it. New syntax comes at a very high cost; it's got to be designed, implemented, tested, documented -- those are our costs. But it comes at a higher cost to YOU because <em>you have to learn what the syntax means, otherwise you cannot read or maintain other people's code</em>. That's another cost; again, we only take the huge expense of adding syntax if we feel that there is a clear, compelling, large benefit for our customers. I don't see a huge benefit here.</p> <p>In short, achieving your desired construction control flow is easy to do without adding the feature, and there's no compelling benefit to adding the feature. No new interesting representational power is added to the language.</p> <p>For the "base" scenario, it's quite straightforward. You never want to call a base constructor AFTER a derived constructor. That's an inversion of the normal dependency rules. Derived code should be able to depend on the base constructor having set up the "base" state of the object; the base ctor should never depend on the derived constructor having set up the derived state. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload