the benefit would be exactly the same benefit of an instance extension.
That's a trivially false statement. Given that a primary benefit of
instance extensions is to be able to implicitly call a static method that
takes an instance of a particular type on an instance of an object of that
type, obviously a "static extension" would not be "exactly the same".
extension methods alleviate the million helper classes that non-trivial
apps
tend to have.
Huh? You don't get rid of the helper classes. They're still there. You
just don't have to type the name of them explicitly when you use them.
And since a static extension would still require you to type the name of
_some_ class, why not just type the name of the class where the method is
really defined?
i think saying you can't see a reason for them and therefore shouldn't
have
them is ridiculous.
Well, when you provide an actual example of how a static extension would
be useful, I might change my mind. But I think it's ridiculous for you to
insist that I agree with you before you've proven your point.
I don't mind having my mind changed by a strong argument, but you have to
present that argument first.
why not let the individual developer decide if there is
not a valid reason to omit them? why polute the namespace with a bunch
of
other types when they should be grouped accordingly.
The namespace is already "polluted", even with instance extensions. You
just don't have to type the class name. But it's still there. So that's
not a valid argument in favor of a static extension.
What's left? Making the static method look like it belongs to some other
class (the one you're extending). What's the point of making a static
method look like it belongs to some other class? Other than the name you
type, it will behave _exactly_ as it would if you just used it from your
own class.
With an instance extension, you can really create code that makes it look
like you've added a method to an instance of a given object, and that can
clean up the code a lot. But with a static extension, all you can do is
swap one name for another. How is that useful? Why does it matter to you
so much which exact letters you type when calling a method?
As far as "return by reference" goes...
to not make a copy of the object is the point of returning by ref.
But that's impossible to do with a value type. C# has no syntax for
referring to value types as if they were referenced. Where would that "no
copy of the object" come from? The run-time would essentially have to box
the object, and then provide some sort of new semantic that allows the use
of the object without unboxing it.
But C# already has a semantic for using an object without unboxing it.
It's called reference types. And if you need to use a type in that way,
then a reference type is what you should be using.
In any case, even if you somehow managed to get a "return by reference"
into the language, you'd have to make sweeping changes to the rest of the
language (and likely the run-time) in order to support that change. As
things stand now, if it's a value type, you can't use it without making a
copy of it. This would be true even if you somehow managed to return a
reference to a copy of it.
it would
refer to the object. there are really two benefits to being able to
return
by reference and that is exposing a value type by property.
What does that mean? What does "exposing a value type by property" mean?
I know what the individual words mean, but put together like that they
don't convey any useful information to me.
that is enough
in itself but a more important reason is performance. there's no
appreciable
gain by returning a 4/8 byte pointer rather than a 200 byte object???
If you have an object that's (for example) 200 bytes, it doesn't really
belong in a struct in the first place. You're trying to fix broken code
by breaking something else, rather than just fixing the broken code.
Then, we have your "lazily instantiated" properties...
well theres a reason why automatic properties were introduced and that
is to
reduce boilerplate code.
Let's be clear: it reduces boilerplate code >> that is used on a
remarkably common basis << .
however they really are only useful on primitive
types and tightly controlled scenarios.
How so? They are useful in _any_ situation in which you have a property
that is simply a getter and/or setter for some field. That works with any
type, not just primitives, and it hardly requires that the scenario is
"tightly controlled".
when you find yourself writing the
same code a hundred zillion times (as im sure others have also) then its
time
for a built-in feature (or a way to create one yourself).
If you are writing this sort of "lazily instaniated" property "a hundred
zillion times", you are in a completely unique situation and not one that
justifies a whole new language feature just to support your own personal
problem.
Suffice to say, most programmers write entire applications without ever
having to lazily initialize a field behind a property, and even those that
do only have to do for a handful of properties at most. And even _then_,
in many of those situations a parameterless constructor isn't sufficient
(and may not even be available).
If this sort of thing applies in the vast majority of your code, you have
very unusual code. You might want to look into the "code snippet" feature
of Visual Studio, but otherwise your own needs do not in any way suggest a
need for a new language feature. In the broader scheme of things, code
that does what you're talking about is extremely rare.
Nope, not really.
Yes I believe I said c#/cli features just for this case! The problem, as
i'm sure others have run into many times, is that when you write an app
that
needs to be interpreted in multiple timezones, you need to always store
a utc
value and transmit in utc then interpret for display in the current
timezone.
So? Then do that. Store the data as UTC (which you can do) and then
convert to the local timezone for display (which you can also do). The
latest .NET even provides direct support for converting to timezones other
than the local one (which admittedly was a significant failing in previous
versions).
What feature are you looking for here that doesn't already exist?
Pete
