Re: Inheritable Static methods

On Mon, 26 May 2008 17:31:14 -0700, d-42 <db.porsche@xxxxxxxxx> wrote:

[...]
How is this significantly better than simply writing
"typeof(someClass).FullName"?

That's basically the same as asking:

How is writing myInt.ToString() significantly better than
Convert.ToString(myInt)

And?

Its not that one is 'signficantly better' than the other.

Agreed. At best, you save one function call. For all I know, some inlining happens, and there's not even that.

That said...

The latter
has an external (Convert) class perform the conversion on the int
type, the former encapsulates the conversion into the int type. Two
different ways of doing the same thing. Nothing wrong with either. And
indeed, for all i know myInt.ToString() is implemented as
Convert.ToString(this) behind the scenes.

It is. Or at least, the docs say so and I trust them.

That's not really the issue.

In this case, because the the class names will be frequently needed it
makes aesthetic sense to have the class provide its own name, rather
than require the programmers to reflect out themselves each time. Just
like it makes sense for Int to be able to convert itself to a string
without the caller manually invoking a helper class each time.

Well, IMHO this is where the comparison breaks down. Even if I thought calling Convert.ToString() was worse by any metric other than elegance (certainly not encapsulation), and even if I thought it was so much worse that it'd be worth debating someone about it, it's not really applicable.

The Convert class really is a different class. But when you use typeof(), that's not a different class. It's really just a different part -- the static "instance", if you will -- of your actual class. I admit, writing "typeof(someClass).FullName" might not look quite as nice as "someClass.FullName". But really, it's practically the same syntax. Any difference is surely inconsequential.

Either will work. It just seems odd that this particular bit of
functionality can't easily be encapsulated.

Frankly, your use case here is a bit bizarre IMHO (and I mean that in a good way :) ). I mean, usually people come here complaining that they can't have virtual static methods because they want to implement something that's actually impossible to implement. But here, you've got a perfectly good alternative syntax that does _exactly_ the same thing.

I don't see the problem.

Pete
.

Relevant Pages

  • Re: "EXT3-fs error" after resume from s2ram
    ... INT A disabled ... writing 0xe2000008) ... connection state: disconnected -> associated ... setting latency timer to 64 ...
    (Linux-Kernel)
  • Re: Rookie Student C++ Array question (reading from a file)
    ... >Start by writing down in plain english words what needs to be done. ... >int main ... >That's your overall plan. ... at the previous suggestion of mapping, ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Rookie Student C++ Array question (reading from a file)
    ... >Start by writing down in plain english words what needs to be done. ... >int main ... >That's your overall plan. ... >do the additions inline in your real source code) ...
    (alt.comp.lang.learn.c-cpp)
  • Re: read and write columns
    ... You attempt to open the same file, "data", for writing and reading, ... Read the documentation for fscanf. ... int main ...
    (comp.lang.c)
  • Re: memory and subroutines
    ... might call a "constructor," consider writing a companion ... "destructor" function at the same time. ... to do one easily-described job and do it well; avoid writing ... int rand_in_range; ...
    (comp.lang.c)