Making it easier

re: Making it easier

Marius Bancila — Fri, 19 Jun 2009 09:13:47 GMT

I would argue that making life easier and making specific tasks easier are the two faces of the same coin. Life is a series of tasks that we do (of course one can do nothing all the time and still not finishing with that). If a technology is able to simplify one task, or maybe several, than we can say it simplifies our life.

re: Making it easier

Denis — Fri, 19 Jun 2009 08:33:53 GMT

>the purpose of technology is to make specific tasks easier

I think the purpose of a specific technology is to make a specific task (or tasks) easier; the purpose of technology in general, as a part of human life and culture, is to free humans from as much routine as possible in order to let humans to do what no machine can do: the CREATIVE WORK.

It's one hell of a debate, about whether or not machines can actually get creative; personally, I don't believe so (although the Matrix, especially the first installment, is still among my favorites - it all makes sense if you think different kind of "machines", like "the bureaucratic machine", or "the corporate machine"). Some Gen Y guys called me a "technological pessimist" for that belief of mine: they are positive that the purpose of technology is to free humans from ANY work, "just to have fun". Well, maybe I am that, I am not Gen Y, after all (just a couple of years too early), but the only way to convince me otherwise is to write a program (in C#, preferably) that will blog INSTEAD of the author. :-)

Or, maybe, a C# compiler that itself develops its own next version - how's that for a challenge to the C# meta-programming champions?

@Dominic, you and me both: I am in Australia, too

re: Making it easier

Dominic — Thu, 18 Jun 2009 10:45:35 GMT

The task of communicating with Australia is now much easier, thanks to improved technology.

Reading this from Australia and can't help but think how much 'smaller' the world is thanks to technology.

re: Making it easier

TheCPUWizard — Wed, 17 Jun 2009 04:28:32 GMT

Joren, pminaev,

Putting the readonly at the front (Joren's syntax) would be just fine, as would a "different" word (e.g. initonly) on the setter.

Because of the various limitations with automatic properties, I find that in my designs I CAN only use them about 5% of the time, because this is such a low percentage, and because of the benefits of consistancy, the reality is that I do not use them at all in designs where I have architectural control.

If addational capabilities such as this (ideally along with support for laxy evaluation, pre and post set conditioning) then they would have a major benefit.

re: Making it easier

Pavel Minaev [MSFT] — Wed, 17 Jun 2009 03:57:41 GMT

TheCPUWizard,

I understand the reason for the feature. However, the syntax you propose - "readonly set" - doesn't make much sense to me. As Joren rightly points out, it's a confusing combination.

re: Making it easier

Joren — Wed, 17 Jun 2009 02:10:43 GMT

>public string Foo { get; readonly set; }

I'd rather have "public readonly string Foo { get; set; }" for a property that can only be assigned in a constructor. "readonly set" confuses me. How can a setter be read-only? And how do you even read a setter?

Also, I'd prefer to have symmetry with fields.

re: Making it easier

TheCPUWizard — Wed, 17 Jun 2009 01:47:33 GMT

pminaev,

I dont see why

> public string Foo { get; readonly set; }

would be any different than

> public string Foo { get; private set; }

The language already supports having a more restrictive access policy on one of the accessors than the other. Being able to restrict it so that is cal only be called from within the body of the constructor is a natural extension.

Readonly allows for MANY optimizations to be performs [if the current compiler actually performs them is secondary].

Consider a construct such as x = A.Prop1.Prop2.Prop3.Prop4.Prop5

If it is known that the chain of referrences will not be modified, it is theoretically possible to reduce this to a single call to the final target instance rather than having to "follow the chain" at each invocation.

re: Making it easier

Pavel Minaev [MSFT] — Wed, 17 Jun 2009 01:13:55 GMT

> So how would you score adding a feature to allow:

> public string Foo { get; readonly set; }

I don't know about Eric, but as given, I'd score it "-10, Incomprehensible".

If I understand your intent correctly (which isn't certain, since you don't explain what the feature should do), given that "set" is already a contextual keyword there, a better option would seem to just add a new, clearer contextual keyword rather than try to combine a bunch of existing ones to get something vaguely resembling what you want. For example:

public string Foo { get; initialize; }

re: Making it easier

Greg — Tue, 16 Jun 2009 18:09:56 GMT

The new features start at -100 is nice given that only selective new technologies should be added to a platform and have the largest effort directed to improving, bug fixing, documenting and optimizing existing technologies.

re: Making it easier

chris — Tue, 16 Jun 2009 17:34:32 GMT

So true Eric! Just as excellent communicators carefully choose there words when giving speeches. Displays of esoteric vocabulary often fall on deaf ears.