Print

Print


I was just curious, so I threw the same thing into C#.

    class Foo
    {
        public static void sayHello()
        {
            hi();
        }

        public static void hi()
        {
            Console.WriteLine("Hi from foo");
        }
    }

    class Bar : Foo
    {
        public static void sayHello2()
        {
            hi();
        }

        public static new void hi()
        {
            Console.WriteLine("Hi from bar");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Bar.sayHello();
            Bar.sayHello2();
            Console.ReadLine();
        }
}

Result is similar:
Hi from foo
Hi from bar.

The C# compiler actually throws an error if you try to make a static class extend another class.  ( i.e., static class Bar : Foo ).

Static references are really a nice way to get around OO in the first place though.  Of course I use them as well, when I want to introduce more procedural type methods into my code, or when I truly need something at the CLASS level, rather than the OBJECT level.  Although using static methods can occasionally provide very small performance boosts, I would guess static methods also reduces the ability to use reflection to examine code introduced or created during runtime.

That said, it's hard for me to get too excited about the lack of the ability for a static class to extend another static class and throw strongly typed classes out the window for Javascript's hash implementation.  And I have spent a lot of time trying to get Javascript to feel more object-oriented, copying a "child" classes hash from the parent and then adding new items (happen to be functions) to it and using Prototype as well.

Either way, there are different models for everyone and perhaps every project.  

But, I did learn something about Java (and then C#) from this thread.

Mark / UF



-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Benjamin Armintor
Sent: Thursday, February 21, 2013 1:22 PM
To: [log in to unmask]
Subject: Re: [CODE4LIB] You are a *pedantic* coder. So what am I?

If this thread is just code nerdery: You can't override static methods in Java.  It looks like you can because there's a generous search for statically bound names (if B extends A, and A defines static a(), B.a() works), but it's not the overriding mechanism because if you try to refer to super in an "overriding" implementation, the compiler stops you (it's not bound).  This also suggests that classes are not objects, but that the reflection API cheats a little to  make them appear to be so.

I always thought Javascript both had primitives and was more functional than OO, given the Prototype inheritance stuff, the fact that objects are really hashes, and the fact that constructors are functions.  Ruby, though:
totally OO. Except when it's not.

- Ben


On Thu, Feb 21, 2013 at 1:00 PM, Adam Wead <[log in to unmask]> wrote:

> Actually, I'm finding this thread very enlightening.  I've only had a 
> little java experience, but always assumed it was the 
> ur-implementation of OO principles.  Now, I've had that assumption corrected.
>
> Thanks,
>
> ...adam
>
>
> On Feb 21, 2013, at 12:53 PM, Ian Walls <[log in to unmask]> wrote:
>
> > Agreed.  Each language has its own strengths and weaknesses.  Pick 
> > the
> one that works best for your situation, factoring in not only what the 
> application needs to do, but your and your team's level of experience, 
> and the overall community context in which the project will live.  The 
> peculiarities of a given languages truth tables, for example, can 
> easily get washed out of the calculation when you consider what 
> languages you know and what platforms your institution supports.
> >
> >
> > -Ian
> >
> > -----Original Message-----
> > From: Code for Libraries [mailto:[log in to unmask]] On Behalf 
> > Of
> Ethan Gruber
> > Sent: Thursday, February 21, 2013 12:45 PM
> > To: [log in to unmask]
> > Subject: Re: [CODE4LIB] You are a *pedantic* coder. So what am I?
> >
> > Look, I'm sure we can list the many ways different languages fail to
> meet our expectations, but is this really a constructive line of 
> conversation?
> >
> > -1
> >
> >
> > On Thu, Feb 21, 2013 at 12:40 PM, Justin Coyne
> > <[log in to unmask]>wrote:
> >
> >> I did misspeak a bit.  You can override static methods in Java.  My 
> >> major issue is that there is no "getClass()" within a static 
> >> method, so when the static method is being run in the context of 
> >> the inheriting class it is unaware of its own run context.
> >>
> >> For example: I want the output to be "Hi from bar", but it's "Hi 
> >> from
> foo":
> >>
> >> class Foo {
> >>  public static void sayHello() {
> >>    hi();
> >>  }
> >>  public static void hi() {
> >>    System.out.println("Hi from foo");  } }
> >>
> >> class Bar extends Foo {
> >>
> >>  public static void hi() {
> >>    System.out.println("Hi from bar");  } }
> >>
> >> class Test {
> >>  public static void main(String [ ] args) {
> >>    Bar.sayHello();
> >>  }
> >> }
> >>
> >>
> >> -Justin
> >>
> >>
> >>
> >> On Thu, Feb 21, 2013 at 11:18 AM, Eric Hellman <[log in to unmask]>
> wrote:
> >>
> >>> OK, pedant, tell us why you think methods that can be over-ridden 
> >>> are static.
> >>> Also, tell us why you think classes in Java are not instances of 
> >>> java.lang.Class
> >>>
> >>>
> >>> On Feb 18, 2013, at 1:39 PM, Justin Coyne 
> >>> <[log in to unmask]>
> >>> wrote:
> >>>
> >>>> To be pedantic, Ruby and JavaScript are more Object Oriented than 
> >>>> Java because they don't have primitives and (in Ruby's case) 
> >>>> because classes
> >>> are
> >>>> themselves objects.   Unlike Java, both Python and Ruby can properly
> >>>> override of static methods on sub-classes. The Java language made 
> >>>> many compromises as it was designed as a bridge to Object 
> >>>> Oriented
> >> programming
> >>>> for programmers who were used to writing C and C++.
> >>>>
> >>>> -Justin
> >>>>
> >>>
> >>
>
> This communication is a confidential and proprietary business 
> communication. It is intended solely for the use of the designated 
> recipient(s). If this communication is received in error, please 
> contact the sender and delete this communication.
>