I'm trying to construct a compelling example of the need for a language
feature, with full support for generics, to introduce all static members and
nested classes of another type into the current name search scope.
i.e. a very simple application would be
class ManyComputations
{
calling System.Math;
... z = Sin(3*x) + Log(y); // qualifiers not needed
}
This provides a superset of the "inherit from a static class" concept,
without actually using inheritance or conflicting with "sealed".
All C# experts are invited to join the discussion over in
microsoft.public.dotnet.languages.vc in the thread titled "howto decouple in
..NET?" Some familiarity with C++/CLI is a definite plus.
Thanks.
49  5753 
Ben Voigt [C++ MVP] <rb*@nospam.nospamwrote:
I'm trying to construct a compelling example of the need for a language
feature, with full support for generics, to introduce all static members and
nested classes of another type into the current name search scope.
i.e. a very simple application would be
class ManyComputations
{
calling System.Math;
... z = Sin(3*x) + Log(y); // qualifiers not needed
}
This provides a superset of the "inherit from a static class" concept,
without actually using inheritance or conflicting with "sealed".
Because it's not actually inheritance, I'd try to avoid using the term
wherever possible.
All C# experts are invited to join the discussion over in
microsoft.public.dotnet.languages.vc in the thread titled "howto decouple in
.NET?" Some familiarity with C++/CLI is a definite plus.
I'll see if I've got time to join in.
One reason MS *might* want to do it - Java has it :)
The syntax used is quite nice, too - static import. The equivalent
would be static using:
static using System.Math;
I wouldn't suggest doing it within a class though - I'd put it with the
rest of the using statements.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..
Ben Voigt [C++ MVP] <rb*@nospam.nospamwrote:
>I'm trying to construct a compelling example of the need for a language
feature, with full support for generics, to introduce all static members
and
nested classes of another type into the current name search scope.
i.e. a very simple application would be
class ManyComputations
{
calling System.Math;
... z = Sin(3*x) + Log(y); // qualifiers not needed
}
This provides a superset of the "inherit from a static class" concept,
without actually using inheritance or conflicting with "sealed".
Because it's not actually inheritance, I'd try to avoid using the term
wherever possible.
>All C# experts are invited to join the discussion over in
microsoft.public.dotnet.languages.vc in the thread titled "howto decouple
in
.NET?" Some familiarity with C++/CLI is a definite plus.
I'll see if I've got time to join in.
One reason MS *might* want to do it - Java has it :)
The syntax used is quite nice, too - static import. The equivalent
would be static using:
static using System.Math;
I wouldn't suggest doing it within a class though - I'd put it with the
rest of the using statements.
Oh, it has to be available in a class. Absolutely positively. But I've
already explained why in the other group. That's not to say it wouldn't be
nice if it also worked at namespace scope.
>
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Ben Voigt [C++ MVP] <rb*@nospam.nospamwrote:
I wouldn't suggest doing it within a class though - I'd put it with the
rest of the using statements.
Oh, it has to be available in a class. Absolutely positively. But I've
already explained why in the other group. That's not to say it wouldn't be
nice if it also worked at namespace scope.
It looks like we're talking about *completely* different things. The
example you gave of being able to use the Sin and Log methods without
further qualification are very different from the desires you have in
expressed in the VC group, as far as I understand them (which isn't
terribly far).
For the purposes of making static members from one type available in
another type without qualification, adding the capability to using
statements is fine.
I'm not *entirely* sure what you're asking for in the VC group, but it
seems to extend *way* past that.
I think it would be a much more fruitful discussion here than in the
C++ group - and more on-topic too, if you're suggesting a C# feature
rather than a C++ feature.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Chris Mullins [MVP] <cm******@yahoo.comwrote:
For the purposes of making static members from one type available in
another type without qualification, adding the capability to using
statements is fine.
As I pointed out in the C++ thread, C# 3.0 does have this exact feature -
they're called Extension Methods.
http://blogs.msdn.com/abhinaba/archi...15/467926.aspx
http://msdn2.microsoft.com/en-us/lib...cs3spec_topic3
It's not that *exact* feature. For one thing, it doesn't apply to
existing methods. For another, it makes them appear to be instance
methods. I certainly wouldn't want to call x.Sin() + y.Cos() in my code
- I'd much rather be able to use Cos(x) + Sin(y).
It may well go part of the way though, in many cases.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Chris Mullins [MVP]" <cm******@yahoo.comwrote in message
news:O9**************@TK2MSFTNGP02.phx.gbl...
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote:
>Ben Voigt [C++ MVP] <rb*@nospam.nospamwrote:
>For the purposes of making static members from one type available in
another type without qualification, adding the capability to using
statements is fine.
As I pointed out in the C++ thread, C# 3.0 does have this exact feature -
they're called Extension Methods.
Your post in the C++ thread got recalled before I could look at it. I was
looking forward to hearing your input, too.
>
http://blogs.msdn.com/abhinaba/archi...15/467926.aspx
http://msdn2.microsoft.com/en-us/lib...cs3spec_topic3
--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote
Your post in the C++ thread got recalled before I could look at it. I was
looking forward to hearing your input, too.
My post got recalled? How... unexpected. I wonder how that happened.
I can see it in Google Groups, for what it's worth...
--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP http://www.coversant.com/blogs/cmullins
"Jon Skeet [C# MVP]" <sk***@pobox.comschrieb
The equivalent
would be static using:
static using System.Math;
Hi Jon,
why the keyword static here, why not simply:
using System.Math;
Christof
On Jun 6, 8:07 am, "Christof Nordiek" <c...@nospam.dewrote:
"Jon Skeet [C# MVP]" <s...@pobox.comschriebThe equivalent
would be static using:
static using System.Math;
why the keyword static here, why not simply:
using System.Math;
I suppose that would be okay in C# (in Java you can individually
import classes, not just packages). However, given that it's not doing
*quite* the same thing as normal using directive, I think I'd prefer
the extra "static" to make it more obvious to the reader. If you're
dealing with some unfamiliar libraries, it may not be immediately
clear whether a particular name is a namespace or a class.
Jon
Ben Voigt [C++ MVP] wrote:
I'm trying to construct a compelling example of the need for a
language feature, with full support for generics, to introduce all
static members and nested classes of another type into the current
name search scope.
i.e. a very simple application would be
class ManyComputations
{
calling System.Math;
... z = Sin(3*x) + Log(y); // qualifiers not needed
}
This provides a superset of the "inherit from a static class"
concept, without actually using inheritance or conflicting with
"sealed".
All C# experts are invited to join the discussion over in
microsoft.public.dotnet.languages.vc in the thread titled "howto
decouple in .NET?" Some familiarity with C++/CLI is a definite plus.
I agree with Jon, THIS is the C# newsgroup and C# discussions should
be held here. We already have a truckload of offtopic (i.e. which are
more about .NET than C#) discussions here so more ONtopic discussion
here would be great ;)
What you're suggesting is IMHO running into problems very quickly.
With 'Sin' and 'Cos' you might not have duplicates in scope, but what
if you have?
Furthermore, the necessity which makes you want what you're suggesting
is the friction between procedural programming and OO programming: math
methods and calculation methods are typical procedural
methods/routines, which don't really fit into the OO paradigm, unless
you'd add Sin() as a method of an int or double for example.
As the language and framework (C#, .NET) are OO, the routines have to
be placed inside a class. To refer to the methods you now have to
specify in which class they're in. This can be a bit odd at first,
because you just want to call a routine like we all did in C or Pascal
and in these languages you also didn't have to specify in which file
the routine was in, it was just there as long as you'd #include the
header file.
However, if you would go the route of 'if I have included / imported a
header/namespace with solely routines and no classes, I should be able
to call them without specifying their location', you effectively
breaking down the OO nature of C# and will introduce what C++ also has:
a way to program C-style code, without classes.
Personally I think every static method has to be specified with the
class it's in. This is for clarity which method is called (so the
reader of the code can easily understand which method is called, a big
helper in getting bug rates down) and also to avoid duplicate names.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
"Frans Bouma [C# MVP]" <pe******************@xs4all.nlschrieb
What you're suggesting is IMHO running into problems very quickly.
With 'Sin' and 'Cos' you might not have duplicates in scope, but what
if you have?
This wouldn't be a new problem to C#. Even now using directives can import
duplicate names, in wich cases you have to use the full quailified name to
make a distinction. Or you can use using alias directives to explicitly give
different names to them.
The rules of resolving simple names would remain the same or could easily
extended.
Christof
On Jun 6, 9:21 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
<snip>
What you're suggesting is IMHO running into problems very quickly.
With 'Sin' and 'Cos' you might not have duplicates in scope, but what
if you have?
Then you generate a compile-time error saying that you've got to
disambiguate.
Furthermore, the necessity which makes you want what you're
suggesting is the friction between procedural programming and OO
programming: math methods and calculation methods are typical
procedural methods/routines, which don't really fit into the OO paradigm,
unless you'd add Sin() as a method of an int or double for example.
So what do you suggest to make life nicer for those who are doing a
*lot* of trigonometry etc in code?
When used sparingly, it can really improve things IMO. Yes, it goes
against the OO nature of C#, but not everything is cleanly expressed
in OO terms.
Jon
"Frans Bouma [C# MVP]" <pe******************@xs4all.nlschrieb
>
Furthermore, the necessity which makes you want what you're suggesting
is the friction between procedural programming and OO programming: math
methods and calculation methods are typical procedural
methods/routines, which don't really fit into the OO paradigm, unless
you'd add Sin() as a method of an int or double for example.
I'm not sure, what you want to say by this. Do you mean OO-languages
shouldn't have static methods at all?
BTW What you suggest would reduce the use of the method. I would have to
explicitly cast an int to double to call the sinus of it, or there had to be
a special version of Sin() in the int class, wich internally would only cast
int to double and call Sin(double).
Christof
However, if you would go the route of 'if I have included / imported a
header/namespace with solely routines and no classes, I should be able
to call them without specifying their location', you effectively
breaking down the OO nature of C# and will introduce what C++ also has:
a way to program C-style code, without classes.
I call shenanigans on your statement that this is anti-OOP. Consider:
public interface IDataLayer
{
DataSet GetProducts();
...
}
public partial class BusinessLayer <DataLayer>
where DataLayer : IDataLayer
{
}
public partial class BusinessLayer <DataLayer>
{
public class DiscountRules
{
...
}
}
public partial class BusinessLayer <DataLayer>
{
public class Reporting
{
...
}
}
public partial class ShoppingCartUI<DataLayer, LookAndFeel>
where DataLayer : IDataLayer
where LookAndFeel : IPageFormatter
{
static using BusinessLayer<DataLayer>;
public class NavigationMenu
{
delegate void NavButtonHandler(UIManager sender, NavigateEventArgs e);
event NavButtonHandler NavigateViewCart;
event NavButtonHandler NavigateAccountManagement;
event NavButtonHandler NavigateSystemManagement;
// use DiscountRules and Reporting without further qualification
}
public class UIManager
{
public DataLayer GetDataLayer() { ... }
NavigationMenu NavMenu;
}
}
public class LocalDataLayer : IDataLayer
{
// GetProducts()
...
void BackupNow();
void ReplayLogs();
void Vaccuum();
}
public class LocalAdminUI
{
static using BusinessLayer<LocalDataLayer>; // needs reporting logic
static using ShoppingCartUI<LocalDataLayer>;
static void ShowAuthenticationScreen(UIManager sender, NavigateEventArgs
e) { ... }
}
public class Configuration
{
static using BusinessLayer<LocalDataLayer>;
static using ShoppingCartUI<LocalDataLayer>;
void main()
{
UIManager uim = new UIManager();
uim.NavMenu.NavigateSystemManagement +=
LocalAdminUI.ShowAuthenticationScreen;
}
}
Now, although ShoppingCartUI and BusinessLayer don't need to know
implementation details about the data layer,
ShoppingCartUI<>.UIManager.GetDataLayer() passes a strongly-typed
LocalDataLayer which the LocalAdminUI can use to trigger a database backup,
vaccuum, etc. ShoppingCartUI and BusinessLayer would be just as happy with
a ClusteredDataLayer or WebServicesDataLayer, etc.
Ok, this isn't the best example, because the DataLayer is probably a
singleton with a long lifetime and you could just keep a reference to it in
the LocalAdminUI. But what about more classes. Consider the case where an
error event is raised because a database query failed. The handler for that
may need to go well beyond the public interface of the request in order to
perform error analysis, yet getting an adapter class created and subscribed
to the error event for each and every request created isn't necessarily
feasible. Ok you say, just do a runtime cast to get the more detailed
interface. Bad idea. You've lost compile-time static checking -- in the
error handling path, where runtime errors are likely to go unnoticed for the
longest time. Change to a different request class, and the error handler
still happily passes the unit tests against the old mock object, but now
causes a disaster at runtime at the worst possible time -- when you already
had an error you desperately need information about.
And for my system, which has nothing to do with products or shopping carts
or RDBMS, there are quite a few detectable concerns which need to be kept
loosely coupled but all work on the same object tree. A language feature to
import non-instance members into the name search space would be a huge help.
Christof Nordiek wrote:
"Frans Bouma [C# MVP]" <pe******************@xs4all.nlschrieb
Furthermore, the necessity which makes you want what you're
suggesting is the friction between procedural programming and OO
programming: math methods and calculation methods are typical
procedural methods/routines, which don't really fit into the OO
paradigm, unless you'd add Sin() as a method of an int or double
for example.
I'm not sure, what you want to say by this. Do you mean OO-languages
shouldn't have static methods at all?
They can come in handy, but static methods are sort of a hack as well
when it comes to pure OO in a language: they give you a way to specify
procedural code in an OO language without having to instantiate an
object to call a method.
A typical example is a very simple set of routines, namely Add(int,
int) and Substract(int, int). These routines take 2 numbers and work
their logic on them.
You could argue that they should be placed in a 'Calculator' class
however, the methods itself don't work on the calculator's data, the
calculator class is actually a container to be able to compile the 2
routines, because Add and Substract are actually just routines which
work on the input and produce a single value as output.
Now, one could bicker over whether this example is a good one or not,
but that's besides the point. The point I'm trying to make is that
there is a friction between OO and procedural: you can't always express
everything in classes the way you WANT TO: sometimes procedural code is
just more convenient. However, to ALLOW that, you effectively have to
open up the language to allow 'modules' with routines which don't
belong to any class, they're just forming a library of routines you can
call.
In C#, this 'Module' idea is implemented as a class with static
methods. The suggestion now is to drop the static class and simply
allow a module with routines as that's what the end result will look
like.
I find the class with static methods not pretty, but it has an
advantage over a bucket with routines forming a library: the class name
gives the reader hints where the method is implemented:
Calculator.Add() might be hurting for the eye when it comes to true OO,
however it's IMHO better than having 'Add()' alone, and the reader then
has to GUESS in which module Add is implemented.
BTW What you suggest would reduce the use of the method. I would have
to explicitly cast an int to double to call the sinus of it, or there
had to be a special version of Sin() in the int class, wich
internally would only cast int to double and call Sin(double).
Though, ask yourself this: why do we place in one situation the method
working on a class' data IN the class the data is contained in and in
another situation we want to place the method OUTSIDE the class the
data is contained in? 10.Cos() might look weird, I agree, but
logically, it is something in line with "foo123".Substring(2);
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Ben Voigt [C++ MVP] wrote:
However, if you would go the route of 'if I have included /
imported a header/namespace with solely routines and no classes, I
should be able to call them without specifying their location', you
effectively breaking down the OO nature of C# and will introduce
what C++ also has: a way to program C-style code, without classes.
I call shenanigans on your statement that this is anti-OOP. Consider:
Listen, Ben. If you want a discussion about this, you shouldn't pull
things like this. I've better things to do than join a mud fest in some
random newsgroup. I just gave an honest opinion which is also shared
among a lot of C++ developers: a lot of C++ developers want the C-style
coding constructs out of C++. There are also a lot of C++ developers
who think the opposite. All fine, but don't call my argumentation cheap
tricks, because then I'm definitely done here, OK?
A set of routines which are solely procedural (i.e. you can copy /
paste them into a C program and it works (minor syntax crap ignored),
isn't what OO is all about so if you WANT THAT in an OO program, the
language has to have a construct for that. C# has static methods for
that. It's not great, IMHO, but it gives the oppertunity to add
procedural routines which don't work on a class' internal members to a
C# program.
[snip]
Ok, this isn't the best example, because the DataLayer is probably a
singleton with a long lifetime and you could just keep a reference to
it in the LocalAdminUI. But what about more classes. Consider the
case where an error event is raised because a database query failed.
The handler for that may need to go well beyond the public interface
of the request in order to perform error analysis, yet getting an
adapter class created and subscribed to the error event for each and
every request created isn't necessarily feasible. Ok you say, just
do a runtime cast to get the more detailed interface. Bad idea.
You've lost compile-time static checking -- in the error handling
path, where runtime errors are likely to go unnoticed for the longest
time. Change to a different request class, and the error handler
still happily passes the unit tests against the old mock object, but
now causes a disaster at runtime at the worst possible time -- when
you already had an error you desperately need information about.
I'm not an expert on your system so I see not a real relevance to the
point you're trying to make.
And for my system, which has nothing to do with products or shopping
carts or RDBMS, there are quite a few detectable concerns which need
to be kept loosely coupled but all work on the same object tree. A
language feature to import non-instance members into the name search
space would be a huge help.
Though why not specify the class in which the method is defined in
front of the method? Math.Cos() instead of Cos() ?
I don't see the relevance of leaving out 'Math' here. And no, I've
never had the need for calling a static method somewhere but at the
point I'd like to call the static method I didn't know which one.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Jon Skeet [C# MVP] wrote:
On Jun 6, 9:21 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
<snip>
What you're suggesting is IMHO running into problems very
quickly. With 'Sin' and 'Cos' you might not have duplicates in
scope, but what if you have?
Then you generate a compile-time error saying that you've got to
disambiguate.
When I'm reading code, all I can HOPE for is that I understand that
'Cos' is in 'Math'. It's about clarity.
>
Furthermore, the necessity which makes you want what you're
suggesting is the friction between procedural programming and OO
programming: math methods and calculation methods are typical
procedural methods/routines, which don't really fit into the OO
paradigm, unless you'd add Sin() as a method of an int or double
for example.
So what do you suggest to make life nicer for those who are doing a
*lot* of trigonometry etc in code?
I was making a hypothetical example that it is (to me at least) rather
odd that some methods are in classes they work on, and others are in
separate classes. We all do that, putting procedural methods together
in static classes and make the methods static, simply because the
methods have no real type they work on, they're procedural.
When used sparingly, it can really improve things IMO. Yes, it goes
against the OO nature of C#, but not everything is cleanly expressed
in OO terms.
I agree OO has limits in expressiveness, especially when you need
procedural expressiveness. However EVERY degration in readability of
code, i.e. any degration of clarity, is IMHO the worse thing that can
happen to a language. that's also why I find things like 'yield' and
also delegates to some extend language constructs which should be used
with care and only there when you can't do something else. they break
down clarity of the code: "Ok, this calls a delegate, where does the
code end up now?" These kind of things should be clear, at least as
clear as possible: when a programmer doesn't understand the code s/he
reads in full without errors, s/he can't write 100% bugfree code.
Simply importing methods and calling them as if they're methods of the
class they're called in, is decreasing the clarity of the code, IMHO
and also makes it possible to program procedural applications. I know
that at times we all just want to have a main routine with some code
and that's it, but one then should pick another language.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
On Jun 7, 9:14 am, "Frans Bouma [C# MVP]"
<snip>
10.Cos() might look weird, I agree, but
logically, it is something in line with "foo123".Substring(2);
I was going to reply to your response to me, but this is actually the
best example I've seen. As you said elsewhere, readability is vital.
It's more important (to me) than the logic of the thing. I would far
rather read:
double dist = Sqrt (x*x+y*y);
than either of
double dist = (x*x+y*y).Sqrt();
double dist = Math.Sqrt(x*x+y*y);
and likewise I'd much rather read
double foo = Cos(theta) + Sin(alpha);
than
double foo = theta.Cos() + alpha.Sin();
double foo = Math.Cos(theta) + Math.Sin(alpha);
Do you genuinely believe that either the instance method version or
the static method version including the class name conveys the
intention of the code more simply than my preferred version?
Yes, you may occasionally want to use Intellisense to confirm which
class a method actually belongs to - although I'd say that when used
sparingly, it should always be obvious anyway. That productivity
decrease is easily matched by the improvement of readability in cases
like the above.
Could it be used stupidly? Yes. Can it also vastly improve the
readability of certain cases, particularly maths? Absolutely.
Jon
[snip]
Though why not specify the class in which the method is defined in
front of the method? Math.Cos() instead of Cos() ?
Don't you mean global::System.Math.Cos()? Or do also you see a need for not
always using the fully-qualified name?
You've missed my entire point that class members don't all fall into the
categories of (instance method/field/property/event) and (static
method/field/property/event). There are also nested classes, and these are
quite possibly a more important use of the feature than all others combined.
So even in a pure OO environment, where everything is a class, there is
still value in adding class members to the search scope.
There is a huge need for being able to omit or shorten the name of the
containing class, whether you are referring to a member field, event,
property, method, or class. Specifically, when the parent class name is
quite long, which is quite common in the presence of generics. And, the
existing "using" (alias) directive cannot be used inside a class, so it
doesn't fully support generics.
Here is a really quick example of the shortcomings of the existing "using"
directive:
Non-generic:
class LinkedListNode { ... }
using Node = LinkedListNode; // of dubious value, not saving much typing
class LinkedList { /* use Node here */ }
Generic:
class LinkedListNode<TValue{ ... }
using Node = LinkedListNode<TValue>; // error, not in scope of TValue
class LinkedList<TValue>
{
using Node = LinkedListNode<TValue>; // error: here TValue is available,
but the using directive isn't allowed
/* use Node here */
}
I find the class with static methods not pretty, but it has an
advantage over a bucket with routines forming a library: the class name
gives the reader hints where the method is implemented:
Calculator.Add() might be hurting for the eye when it comes to true OO,
however it's IMHO better than having 'Add()' alone, and the reader then
has to GUESS in which module Add is implemented.
Then you'd better outlaw "using namespace". After all, how can you know
what constructor "new Timer()" calls?
Oh, yes, you would look at the using namespace directives at the top of the
file or namespace. And with this suggested feature, you would also look at
the "using static" directives at the top of the file, namespace, or class,
to determine where 'Add()' came from.
Could it be used stupidly? Yes. Can it also vastly improve the
readability of certain cases, particularly maths? Absolutely.
And I've proposed another case that I think it would be extremely useful
for:
In order to share generic parameters between a family of classes, they need
to be nested within a generic class. But then you can't access them all
with using namespace, so you're left with a long, ugly qualifier including
the generic type arguments. "using static" could resolve this issue quite
neatly.
Imagine that the generic collections, instead of living in
System.Collections.Generic namespace, all lived in a generic class. Or at
least all the 1-D collections did. Then the data access layer for Customer
could declare "using static Collection<Customer>;" and then refer to
type-safe List, SortedList, IList, ICollection everywhere without
respecifying the generic argument everywhere as well. Maybe a map of string
to Customer should really be "Collection<Customer>.HashMap<string>".
Ben Voigt [C++ MVP] <rb*@nospam.nospamwrote:
Could it be used stupidly? Yes. Can it also vastly improve the
readability of certain cases, particularly maths? Absolutely.
And I've proposed another case that I think it would be extremely useful
for:
In order to share generic parameters between a family of classes, they need
to be nested within a generic class. But then you can't access them all
with using namespace, so you're left with a long, ugly qualifier including
the generic type arguments. "using static" could resolve this issue quite
neatly.
Imagine that the generic collections, instead of living in
System.Collections.Generic namespace, all lived in a generic class. Or at
least all the 1-D collections did. Then the data access layer for Customer
could declare "using static Collection<Customer>;" and then refer to
type-safe List, SortedList, IList, ICollection everywhere without
respecifying the generic argument everywhere as well. Maybe a map of string
to Customer should really be "Collection<Customer>.HashMap<string>".
Hmmm... I can't say I can see the benefit of that at the moment. I
haven't been able to really follow your other examples in the C++ group
(partly due to the C++ references, partly due to not having enough time
to really go over them for long periods, I'm afraid). I can see the
benefit of *simple* static inclusions, but I'm not sure beyond that.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com>
and likewise I'd much rather read
double foo = Cos(theta) + Sin(alpha);
than
double foo = theta.Cos() + alpha.Sin();
Shouldn't that be:
double foo = theta.Cos().Add(alpha.Sin());
in 'pure' OO ;-)
Christof
Jon Skeet [C# MVP] wrote:
On Jun 7, 9:14 am, "Frans Bouma [C# MVP]"
<snip>
10.Cos() might look weird, I agree, but
logically, it is something in line with "foo123".Substring(2);
I was going to reply to your response to me, but this is actually the
best example I've seen. As you said elsewhere, readability is vital.
It's more important (to me) than the logic of the thing. I would far
rather read:
double dist = Sqrt (x*x+y*y);
than either of
double dist = (x*x+y*y).Sqrt();
double dist = Math.Sqrt(x*x+y*y);
and likewise I'd much rather read
double foo = Cos(theta) + Sin(alpha);
than
double foo = theta.Cos() + alpha.Sin();
double foo = Math.Cos(theta) + Math.Sin(alpha);
I'm raised with assembler and C, when I was at the uni we didn't get
OO languages, just a lot of other paradigms. All nice but not OO.
Reading your examples, I have to admit:
double dist = Sqrt(x*x + y*y);
fits like a glove, I really like it because it's so familiar, as I've
written and read code like that for years and years.
What I want to make clear here is that it apparently seems that I am
actively PROMOTING 10.Sqrt();, but I'm not. I'm just arguing that
theoretically, it would be more OO. Not that that would be BETTER
necessarily.
Just because the code reads like old code from the good ol' times,
doesn't make it FIT in the surrounding code it is placed in,
necessarily. So if the surrounding code is pure OO code, it feels like
a friction to have code like
double dist = Sqrt(x*x + y*y);
The main reason is that the general paradigm is that 'Sqrt' here is a
method of the class this line is in. But that's not the case in the TS'
proposal.
This thus clashes, IMHO. By proceeding with what TS's proposes, you
create ambiguity in the language for the reader of the code. I then
argue: you shouldn't proceed with this, as it is a degration of
readability (== reader understands what's written).
My argument was a bit ripped apart, perhaps because I didn't structure
it well enough, but what I argued was that the REASON the static
methods are there is because of the friction between OO and procedural
and you could solve it in two ways: move the method to the class which
instance holds the data the method works on (the dreaded 10.Sqrt()) or
use it as static methods, which is IMHO still some sort of hack.
I personally agree with your examples, but not because I find them
formulate better constructs, but because they feel more closer to what
I have been reading/writing for a long time, more familiar.
However merging that with an OO language gives IMHO more problems than
it solves, so I can't agree with the proposal of TS, on the contrary.
Do you genuinely believe that either the instance method version or
the static method version including the class name conveys the
intention of the code more simply than my preferred version?
Yes, because the preferred version clashes with
SomeType t = ClassMethod(val);
when we see this kind of code in a C# class, we KNOW that
'ClassMethod' is either in this class or in its supertype. It's not a
class defined elsewhere.
Yes, you may occasionally want to use Intellisense to confirm which
class a method actually belongs to - although I'd say that when used
sparingly, it should always be obvious anyway. That productivity
decrease is easily matched by the improvement of readability in cases
like the above.
IMHO any reliance on intellisense for readability of code is bad,
because code should be clear from its construction, not because you
have fancy tools at hand. The next step will be that 'code is perfectly
clear if you have resharper x.y, coderush vZ etc. installed and setup
like user ABC.'.
Could it be used stupidly? Yes. Can it also vastly improve the
readability of certain cases, particularly maths? Absolutely.
As I see 'readability' as the term for: the reader understands what's
been written perfectly, I don't really see how
double d = Math.Sqrt(val);
is less readable than
double d = Sqrt(val);
simply because Math.Sqrt() tells the reader which Sqrt is called: the
one in the Math class. Simply calling Sqrt() is less clear, because it
could be in the class or supertype OR it could (if TS' suggestion is
added) somewhere in the classes of the scope data imported by the using
statements. IMHO not a thing you'd want to have. (Sqrt is pretty
obvious what it does, a simple thing, but a method which is pretty
complex and will call a lot of other methods, it's not that clear).
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Ben Voigt [C++ MVP] wrote:
I find the class with static methods not pretty, but it has an
advantage over a bucket with routines forming a library: the class
name gives the reader hints where the method is implemented:
Calculator.Add() might be hurting for the eye when it comes to true
OO, however it's IMHO better than having 'Add()' alone, and the
reader then has to GUESS in which module Add is implemented.
Then you'd better outlaw "using namespace". After all, how can you
know what constructor "new Timer()" calls?
Oh, yes, you would look at the using namespace directives at the top
of the file or namespace. And with this suggested feature, you would
also look at the "using static" directives at the top of the file,
namespace, or class, to determine where 'Add()' came from.
So, because that set of using statements makes it already less clear,
you're perfectly OK with making it VERY unclear for the reader with
further scope increases?
double d = Sqrt(foo);
where does 'Sqrt(foo)' live? I have NO idea. Sure, with fancy tooling
I might find the place where this is. But reliance on tooling to READ
and UNDERSTAND code is IMHO a slippery slope I at least don't want to
be on. Code should be understandable and clear for the reader who reads
it. ANY degration to that is IMHO bad. Sure your suggestion might save
a few keystrokes, but it also introduces degration of the clarity of
code written. I simply fail to understand how you can ignore that fact.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
On Jun 8, 9:37 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
<snip>
So, because that set of using statements makes it already less clear,
you're perfectly OK with making it VERY unclear for the reader with
further scope increases?
double d = Sqrt(foo);
where does 'Sqrt(foo)' live? I have NO idea.
Do you *really* have no idea, in real life rather than in theory?
Would you not *guess* that it was in System.Math, given no other
information, and considering the context?
Sure, with fancy tooling
I might find the place where this is. But reliance on tooling to READ
and UNDERSTAND code is IMHO a slippery slope I at least don't want to
be on. Code should be understandable and clear for the reader who reads
it. ANY degration to that is IMHO bad. Sure your suggestion might save
a few keystrokes, but it also introduces degration of the clarity of
code written. I simply fail to understand how you can ignore that fact.
We apparently view clarity differently. If I'm working on something
which I know from the context uses trigonometry, then formulae which
just have things like:
double x = Pow(Sin(alpha)+Cos(theta), 2);
have more clarity for me than formulae such as:
double x = Math.Pow(Math.Sin(alpha)+Math.Cos(theta), 2);
Have you read much C# code that requires extensive use of System.Math?
It's horrible currently, and would *greatly* benefit from this. The
ambiguity due to the *possibility* of Cos/Sin/Pow etc is greatly
dwarfed by the *guaranteed* extra cruft of having to prefix everything
with "Math".
Jon
Ben Voigt [C++ MVP] wrote:
[snip]
Though why not specify the class in which the method is defined in
front of the method? Math.Cos() instead of Cos() ?
Don't you mean global::System.Math.Cos()? Or do also you see a need
for not always using the fully-qualified name?
I write a lot of C# code and I've never ever have to use global::. I
also hardly have to use full qualified namespaces in front of types.
Perhaps I write code no-one else writes, but that's my experience.
You've missed my entire point that class members don't all fall into
the categories of (instance method/field/property/event) and (static
method/field/property/event). There are also nested classes, and
these are quite possibly a more important use of the feature than all
others combined. So even in a pure OO environment, where everything
is a class, there is still value in adding class members to the
search scope.
So, you suggest this kind of code is good?
public class Foo
{
private Bar _bar;
private string _val;
private class Bar
{
private Foo _container;
internal Bar(Foo container)
{
_container = container;
}
public string GetVal()
{
return "Bar" + _container._val;
}
}
public Foo()
{
_bar = new Bar(this);
_val = "Foo";
}
public string Do()
{
return _bar.GetVal();
}
}
where bar accesses private members of Foo?
why go that route? Isn't that asking for trouble? Sure, it's possible
but why not create properties and access Foo's code through that? It's
not as if Bar is placed elsewhere, the code is inside Foo anyway.
Sure, in these kind of cross-referencing code, just having to refrence
to '_val' instead of _container._val, can be less typing, but I find it
obscure. Just because a nested type is inside the surrounding type
doesn't make the code (IMHO) semantically part of the surrounding type.
At least, I find it leaky. Sure it's possible, but that doesn't make it
more readable.
There is a huge need for being able to omit or shorten the name of
the containing class, whether you are referring to a member field,
event, property, method, or class. Specifically, when the parent
class name is quite long, which is quite common in the presence of
generics. And, the existing "using" (alias) directive cannot be used
inside a class, so it doesn't fully support generics.
using the keyword 'using' just to save some keystrokes is IMHO not the
way to go. Similar to what some people think is logical to use typedefs
all over the place just because it makes the code mode 'readable' to
them.. :X
A program's control flow can be controlled with a lot of delegates. It
will work, and probably be 'very' flexible. THe downside is that
readability (== the reader understands what's written and going on)
goes out the window, simply because the only way to understand what the
code does is stepping through it in a debugger. well.. Hurray... :-/
Here is a really quick example of the shortcomings of the existing
"using" directive:
Non-generic:
class LinkedListNode { ... }
using Node = LinkedListNode; // of dubious value, not saving much
typing
class LinkedList { /* use Node here */ }
Generic:
class LinkedListNode<TValue{ ... }
using Node = LinkedListNode<TValue>; // error, not in scope of TValue
class LinkedList<TValue>
{
using Node = LinkedListNode<TValue>; // error: here TValue is
available, but the using directive isn't allowed /* use Node here
*/ }
using 'using' in this kind of code is IMHO only useful if you can
reword a type to another name, like when the same piece of code has to
use be compiled against two different oracle providers (ODP.NET and MS
Oracle client) and the only difference is the enum type name with the
type definitions to create parameters for example. then using the same
code with both providers can save a lot of time in maintenance.
Because, often people forget what the biggest pile of work is with a
piece of software: maintenance. Software maintenance will become
horrible the more readability and clarity of the code goes out the
window. Redefinining type names with using is IMHO doing that, unless
you can't otherwise. To do it just by 'saving some typing' is IMHO not
an excuse to introduce it, simply because where does it end? ANd will
maintainability be BETTER after it? I seriously doubt it will.
We soon reach the point where there will be more software applications
on this planet than engineers to maintain them. Introducing more
problems for maintainability is IMHO only increasing that problem we're
soon facing.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
On Jun 8, 9:33 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
<snip>
I'm raised with assembler and C, when I was at the uni we didn't get
OO languages, just a lot of other paradigms. All nice but not OO.
Reading your examples, I have to admit:
double dist = Sqrt(x*x + y*y);
fits like a glove, I really like it because it's so familiar, as I've
written and read code like that for years and years.
It's not just in code though - it's in anywhere you might see formulae
written down. Yes, there's be a square root sign instead of Sqrt, but
that translation is relatively unintrusive.
What I want to make clear here is that it apparently seems that I am
actively PROMOTING 10.Sqrt();, but I'm not. I'm just arguing that
theoretically, it would be more OO. Not that that would be BETTER
necessarily.
I don't think anyone's arguing that "static using" would make C# more
OO, just that it would make life better in some situations -
specifically when writing math-intensive code.
Just because the code reads like old code from the good ol' times,
doesn't make it FIT in the surrounding code it is placed in,
necessarily.
It's not that it reads like old code, it's that it reads like a
formula you might see in a book.
I've recently been using the Haversine formula to calculate distances.
It's described at http://en.wikipedia.org/wiki/Haversine_formula
The C# code to calculate it is hard to verify as accurately
representing the formulae described on the page, because there's so
much extra cruft involved.
Maths code frequently represents implementations of formulae written
down elsewhere. The ease of *that* translation is often more important
to me than the OO purity of the resulting code.
Unless you propose that the maths world starts becoming OO as well,
there will always be a tension - but in my experience the code is
easier to read by sacrificing the OO-ness in order to make the code
look closer to the written form.
Do you genuinely believe that either the instance method version or
the static method version including the class name conveys the
intention of the code more simply than my preferred version?
Yes, because the preferred version clashes with
SomeType t = ClassMethod(val);
when we see this kind of code in a C# class, we KNOW that
'ClassMethod' is either in this class or in its supertype. It's not a
class defined elsewhere.
Only because "static using" isn't an option at the moment! Yes, if
this were overused it would be horrible - but in the specific case of
using it for maths, I don't believe there's a problem at all. How many
Sin and Cos methods have you written?
Yes, you may occasionally want to use Intellisense to confirm which
class a method actually belongs to - although I'd say that when used
sparingly, it should always be obvious anyway. That productivity
decrease is easily matched by the improvement of readability in cases
like the above.
IMHO any reliance on intellisense for readability of code is bad,
because code should be clear from its construction, not because you
have fancy tools at hand. The next step will be that 'code is perfectly
clear if you have resharper x.y, coderush vZ etc. installed and setup
like user ABC.'.
So as Ben suggested, you don't use any using statements at all? Do you
find *they* reduce readability? If not, why not? They introduce
exactly the same sort of potential ambiguity, so why would you reject
"using static" but accept a normal "using"?
Could it be used stupidly? Yes. Can it also vastly improve the
readability of certain cases, particularly maths? Absolutely.
As I see 'readability' as the term for: the reader understands what's
been written perfectly, I don't really see how
double d = Math.Sqrt(val);
is less readable than
double d = Sqrt(val);
Everywhere I've ever used Sqrt, it's obvious from the context that I'm
interested in maths functionality. The more extraneous information
that's present, the harder it is to read the code.
simply because Math.Sqrt() tells the reader which Sqrt is called: the
one in the Math class. Simply calling Sqrt() is less clear, because it
could be in the class or supertype OR it could (if TS' suggestion is
added) somewhere in the classes of the scope data imported by the using
statements. IMHO not a thing you'd want to have. (Sqrt is pretty
obvious what it does, a simple thing, but a method which is pretty
complex and will call a lot of other methods, it's not that clear).
Which is why you'd have to use it sparingly, of course. I'd rarely use
it outside System.Math, although in Java I found some other uses which
give DSL-like capabilities rather nicely.
Jon
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@q69g2000hsb.googlegr oups.com...
On Jun 8, 9:37 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
<snip>
> So, because that set of using statements makes it already less
clear,
you're perfectly OK with making it VERY unclear for the reader with
further scope increases?
double d = Sqrt(foo);
where does 'Sqrt(foo)' live? I have NO idea.
Do you *really* have no idea, in real life rather than in theory?
Would you not *guess* that it was in System.Math, given no other
information, and considering the context?
>Sure, with fancy tooling
I might find the place where this is. But reliance on tooling to READ
and UNDERSTAND code is IMHO a slippery slope I at least don't want to
be on. Code should be understandable and clear for the reader who reads
it. ANY degration to that is IMHO bad. Sure your suggestion might save
a few keystrokes, but it also introduces degration of the clarity of
code written. I simply fail to understand how you can ignore that fact.
We apparently view clarity differently. If I'm working on something
which I know from the context uses trigonometry, then formulae which
just have things like:
double x = Pow(Sin(alpha)+Cos(theta), 2);
have more clarity for me than formulae such as:
double x = Math.Pow(Math.Sin(alpha)+Math.Cos(theta), 2);
Have you read much C# code that requires extensive use of System.Math?
It's horrible currently, and would *greatly* benefit from this. The
ambiguity due to the *possibility* of Cos/Sin/Pow etc is greatly
dwarfed by the *guaranteed* extra cruft of having to prefix everything
with "Math".
Plus the fact that if you ever found a bug in System.Math, or needed a
version that cached results, or anything like that, all you would need to do
is change:
using static System.Math;
to
using static MyLib.CachingMath;
and recompile.
While "using static" isn't anti-OOP, the idea that every call-site should
specify exactly what function is called, is. One of the three pillars of
object-oriented programming, polymorphism, is anti-thetical.
>
Jon
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
On Jun 8, 9:33 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
<snip>
> I'm raised with assembler and C, when I was at the uni we didn't
get
OO languages, just a lot of other paradigms. All nice but not OO.
Reading your examples, I have to admit:
double dist = Sqrt(x*x + y*y);
fits like a glove, I really like it because it's so familiar, as I've
written and read code like that for years and years.
It's not just in code though - it's in anywhere you might see formulae
written down. Yes, there's be a square root sign instead of Sqrt, but
that translation is relatively unintrusive.
> What I want to make clear here is that it apparently seems that I
am
actively PROMOTING 10.Sqrt();, but I'm not. I'm just arguing that
theoretically, it would be more OO. Not that that would be BETTER
necessarily.
I don't think anyone's arguing that "static using" would make C# more
OO, just that it would make life better in some situations -
specifically when writing math-intensive code.
Well, I am.
Because nested classes aren't instance members, I'm claiming they should be
visible through static using as well. That allows passing a set of type
parameters to a whole group of classes at once, which I'm also claiming is a
useful application of generics. Everyone thinks of generics in terms of
either avoiding unboxing, or polymorphism, whereas I am trying to make the
point that they can break dependencies even when the generic parameter will
take only one type at runtime. Furthermore, I think generics ought to have
an attribute, that causes the JIT to optimize each version separately for
reference types, just as it already does for value types. There's no reason
that Dictionary shouldn't be able to inline GetHashCode() in a lot of cases.
So, you suggest this kind of code is good?
public class Foo
{
private Bar _bar;
private string _val;
private class Bar
{
private Foo _container;
internal Bar(Foo container)
{
_container = container;
}
public string GetVal()
{
return "Bar" + _container._val;
}
}
public Foo()
{
_bar = new Bar(this);
_val = "Foo";
}
public string Do()
{
return _bar.GetVal();
}
}
where bar accesses private members of Foo?
why go that route? Isn't that asking for trouble? Sure, it's possible
but why not create properties and access Foo's code through that? It's
not as if Bar is placed elsewhere, the code is inside Foo anyway.
Sure, in these kind of cross-referencing code, just having to refrence
to '_val' instead of _container._val, can be less typing, but I find it
obscure. Just because a nested type is inside the surrounding type
doesn't make the code (IMHO) semantically part of the surrounding type.
At least, I find it leaky. Sure it's possible, but that doesn't make it
more readable.
There are cases where that kind of code is definitely called for. The BCL
has all kinds of nested classes, many of which are appropriate. Among other
things, anonymous closures are really nested classes.
The key is to use containment where appropriate.
One use case for "static using" involves nesting a number of classes inside
a generic class which has no private members (possible private classes).
This is similar to a namespace, except (1) you now have a finer level of
local class than "internal", and generics are supported.
Take a look at System.dll. There are a ton of internal classes that would
be much better bound to a tight group of classes that use them and each
other. But that's not possible until we get the same ability to reference
nested classes via using that we currently have for namespace members. (I'm
not suggesting that System.dll would be reorganized, but new code could be
modularized much better).
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:OI*************@TK2MSFTNGP06.phx.gbl...
>So, you suggest this kind of code is good?
public class Foo
{
private Bar _bar;
private string _val;
private class Bar
{
private Foo _container;
internal Bar(Foo container)
{
_container = container;
}
public string GetVal()
{
return "Bar" + _container._val;
}
}
public Foo()
{
_bar = new Bar(this);
_val = "Foo";
}
public string Do()
{
return _bar.GetVal();
}
}
[snip]
There are cases where that kind of code is definitely called for. The BCL
has all kinds of nested classes, many of which are appropriate. Among
other things, anonymous closures are really nested classes.
I meant with the exception of identifiers starting with underscore, which
breaks any reasonable code standard (because any cross-language standard
must reserve those identifiers to the compiler vendor if even one language
does).
Jon Skeet [C# MVP] wrote:
On Jun 8, 9:37 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
<snip>
So, because that set of using statements makes it already
less clear, you're perfectly OK with making it VERY unclear for the
reader with further scope increases?
double d = Sqrt(foo);
where does 'Sqrt(foo)' live? I have NO idea.
Do you really have no idea, in real life rather than in theory?
Would you not guess that it was in System.Math, given no other
information, and considering the context?
I don't want to 'guess', Jon. That's the whole point. Of course, any
math method likely will be in Math, though the world is bigger than the
set of methods in Math. Of course, with 'Sqrt' it's pretty obvious
where that method might be located, however Validate(myCustomer) is a
bit less clear.
So, IMHO the example you're pushing is actually an incredibly narrow
scope, but the feature required to use that example as discussed won't
be used solely for very narrow scoped methods, but for a lot more
methods. I then say: it will give more problems than it solves.
Sure, with fancy tooling
I might find the place where this is. But reliance on tooling to
READ and UNDERSTAND code is IMHO a slippery slope I at least don't
want to be on. Code should be understandable and clear for the
reader who reads it. ANY degration to that is IMHO bad. Sure your
suggestion might save a few keystrokes, but it also introduces
degration of the clarity of code written. I simply fail to
understand how you can ignore that fact.
We apparently view clarity differently. If I'm working on something
which I know from the context uses trigonometry, then formulae which
just have things like:
double x = Pow(Sin(alpha)+Cos(theta), 2);
have more clarity for me than formulae such as:
double x = Math.Pow(Math.Sin(alpha)+Math.Cos(theta), 2);
Sure, though is that in general the case with any random method, or is
it just more clear because the methods in the example are clearly math
related routines so there could be just one place where they'd be
located?
Have you read much C# code that requires extensive use of System.Math?
No, last time I did geometry related code was in C++ some years ago.
It's horrible currently, and would greatly benefit from this. The
ambiguity due to the possibility of Cos/Sin/Pow etc is greatly
dwarfed by the guaranteed extra cruft of having to prefix everything
with "Math".
In THIS particular example, I see your point, but IMHO it's also the
only example or perhaps one of the very few examples which would make
this feature worth having. IMHO, what the cause of this problem is is
that a piece of logic has to be formulated in language L1 which uses
paradigm P1, but the piece of logic is far better expressed in language
L2 which uses paradigm P2. Because L1 is the language of choice, the
logic has to be written in a way which is less expressive.
I.o.w. a way to have any DSL D inside C# and where context awareness
is possible inside D and C# would be very welcome. But that's not going
to happen, see the way how they added Linq instead of adding a DSL
awareness and WITH that Linq. That same DSL awareness then would have
given you the ability for formulate the formulas in a language much
more expressive for that than C# and at the same time wouldn't butcher
C# with features which are actually a big burden for a lot of other
situations than the situation it would be handy for.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Frans Bouma [C# MVP] <pe******************@xs4all.nlwrote:
Do you really have no idea, in real life rather than in theory?
Would you not guess that it was in System.Math, given no other
information, and considering the context?
I don't want to 'guess', Jon. That's the whole point. Of course, any
math method likely will be in Math, though the world is bigger than the
set of methods in Math. Of course, with 'Sqrt' it's pretty obvious
where that method might be located, however Validate(myCustomer) is a
bit less clear.
Which is why it would be a bad idea to use it for Validate.
Here's another example, without changing anything. If I write a method
called "DoSomething" then wherever I use it, I've either got to guess
what it does or consult the documentation (which would usually be via
Intellisense).
What's my answer to this? Naming methods sensibly.
So, IMHO the example you're pushing is actually an incredibly narrow
scope, but the feature required to use that example as discussed won't
be used solely for very narrow scoped methods, but for a lot more
methods. I then say: it will give more problems than it solves.
To which I say: only if used incredibly stupidly.
We apparently view clarity differently. If I'm working on something
which I know from the context uses trigonometry, then formulae which
just have things like:
double x = Pow(Sin(alpha)+Cos(theta), 2);
have more clarity for me than formulae such as:
double x = Math.Pow(Math.Sin(alpha)+Math.Cos(theta), 2);
Sure, though is that in general the case with any random method, or is
it just more clear because the methods in the example are clearly math
related routines so there could be just one place where they'd be
located?
It's because it's clear, certainly - and I wouldn't recommend using it
in any cases *other* than where it's clear.
Have you read much C# code that requires extensive use of System.Math?
No, last time I did geometry related code was in C++ some years ago.
I suspect you'd be more in favour of the feature if you had had to
experience the nastiness which requiring "Math." presents.
It's horrible currently, and would greatly benefit from this. The
ambiguity due to the possibility of Cos/Sin/Pow etc is greatly
dwarfed by the guaranteed extra cruft of having to prefix everything
with "Math".
In THIS particular example, I see your point, but IMHO it's also the
only example or perhaps one of the very few examples which would make
this feature worth having. IMHO, what the cause of this problem is is
that a piece of logic has to be formulated in language L1 which uses
paradigm P1, but the piece of logic is far better expressed in language
L2 which uses paradigm P2. Because L1 is the language of choice, the
logic has to be written in a way which is less expressive.
Absolutely. But this feature would help things enormously.
I.o.w. a way to have any DSL D inside C# and where context awareness
is possible inside D and C# would be very welcome. But that's not going
to happen, see the way how they added Linq instead of adding a DSL
awareness and WITH that Linq. That same DSL awareness then would have
given you the ability for formulate the formulas in a language much
more expressive for that than C# and at the same time wouldn't butcher
C# with features which are actually a big burden for a lot of other
situations than the situation it would be handy for.
Well, the situation I was thinking of is actually Hibernate and its
Criteria API, but I can't find the page that gives a nice example at
the moment.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Frans Bouma [C# MVP] wrote:
Jon Skeet [C# MVP] wrote:
On Jun 8, 9:37 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
<snip>
So, because that set of using statements makes it already
less clear, you're perfectly OK with making it VERY unclear for the
reader with further scope increases?
>
double d = Sqrt(foo);
>
where does 'Sqrt(foo)' live? I have NO idea.
Do you really have no idea, in real life rather than in theory?
Would you not guess that it was in System.Math, given no other
information, and considering the context?
I don't want to 'guess', Jon.
You still have to guess that it's System.Math, and not some other Math
:)
FWIW, I think OO is overrated, has been for a long time now. It's on the
wane, as things become more normal.
-- Barry
-- http://barrkel.blogspot.com/
Jon Skeet [C# MVP] wrote:
Frans Bouma [C# MVP] <pe******************@xs4all.nlwrote:
Do you really have no idea, in real life rather than in theory?
Would you not guess that it was in System.Math, given no other
information, and considering the context?
I don't want to 'guess', Jon. That's the whole point. Of course,
any math method likely will be in Math, though the world is bigger
than the set of methods in Math. Of course, with 'Sqrt' it's pretty
obvious where that method might be located, however
Validate(myCustomer) is a bit less clear.
Which is why it would be a bad idea to use it for Validate.
Here's another example, without changing anything. If I write a
method called "DoSomething" then wherever I use it, I've either got
to guess what it does or consult the documentation (which would
usually be via Intellisense).
What's my answer to this? Naming methods sensibly.
Sure, though if the language has the construct of static methods, the
class name becomes part of the method name (IMHO), in such a way that
the scope in which the method operates is described by the class name
so it's not necessary to add that description in the method name itself.
FOr example, String.Copy(). It's a static method. Using the proposed
mechanism, I end up with code like:
myVar = Copy(myOtherVar);
In a procedural language, one wouldn't use 'Copy'. One would use
CopyString() for example as it copies a string. But because the method
is statically defined on String, CopyString is redundant, Copy is
enough information, as 'String' is already specified.
Have you read much C# code that requires extensive use of
System.Math?
No, last time I did geometry related code was in C++ some years
ago.
I suspect you'd be more in favour of the feature if you had had to
experience the nastiness which requiring "Math." presents.
I guess :)
I.o.w. a way to have any DSL D inside C# and where context
awareness is possible inside D and C# would be very welcome. But
that's not going to happen, see the way how they added Linq instead
of adding a DSL awareness and WITH that Linq. That same DSL
awareness then would have given you the ability for formulate the
formulas in a language much more expressive for that than C# and at
the same time wouldn't butcher C# with features which are actually
a big burden for a lot of other situations than the situation it
would be handy for.
Well, the situation I was thinking of is actually Hibernate and its
Criteria API, but I can't find the page that gives a nice example at
the moment.
We use a similar API, to get compile time checked queries (without
having Linq around ;)). Like:
IPredicate p = (CustomerFields.CompanyName == "BigCorp Inc");
The perfect DSL for querying is SQL, it's however set oriented, not
procedural nor OO. That friction has to be overcome somehow, if you
want to specify what you want in C# if you can't use SQL. IMHO the same
with mathematical procedures in an OO environment. Cutting up the
target language to become a language for another paradigm is IMHO
making the language very weak and open for abuse. Better is to enable
interoperability in a transparent form so you can write a complex
formula in the DSL which does that best, evaluate it with that DSL and
refer to the result in normal C#. And back, refer to values in the C#
program in the formula.
It would get you what you want, and in the best possible form. However
I'm not sure if we'll see it in a short timeframe in C#, unless things
like JRuby will get that much traction that MS has to act upon it. (For
the JRuby impaired readers: JRuby is an enviroment which allows you to
write ruby code and java code and let them interoperate on eachother:
call java code from within ruby, call ruby code from within java and
refer to elements living in the other language space).
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Frans Bouma [C# MVP] <pe******************@xs4all.nlwrote:
Here's another example, without changing anything. If I write a
method called "DoSomething" then wherever I use it, I've either got
to guess what it does or consult the documentation (which would
usually be via Intellisense).
What's my answer to this? Naming methods sensibly.
Sure, though if the language has the construct of static methods, the
class name becomes part of the method name (IMHO), in such a way that
the scope in which the method operates is described by the class name
so it's not necessary to add that description in the method name itself.
FOr example, String.Copy(). It's a static method. Using the proposed
mechanism, I end up with code like:
myVar = Copy(myOtherVar);
Only if you abuse the feature though. There's nothing to force you do
static using System.String;
and indeed I wouldn't recommend it.
In a procedural language, one wouldn't use 'Copy'. One would use
CopyString() for example as it copies a string. But because the method
is statically defined on String, CopyString is redundant, Copy is
enough information, as 'String' is already specified.
Right - so where it's not clear, you don't use the feature.
<snip>
I.o.w. a way to have any DSL D inside C# and where context
awareness is possible inside D and C# would be very welcome. But
that's not going to happen, see the way how they added Linq instead
of adding a DSL awareness and WITH that Linq. That same DSL
awareness then would have given you the ability for formulate the
formulas in a language much more expressive for that than C# and at
the same time wouldn't butcher C# with features which are actually
a big burden for a lot of other situations than the situation it
would be handy for.
Well, the situation I was thinking of is actually Hibernate and its
Criteria API, but I can't find the page that gives a nice example at
the moment.
We use a similar API, to get compile time checked queries (without
having Linq around ;)). Like:
IPredicate p = (CustomerFields.CompanyName == "BigCorp Inc");
The perfect DSL for querying is SQL, it's however set oriented, not
procedural nor OO. That friction has to be overcome somehow, if you
want to specify what you want in C# if you can't use SQL. IMHO the same
with mathematical procedures in an OO environment. Cutting up the
target language to become a language for another paradigm is IMHO
making the language very weak and open for abuse. Better is to enable
interoperability in a transparent form so you can write a complex
formula in the DSL which does that best, evaluate it with that DSL and
refer to the result in normal C#. And back, refer to values in the C#
program in the formula.
In this case it doesn't make the language "very weak" but enables a
fluent interface which reads quite naturally. (It doesn't particularly
read like SQL, but that's okay.)
It would get you what you want, and in the best possible form. However
I'm not sure if we'll see it in a short timeframe in C#, unless things
like JRuby will get that much traction that MS has to act upon it. (For
the JRuby impaired readers: JRuby is an enviroment which allows you to
write ruby code and java code and let them interoperate on eachother:
call java code from within ruby, call ruby code from within java and
refer to elements living in the other language space).
Have you not heard about DLR and IronRuby? http://blogs.msdn.com/hugunin/archiv...amic-language-
runtime-dlr.aspx http://www.iunknown.com/2007/04/introducing_iro.html
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] wrote:
Frans Bouma [C# MVP] <pe******************@xs4all.nlwrote:
Here's another example, without changing anything. If I write a
method called "DoSomething" then wherever I use it, I've either
got to guess what it does or consult the documentation (which
would usually be via Intellisense).
>
What's my answer to this? Naming methods sensibly.
Sure, though if the language has the construct of static methods,
the class name becomes part of the method name (IMHO), in such a
way that the scope in which the method operates is described by the
class name so it's not necessary to add that description in the
method name itself.
FOr example, String.Copy(). It's a static method. Using the
proposed mechanism, I end up with code like:
myVar = Copy(myOtherVar);
Only if you abuse the feature though. There's nothing to force you do
static using System.String;
and indeed I wouldn't recommend it.
Ok, though IMHO (but we differ in opinion on that ;)) this feature's
usage is usually (in my eyes) an abuse.
It would get you what you want, and in the best possible form.
However I'm not sure if we'll see it in a short timeframe in C#,
unless things like JRuby will get that much traction that MS has to
act upon it. (For the JRuby impaired readers: JRuby is an
enviroment which allows you to write ruby code and java code and
let them interoperate on eachother: call java code from within
ruby, call ruby code from within java and refer to elements living
in the other language space).
Have you not heard about DLR and IronRuby?
http://blogs.msdn.com/hugunin/archiv...amic-language-
runtime-dlr.aspx
http://www.iunknown.com/2007/04/introducing_iro.html
Yes I have, though afaik, the DLR doesn't support C#, nor is it giving
me (but I might have understood it wrong) true language integration
between two languages.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Frans Bouma [C# MVP] <pe******************@xs4all.nlwrote:
Only if you abuse the feature though. There's nothing to force you do
static using System.String;
and indeed I wouldn't recommend it.
Ok, though IMHO (but we differ in opinion on that ;)) this feature's
usage is usually (in my eyes) an abuse.
How can we talk about "usually" when we don't know what's "usual"?
Until we've seen how often such a feature would be used in reality, we
can't know what proportion of such uses is abusive, even if we agree on
what constitutes abuse.
What I *will* say is that the feature exists in Java (v5+) and most of
the times I've seen it used have been beneficial.
Have you not heard about DLR and IronRuby?
http://blogs.msdn.com/hugunin/archiv...amic-language-
runtime-dlr.aspx
http://www.iunknown.com/2007/04/introducing_iro.html
Yes I have, though afaik, the DLR doesn't support C#, nor is it giving
me (but I might have understood it wrong) true language integration
between two languages.
The DLR extends the CLR as far as I'm aware, so it can call code
written in C#. I haven't looked in enough detail to see whether C# can
call code written in, say, IronRuby - but I'd certainly hope so.
Personally I'd love to see an equivalent of Groovy but for C# - I think
Boo is as close as it comes at the moment, but who knows what may be
possible on the DLR...
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] wrote:
Frans Bouma [C# MVP] <pe******************@xs4all.nlwrote:
Only if you abuse the feature though. There's nothing to force
you do
>
static using System.String;
>
and indeed I wouldn't recommend it.
Ok, though IMHO (but we differ in opinion on that ;)) this
feature's usage is usually (in my eyes) an abuse.
How can we talk about "usually" when we don't know what's "usual"?
Until we've seen how often such a feature would be used in reality,
we can't know what proportion of such uses is abusive, even if we
agree on what constitutes abuse.
We can't see into the future, agreed, though I'm not convinced usage
of this is very beneficial: it IMHO almost always creates obscurity,
but as I said, that's my opinion and others of course can (and likely
will) have different opinions ;)
What I will say is that the feature exists in Java (v5+) and most of
the times I've seen it used have been beneficial.
though all with math methods or also with other methods?
Have you not heard about DLR and IronRuby?
>
http://blogs.msdn.com/hugunin/archiv...ynamic-languag
e- runtime-dlr.aspx
>
http://www.iunknown.com/2007/04/introducing_iro.html
Yes I have, though afaik, the DLR doesn't support C#, nor is it
giving me (but I might have understood it wrong) true language
integration between two languages.
The DLR extends the CLR as far as I'm aware, so it can call code
written in C#. I haven't looked in enough detail to see whether C#
can call code written in, say, IronRuby - but I'd certainly hope so.
afaik, you can't write a C# program on the DLR. Of course you can call
a method in IL which might have been written in C#, but it's not
possible to write a C# program on the DLR and mix the code with, say,
ruby.
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
On Jun 11, 8:29 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
How can we talk about "usually" when we don't know what's "usual"?
Until we've seen how often such a feature would be used in reality,
we can't know what proportion of such uses is abusive, even if we
agree on what constitutes abuse.
We can't see into the future, agreed, though I'm not convinced usage
of this is very beneficial: it IMHO almost always creates obscurity,
but as I said, that's my opinion and others of course can (and likely
will) have different opinions ;)
Indeed.
What I will say is that the feature exists in Java (v5+) and most of
the times I've seen it used have been beneficial.
though all with math methods or also with other methods?
Some maths, some not. (I've seen it used beneficially with
enumerations, but that's partly because Java enumerations are so much
more powerful anyway.)
Yes I have, though afaik, the DLR doesn't support C#, nor is it
giving me (but I might have understood it wrong) true language
integration between two languages.
The DLR extends the CLR as far as I'm aware, so it can call code
written in C#. I haven't looked in enough detail to see whether C#
can call code written in, say, IronRuby - but I'd certainly hope so.
afaik, you can't write a C# program on the DLR. Of course you can call
a method in IL which might have been written in C#, but it's not
possible to write a C# program on the DLR and mix the code with, say,
ruby.
If you mean getting the DLR to "dynamically" compile C#, I wouldn't be
surprised to find it can't (although you can compile full C# with the
CSharpCodeProvider of course). I haven't looked at the DLR enough to
really know much about it yet though.
Jon
Jon Skeet wrote:
Yes I have, though afaik, the DLR doesn't support C#, nor is it giving
me (but I might have understood it wrong) true language integration
between two languages.
The DLR extends the CLR as far as I'm aware, so it can call code
written in C#. I haven't looked in enough detail to see whether C# can
call code written in, say, IronRuby - but I'd certainly hope so.
When implementing multiple dynamic languages on the .NET platform, the
need for bringing together the common dynamic patterns into a library is
pretty obvious. From the slot it fills, I'm 100% certain that it
supports a kind of reflection-level support for calling from C#, i.e.
you'll likely have to lookup methods by name with a string (but possibly
benefit with caching delegates), and pass object[] or similar as
arguments.
Static binding, where type / methods from Python and Ruby etc. become
available as strongly-typed types / methods in C#, while "nice", isn't
really very practical for dynamic languages, because everything you make
available in that strongly-typed way, lessens the dynamicness of the
languages involved.
Personally I'd love to see an equivalent of Groovy but for C# - I think
Boo is as close as it comes at the moment, but who knows what may be
possible on the DLR...
I see the DLR as being the infrastructure which puts into a common
basket a handful of things that are commonly done when implementing
scripting languages: types that can be expanded and modified
dynamically, 'eval'/REPL support, the moral equivalent of COM IDispatch
interfaces, etc.
-- Barry
-- http://barrkel.blogspot.com/
On Jun 11, 8:56 am, Barry Kelly <barry.j.ke...@gmail.comwrote:
Personally I'd love to see an equivalent of Groovy but for C# - I think
Boo is as close as it comes at the moment, but who knows what may be
possible on the DLR...
I see the DLR as being the infrastructure which puts into a common
basket a handful of things that are commonly done when implementing
scripting languages: types that can be expanded and modified
dynamically, 'eval'/REPL support, the moral equivalent of COM IDispatch
interfaces, etc.
Indeed. One issue I can see is where there are common general ideas,
but different semantics - e.g. looking up a method dynamically, and
the fallback techniques. Each language which is a port of an existing
one will want to keep the existing language's semantics, but it would
be nice in other ways to be consistent between languages within the
DLR. It's not really a technical problem at that stage, of course.
Jon
"Barry Kelly" <ba***********@gmail.comwrote in message
news:mj********************************@4ax.com...
Frans Bouma [C# MVP] wrote:
>Jon Skeet [C# MVP] wrote:
On Jun 8, 9:37 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
<snip>
So, because that set of using statements makes it already
less clear, you're perfectly OK with making it VERY unclear for the
reader with further scope increases?
double d = Sqrt(foo);
where does 'Sqrt(foo)' live? I have NO idea.
Do you really have no idea, in real life rather than in theory?
Would you not guess that it was in System.Math, given no other
information, and considering the context?
I don't want to 'guess', Jon.
You still have to guess that it's System.Math, and not some other Math
:)
FWIW, I think OO is overrated, has been for a long time now. It's on the
wane, as things become more normal.
It's quite useful when you need inheritance or polymorphism. Useful for
encapsulation too, but that is readily achieved with procedural and
functional programming as well.
What's wrong is when a language designer makes the decision "only OO
programming will be used".
But why has this feature become about OO vs procedure? Coupled with
generics, it provides something incredibly OO -- "configurations". Not the
run-time load the configuration from an xml file, but type-safe, fully
checked, compile-time configurations. There are cases for each, but up
until now there has been no language support for the latter.
>
-- Barry
--
http://barrkel.blogspot.com/
Ben Voigt [C++ MVP] wrote:
"Barry Kelly" <ba***********@gmail.comwrote in message
news:mj********************************@4ax.com...
FWIW, I think OO is overrated, has been for a long time now. It's on the
wane, as things become more normal.
It's quite useful when you need inheritance or polymorphism.
For sure. Not disputing that OO is a hugely useful tool. I've just
become wary when wielded indiscriminately as a tool for unsuitable
problems...
Useful for
encapsulation too, but that is readily achieved with procedural and
functional programming as well.
What's wrong is when a language designer makes the decision "only OO
programming will be used".
Believe it or not, I actually had more the RDBMS-OO contrast in mind,
even though the thread is about System.Math etc. That said, I agree with
you.
But why has this feature become about OO vs procedure? Coupled with
generics, it provides something incredibly OO -- "configurations". Not the
run-time load the configuration from an xml file, but type-safe, fully
checked, compile-time configurations. There are cases for each, but up
until now there has been no language support for the latter.
What is this checked, compile-time configuration of which you speak? And
where does it now have language support? It sounds curiously similar to
something I'm working on...
-- Barry
-- http://barrkel.blogspot.com/
"Barry Kelly" <ba***********@gmail.comschrieb
FWIW, I think OO is overrated, has been for a long time now. It's on the
wane, as things become more normal.
I'd say, the term 'pure OO' is often overrated.
Christof
>But why has this feature become about OO vs procedure? Coupled with
>generics, it provides something incredibly OO -- "configurations". Not
the
run-time load the configuration from an xml file, but type-safe, fully
checked, compile-time configurations. There are cases for each, but up
until now there has been no language support for the latter.
What is this checked, compile-time configuration of which you speak? And
where does it now have language support? It sounds curiously similar to
something I'm working on...
Sorry, it doesn't, yet. The proposed "static using" feature would provide
it.
Ben Voigt [C++ MVP] wrote:
But why has this feature become about OO vs procedure? Coupled with
generics, it provides something incredibly OO -- "configurations". Not
the
run-time load the configuration from an xml file, but type-safe, fully
checked, compile-time configurations. There are cases for each, but up
until now there has been no language support for the latter.
What is this checked, compile-time configuration of which you speak? And
where does it now have language support? It sounds curiously similar to
something I'm working on...
Sorry, it doesn't, yet. The proposed "static using" feature would provide
it.
Ah, I think you mean, switching your 'static using', and by that
switching in a specific set of methods?
AFAICT, there's no reason you can't already do that, but at one more
level of indirection. In other words, have multiple classes of the same
name in different namespaces, and use a particular namespace at the top
of the file.
-- Barry
-- http://barrkel.blogspot.com/
"Barry Kelly" <ba***********@gmail.comwrote in message
news:e4********************************@4ax.com...
Ben Voigt [C++ MVP] wrote:
>But why has this feature become about OO vs procedure? Coupled with
generics, it provides something incredibly OO -- "configurations".
Not
the
run-time load the configuration from an xml file, but type-safe, fully
checked, compile-time configurations. There are cases for each, but
up
until now there has been no language support for the latter.
What is this checked, compile-time configuration of which you speak?
And
where does it now have language support? It sounds curiously similar to
something I'm working on...
Sorry, it doesn't, yet. The proposed "static using" feature would
provide
it.
Ah, I think you mean, switching your 'static using', and by that
switching in a specific set of methods?
Methods sure, but also nested classes.
>
AFAICT, there's no reason you can't already do that, but at one more
level of indirection. In other words, have multiple classes of the same
name in different namespaces, and use a particular namespace at the top
of the file.
But, namespaces don't support generics. Classes do. That way, the
configuration can propagate.
It also means, by having everything configuration dependent inside a generic
class, that the configuration can be changed in one place, instead of at the
top of every file. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Tim Van Wassenhove |
last post by:
Hello,
When i read the CLI spec, 8.10.2 Method inheritance i read the
following:
"A derived object type inherits all of the instance and virtual methods
of its base object type. It does not...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
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: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
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...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| | |
