static class inheritance, generalized

[Frans Bouma [C# MVP]]

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?

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#)
------------------------------------------------------------------------

 

[Jon Skeet [C# MVP]]

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.


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.)

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

 

[Barry Kelly]

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

 

[Jon Skeet [C# MVP]]

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

 

[Ben Voigt [C++ MVP]]

On Jun 8, 9:37 am, "Frans Bouma [C# MVP]"

<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 Kelly]

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

 

[Christof Nordiek]

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

 

[Ben Voigt [C++ MVP]]

But why has this feature become about OO vs procedure? Coupled with

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.

 

[Barry Kelly]

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

 

[Ben Voigt [C++ MVP]]

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.