Re: Funny loop with post-increment.

the
> > compiler will whine that you have to place the break there because
> > there's
> no
> > fall through, however the break statement itself doesn't do anything:
there
> > was already a break in the code at that spot.

It will be easy for C# to support implicit 'break's. Afterall, there are
other breaking semantics like return, throw, goto) that remove the need for
explictbreaks in the switch construct.

Regardless, however, one thing about languages is that some things are there
for function and others are there for expressiveness, readability and sheer
documentation. How much is too much? Good question, but I don't know. The
downside with 'implicit-everywhere' is that it forces you as a language
designer to make a lot more assumptions about how people are going to use
your language. And that sometimes could be limiting.

For example, right from C# 1.0, type resolution/coercion was built into the
language (hence, function overloading support). Yet, 'var' type induction
showed up much, much later and retains only limited use (compared to how it
is used in the scripting languages). Why is that?

Perhaps because the following code,

bool recycledFromPool ;
IPerson employee = PersonFactory.GetEmployee(out recycledFromPool);

is probably better documentation (ie: shows clearer programmer intent) than

var recycledFromPool;
var employee = PersonFactory.GetEmployee(recycledFromPool);

because of the explicit type declaration of IPerson and the explicit passing
convention of poolSize.


In some programming philosophies, the following would be an equivalent
construct;

@recycledFromPool
@employee = factory :employee @recycledFromPool

The following can be said of the last construct:
    1. It use shorter keystrokes.
    2. It appears simpler.
    3. It has to be strong on convention (the compiler or runtime has to
know where the factory for Employee is located.
    4. If you 'declare' a variable more than once in error, the latest
becomes it. Sorry Princess!!
    4. The compiler has to be very forgiving
(hanging-your-runtime-nose-out-to-dry).
    5. It has no mechanism for enforcing contracts (Interface or otherwise).
    6. It's runtime will need a facility (redirection or exception) called
something like  "MethodNotFound"!

While these may suit some target audience, project size, experience set, and
the ratio of senior:junior coders on the team, it may not hold up for large
projects where many juniors have to help out with minimal supervision.


P

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com