• wtf (unregistered) in reply to veniam
    veniam:
    I see. So we're going to get rid of static methods entirely?

    Hopefully yes. There is no reason for them to exist.

    A Util class is not object-oriented. Try to define its responsibility. If you write "it's supposed to hold everything that doesn't fit elsewhere" and compare that to other classes' responsibilities, you'll see that you have a beast that should be killed.

    And existing Java libraries are no excuse to repeat their mistakes.

    I might let you keep one static main() to get things rolling.

    Could be interesting. You could even get around the static declaration for main, if you handled it in a manner roughly parallel to the way constructors are handled. Obviously, I haven't really thought about this, so this is off the top of my head, but I can see how you could possibly do away with the static keyword for methods and still have something very much like Java.

    What would you do about static variables? Allow or no?

  • (cs) in reply to Cbuttius
    Cbuttius:
    Just looked at the algorithm. There is one major bug in that if you pass in a negative number you will fail the checks and take a negative index from the array, presumably in Java that gives you a bounds exception or whatever they call it...

    Yes. Using a negative number as an array index will cause an ArrayIndexOutOfBoundsException at runtime.

    Cbuttius:
    but is there not an unsigned int in Java?

    No. Java has no unsigned numeric types of any kind.

  • leet3lite (unregistered)

    Like so much WTF code, name changes and comments would make it much more reasonable. Instead of "Util" as a classname, "ExcelColumnIndexer" or something like that and "convertColumnIndex" instead of "dec2Alpha" would immediately give an idea of what they are trying to do, even if the internal code is fubar. Seriously - Reasonable naming is something everyone can do without technical training. Stop screwing with everyone's sanity!

  • MOD26 (unregistered)

    I used this kind of code for something else than excel. It was for RSA encoding.

  • Actual Computer Scientist (unregistered) in reply to veniam
    veniam:
    I see. So we're going to get rid of static methods entirely?

    Hopefully yes. There is no reason for them to exist.

    When a method doesn't have or modify state, it should be a static method. In this way it marks for human beings (and the compiler) that it is stateless; which is a nice compact way of saying: re-entrant, thread-safe, relocatable, and has no data on the heap.

    veniam:
    A Util class is not object-oriented. Try to define its responsibility. If you write "it's supposed to hold everything that doesn't fit elsewhere" and compare that to other classes' responsibilities, you'll see that you have a beast that should be killed.

    And existing Java libraries are no excuse to repeat their mistakes.

    I might let you keep one static main() to get things rolling.

    Write Java programs without those libraries, then you can tell me all about their mistakes as you explain your wonderful replacements.

  • Jules (unregistered) in reply to Errorman
    Errorman:
    Mike D.:
    Adam:
    I've always felt content knowing that in the UK our buildings start with a Ground Floor (Floor 0) whereas in the states they start off at Floor 1.
    Do they skip the 13th floor, like here?
    Yes, because of course they have to get used to handling FLOOR_NOT_FOUND errors.

    In my city, the local hospital actually has a 13th floor and it's where the pysc ward is - no kidding.

  • Matt Westwood (unregistered)

    Classic management wtf: assign simply-defined tasks to new starters for them to cut their teeth on, but fail to examine exactly what they wrote once they have returned with a program / module / class / method that "works".

  • (cs) in reply to Jules
    Jules:
    Errorman:
    Mike D.:
    Adam:
    I've always felt content knowing that in the UK our buildings start with a Ground Floor (Floor 0) whereas in the states they start off at Floor 1.
    Do they skip the 13th floor, like here?
    Yes, because of course they have to get used to handling FLOOR_NOT_FOUND errors.

    In my city, the local hospital actually has a 13th floor and it's where the pysc ward is - no kidding.

    I thought the psych ward was usually on the third floor.

  • (cs) in reply to Mr. Spontaneous
    Mr. Spontaneous:
    I may be putting myself up for ridicule here, but what is the problem with a Util class for widely used methods in strict OOP languages? I understand that you don't want to throw everything in there.

    There's nothing wrong with it, if only because there's no right way to do it in a strict OO language. (Just look at all the people on here arguing about how to get it right!)

    Some concepts simply don't map well to the object/class paradigm, but proponents of strict OO languages don't like having this embarrassing fact brought to their attention, so they set up an ugly hack that works around it, then ridicule people who use other types of ugly hacks instead for "not doing it right," when the real problem is square pegs and round holes.

    TRWTF is strict OO languages.

  • The Nerve (unregistered)

    TRWTF is that James didn't do a code search to see what this code was doing. If he had, I'm sure he would not have submitted it here.

  • somedude (unregistered)

    TRWTF is that there is no XML involved

  • wtf (unregistered) in reply to Mason Wheeler
    Mason Wheeler:

    TRWTF is strict OO languages.

    Or perhaps people taking "OO" more strictly than it needs to be taken. Object-oriented programming forces the programmer to pay attention to the fact that they're modelling a part of the world, and that's good, but at some point you have to have axioms. If you're doing ballistics, are you going to model gravity by having an "Earth" class that attracts bodies in proportion to its mass, or are you just going to have the number "9.8" somewhere in the code? Your util class is a good place to keep your axioms, and the things that you just don't need to model in an object. Good OO programming, then, is the ability to know what belongs there.

  • Bobx (unregistered)

    Is that a zero in the middle of the "alphabet"?

    Also, from the lead: "destitute and despair"? Consistent parts of speech, anyone?

  • (cs) in reply to Actual Computer Scientist
    Actual Computer Scientist:
    veniam:
    I see. So we're going to get rid of static methods entirely?

    Hopefully yes. There is no reason for them to exist.

    When a method doesn't have or modify state, it should be a static method. In this way it marks for human beings (and the compiler) that it is stateless; which is a nice compact way of saying: re-entrant, thread-safe, relocatable, and has no data on the heap.

    Oh boy.

    Umm, no. Not in Java, not in C++. Static methods can have state. In Java such state is class-level, in C++ the static state can be also local to a method.

    Further misunderstanding is that such methods are re-entrant, thread-safe etc. They can only be if all of the functions/methods they call are such. It's very easy to have a non re-entrant, non thread-safe static function.

  • 2300 (unregistered) in reply to NameNotFoundException

    java.lang.{Math,Array} are a bad example of util classes that make sense. In a "strict OOP language", also integers and floating point numbers would be objects, so these mehtods could well be implemented as methods of integers, floating point numbers and arrays.

  • bricon (unregistered) in reply to leet3lite
    leet3lite:
    Like so much WTF code, name changes and comments would make it much more reasonable. Instead of "Util" as a classname, "ExcelColumnIndexer" or something like that and "convertColumnIndex" instead of "dec2Alpha" would immediately give an idea of what they are trying to do, even if the internal code is fubar. Seriously - Reasonable naming is something everyone can do without technical training. Stop screwing with everyone's sanity!
    There's nothing wrong with abstracting naming conventions. I do it timeRange15. remainingComment2String(). while(1) print "!"
  • Ken B. (unregistered) in reply to Anonymous
    Anonymous:
    Sylver:
    Crash Magnet:
    ARRALPHALET vs ALPHABET

    You have failed when you acronym takes more letters than the correct spelling.

    Not an acronym. No sir. This is Hungarian notation, of course.
    Apparently with a tribute to old BASIC languages, hence the "LET" at the end.
    No, it's ARRay of ALPHAbetic LETters. (As opposed to non-alpha letters, or alphabetic numbers, I suppose.)

    Okay, I don't usually do this, but...

    Captcha: damnum. "I want to phone in a WTF! What's the damnum of TDWTF?"

  • Jay (unregistered)

    I think a lot of the confusion here is from the fact that you people all seem to be assuming that this class has something to do with an alphabet. But if you'd just look at the class name, you'd see that that isn't so. The author has clearly indicated that this class is about an Arralphalet. That's something that resembles a Latin alphabet, but, for example, it has a Z at the beginning as well as the one at the end ...

  • Jay (unregistered) in reply to Mike D.
    Mike D.:
    Adam:
    I've always felt content knowing that in the UK our buildings start with a Ground Floor (Floor 0) whereas in the states they start off at Floor 1.
    Do they skip the 13th floor, like here?

    Yes, the building I work in has now 13th floor. I'm sure it's because of superstition. That's why they made it only 2 stories tall -- so they'd get nowhere near a 13th floor.

  • Ken B. (unregistered) in reply to Mike D.
    Mike D.:
    Adam:
    I've always felt content knowing that in the UK our buildings start with a Ground Floor (Floor 0) whereas in the states they start off at Floor 1.
    Do they skip the 13th floor, like here?
    Well, you have to admit that it's a marvel of engineering how they get the 14th floor to float some 8-10 feet above the 12th floor.
  • Fred (unregistered)
    /** * The utilize methods. */
    Any time you see the word "utilize" you know right away there is trouble coming, because "use" is a 100%-compatible replacement. In other words, people who utilize big words when they could just as easily use small words are the same people who have nothing to say, but feel the need to throw up big clouds of smoke so nobody notices.
  • Apparently Unfazable (unregistered)

    There's some minor "this name is crap" that you see everywhere (even in the FIXED code, c should be named lsd or b26LSD so it's more obvious it's got is the least significant digit in base 26). The array should just be indexed at i-1 and if that isn't happening the first string should be null so that it totally bombs at some point if you stuck null into your result. (but it's better to ArrayIndexOOB immediately with the -1 access) Aside from that, I don't see what people are wtfing over.

    Poor code, but not particularly wtf-worthy.

    (@316992: decimal is the name for base-10, like binary is the name for base-2)

    TRWTF is that we don't get to see reverse operation: "that method for turning letters into numbers." (yes, I know that's a think-o there)

  • Jay (unregistered) in reply to veniam
    veniam:
    I see. So we're going to get rid of static methods entirely?

    Hopefully yes. There is no reason for them to exist.

    A Util class is not object-oriented. Try to define its responsibility. If you write "it's supposed to hold everything that doesn't fit elsewhere" and compare that to other classes' responsibilities, you'll see that you have a beast that should be killed.

    And existing Java libraries are no excuse to repeat their mistakes.

    I might let you keep one static main() to get things rolling.

    Okay, I'll bite.

    So let's say we agree that we're going to abolish the Math class as anti-OOP. Now in a program you discover that you need to calculate a square root. How will you implement a square root calculation?

    If the need comes up in, say, the distance calcuation of your Point function, you could implement it inside the "calculateDistance(Point otherPoint)" function. But then suppose you need to calculate square roots in some other class, too. Will you reimplement the same algorithm?

    Indeed, what if the class where you need to find a square root needs it in two places. Will you implement the algorithm twice, once in each place? Or will you break this out into a common function? That common function will presumably take one parameter and return one value. It has nothing to do with the rest of the state of the object, so it may as well be static. Or will you tie the function to one particular value, just so you can meet the goal of being "more object-oriented". But then if you need it to operate on two different values, what will you do? Create a dummy member field just to hold the value you want to find the square root of? What would be gained by this?

    You could create an object to hold numbers to have miscellaneous mathematical operations performed on them. That is, you could create a MathOps object that takes an int in its constructor, so you could write something like:

    int n=... whatever ...;
    MathOps nn=new MathOps(n);
    rootN=nn.squareRoot();
    

    This would be more OOPish, but what does it gain over

    rootN=Math.squareRoot(n);
    

    It's more line of code to write creates an additional object on the heap, consuming time and memory. The only apparent advantage is that it preserves the abstract goal of being more OOPish.

    I suppose you could say that we should abolish primitives and make all numbers objects, so that our Integer object could then have a square root function.

    But what if someone creates a final object that doesn't include a function I need? Or they create an object whose internals are obscure enough that it would be difficult or risky for me to extend it to add the functions I need?

  • (cs)

    Wow, there's a lot of "wrong" in this thread pertaining to static methods.

    1. Static methods are not necessarily stateless.
    2. Because static methods do have an object they operate on: the class itself.

    In pretty much every OO language, classes are themselves objects. Static methods are methods of the class. Classes may have class state (static variables). Instances of the class may interact with the class level state, in the same way that they may interact with the parent classes's state.

    All of this is to say: static methods are neither wrong, nor non-OO. One can debate whether or not class types should be objects, but I have a hard time seeing a compelling case for making classes anything but objects.

  • Big Excel Sheet (unregistered)

    13733 319786 16074 253 356974 9 274076222 1963523940 4129617901 2097999 357181

  • Fedaykin (unregistered) in reply to Mike D.
    Mike D.:
    Mr. Spontaneous:
    I may be putting myself up for ridicule here, but what is the problem with a Util class for widely used methods in strict OOP languages? I understand that you don't want to throw everything in there.
    If it doesn't manipulate the object, it doesn't need to be in the object. So a 'Util' class makes no sense unless you're creating 'Util's.

    Which is the way things work in theory and a good goal. However, in the real world some classes, like String, are final...

    Damn you Sun, damn you!

  • (cs) in reply to Jay
    Jay:
    So let's say we agree that we're going to abolish the Math class as anti-OOP. Now in a program you discover that you need to calculate a square root. How will you implement a square root calculation?

    Obviously, it should be a method on the Number base-type. I shouldn't need to implement anything- a common function like that should be built into the type, not in an ancillary class.

    Now, if I had something domain specific, it would behoove me to implement my own child of the number type that had that method, although the "ideal" solution, for certain values of "ideal", would be to use the built-in language functionality to inject methods into higher levels of the inheritance tree.

    I can't speak to Java, but I know .NET, Ruby, JavaScript, and likely many other languages, have the ability to say, "Hey, put this method in the Number type, even though I don't have access to that type's definition."

  • Mike (unregistered) in reply to bl@h

    This code brought to you by the letter Z and the number 0.. or 26, or.. never mind.

  • (cs) in reply to Fedaykin
    Fedaykin:
    like String, are final...

    Damn you Sun, damn you!

    Wow, really? That's retarded.

  • MOD26 (unregistered)

    Have a math class attached to a number class could be great. Like this you don't touch your code when you want to do complex calculation or infenitesimal calculation etc.

    I hate this class Math, it blocks all the abstraction pattern.

  • (cs) in reply to Apparently Unfazable
    Apparently Unfazable:
    (@316992: decimal is the name for base-10, like binary is the name for base-2)

    You know, I can see how someone who's new to the site might not know how to use the Reply and Quote buttons. I can even almost see how you might think quoting a post ID number rather than a username might somehow be a good idea.

    But trying to quote a post from the future is a WTF any way you slice it.

  • David (unregistered) in reply to Remy Porter

    And we all know that the 'pattern' of OOP is obfuscation: illogically design one's code so that no one else can understand it.

  • Pedant who know the JLS (unregistered) in reply to Someone You Know
    Someone You Know:
    Cbuttius:
    but is there not an unsigned int in Java?

    No. Java has no unsigned numeric types of any kind.

    Java has: char.

    JLS:
    The values of the integral types are integers in the following ranges: [...] For char, from '\u0000' to '\uffff' inclusive, that is, from 0 to 65535
    http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.1
  • Erik (unregistered) in reply to Mike D.

    You bring up one of my (many) peeves with Java: What the hell is the deal with being forced to stuff everything into damn objects? I'm all for OOP, but requiring that everything be an object is just really really stupid.

    Unless they're implementing, say, a strategy pattern, dataless objects are just kludges.

    See Object Pascal for a saner approach.

  • someGuy (unregistered) in reply to MOD26
    MOD26:
    Have a math class attached to a number class could be great. Like this you don't touch your code when you want to do complex calculation or infenitesimal calculation etc.

    I hate this class Math, it blocks all the abstraction pattern.

    so then what if I actually care about how long my compiled code takes to run?

  • Lyle (unregistered) in reply to MOD26
    MOD26:
    It's just a conversion to base 26 poorly coded.

    Second this. Lousy programming but not really a WTF.

  • (cs) in reply to bl@h
    bl@h:
    I'd like to see Sesame Street sing a song about The Arralphalet
    ZABC-DEF-GHI-JKL-MNOP-QRS-TUV-WXY-ArrayIndexOutOfBoundsException
  • anon (unregistered) in reply to Someone You Know

    @316979 - yeah, well you sound smart now, but you'll get yours in post 325418

  • JB (unregistered) in reply to Mike D.
    Mike D.:
    Adam:
    I've always felt content knowing that in the UK our buildings start with a Ground Floor (Floor 0) whereas in the states they start off at Floor 1.
    Do they skip the 13th floor, like here?
    Here in Michigan, USA we have Ground Level and floor 1 starts above that.
  • The Nerve (unregistered) in reply to Jay
    Jay:
    veniam:
    I see. So we're going to get rid of static methods entirely?

    Hopefully yes. There is no reason for them to exist.

    A Util class is not object-oriented. Try to define its responsibility. If you write "it's supposed to hold everything that doesn't fit elsewhere" and compare that to other classes' responsibilities, you'll see that you have a beast that should be killed.

    And existing Java libraries are no excuse to repeat their mistakes.

    I might let you keep one static main() to get things rolling.

    Okay, I'll bite.

    So let's say we agree that we're going to abolish the Math class as anti-OOP. Now in a program you discover that you need to calculate a square root. How will you implement a square root calculation?

    If the need comes up in, say, the distance calcuation of your Point function, you could implement it inside the "calculateDistance(Point otherPoint)" function. But then suppose you need to calculate square roots in some other class, too. Will you reimplement the same algorithm?

    Indeed, what if the class where you need to find a square root needs it in two places. Will you implement the algorithm twice, once in each place? Or will you break this out into a common function? That common function will presumably take one parameter and return one value. It has nothing to do with the rest of the state of the object, so it may as well be static. Or will you tie the function to one particular value, just so you can meet the goal of being "more object-oriented". But then if you need it to operate on two different values, what will you do? Create a dummy member field just to hold the value you want to find the square root of? What would be gained by this?

    You could create an object to hold numbers to have miscellaneous mathematical operations performed on them. That is, you could create a MathOps object that takes an int in its constructor, so you could write something like:

    int n=... whatever ...;
    MathOps nn=new MathOps(n);
    rootN=nn.squareRoot();
    

    This would be more OOPish, but what does it gain over

    rootN=Math.squareRoot(n);
    

    It's more line of code to write creates an additional object on the heap, consuming time and memory. The only apparent advantage is that it preserves the abstract goal of being more OOPish.

    I suppose you could say that we should abolish primitives and make all numbers objects, so that our Integer object could then have a square root function.

    But what if someone creates a final object that doesn't include a function I need? Or they create an object whose internals are obscure enough that it would be difficult or risky for me to extend it to add the functions I need?

    Yeah, this is a problem similar to Cargo Cult. It occurs when the programmers involved don't know WHY something is supposed to be OO: they just known that it's supposed to be. There are design patterns designed to address the problems you list above. However, implementing a lot of them is more complicated than the easy solution. So before you ask yourself how you're going to create something, consider the following:

    1. Is it low complexity?
    2. Is it easy to maintain?

    If the answer to the above is not yes in both cases, then think of another solution.

  • Dan (unregistered) in reply to MOD26
    MOD26:
    Have a math class attached to a number class could be great. Like this you don't touch your code when you want to do complex calculation or infenitesimal calculation etc.

    I hate this class Math, it blocks all the abstraction pattern.

    I think the people at Sun decided that performance is more important than a religious ideal. So they left ints as primitives instead of automatically creating an Integer instance like Python does every time a new number comes into existence in its little world.

    Nothing wrong with static methods either. If the method neither needs state information from an instance nor modifies such state, why force it to take a "this" pointer?

    And why not put stateless functions of general use within a general class? If your answer is simply "Because that's not OOP", then you are more religious than practical.

  • The Nerve (unregistered) in reply to Dan
    Dan:
    If your answer is simply "Because that's not OOP", then you are more religious than practical.

    +1

  • (cs) in reply to Dan
    Dan:
    I think the people at Sun decided that performance is more important than a religious ideal. So they left ints as primitives instead of automatically creating an Integer instance like Python does every time a new number comes into existence in its little world.

    I much prefer the .NET approach- do both! It does mean that the compiler has to be smart about how it handles boxing and unboxing, and bad programmers can really screw themselves with it if they're not careful, but .NET value-types are full fledged objects that are handled by the system as primitives.

  • (cs) in reply to The Nerve
    The Nerve:
    Yeah, this is a problem similar to Cargo Cult. It occurs when the programmers involved don't know WHY something is supposed to be OO: they just known that it's supposed to be. There are design patterns designed to address the problems you list above. However, implementing a lot of them is more complicated than the easy solution. So before you ask yourself how you're going to create something, consider the following:
    1. Is it low complexity?
    2. Is it easy to maintain?

    If the answer to the above is not yes in both cases, then think of another solution.

    And yet it seems that almost every time my code gets reviewed by the senior devs at work, their comments boil down to "make this more complicated." Never mind that method bar() in class Foo has a meaning specific to this class - it accesses an external service, so it should go in its own class!

    Also: I strongly despise Java's requirement that everything be inside a class.

    Also: I strongly despise Java. Maybe someday I'll get a job not requiring it...

  • (cs) in reply to Remy Porter
    Remy Porter:
    Dan:
    I think the people at Sun decided that performance is more important than a religious ideal. So they left ints as primitives instead of automatically creating an Integer instance like Python does every time a new number comes into existence in its little world.

    I much prefer the .NET approach- do both! It does mean that the compiler has to be smart about how it handles boxing and unboxing, and bad programmers can really screw themselves with it if they're not careful, but .NET value-types are full fledged objects that are handled by the system as primitives.

    That makes no sense. The only reason you need auto-boxing is if you integer are not objects. But I am not sure: Are integers objects in .net (That is: If i do a int myVal=42. myVal.doSomething();

    Will the call to doSomething create a new object?

  • (cs) in reply to Fedaykin
    Fedaykin:
    Mike D.:
    Mr. Spontaneous:
    I may be putting myself up for ridicule here, but what is the problem with a Util class for widely used methods in strict OOP languages? I understand that you don't want to throw everything in there.
    If it doesn't manipulate the object, it doesn't need to be in the object. So a 'Util' class makes no sense unless you're creating 'Util's.

    Which is the way things work in theory and a good goal. However, in the real world some classes, like String, are final...

    Damn you Sun, damn you!

    Making string non-final would not solve many things as long as instances still need to non-mutable.

    But even if you could inherit from String in order to add needed methods to the String class, this would still be result in a wtf because what happens with all the strings which come from other parts of the system.

    They could then not be used as argument for one of your methods because you expect an expandedString.

    And things get even worse when you realize that other groups might also want to add methods to the String class, making it impossible to use your string class with their methods.

    Which is why it is a sound and correct design that all methods in String are there because they use the internal implementation of string, and other methods which use strings as values(Such as regexp, advanced search and so on) are utility functions which take a string as argument.

    The other alternative is to allow injection of methods in existing classes at runtime but Java does not support this. Most likely because the jit would have a hell of a time trying to validate and optimize method injection.

  • (cs) in reply to tiller
    tiller:
    That makes no sense. The only reason you need auto-boxing is if you integer are not objects. But I am not sure: Are integers objects in .net (That is: If i do a int myVal=42. myVal.doSomething();

    Will the call to doSomething create a new object?

    Maybe. The .NET compiler does weird stuff with boxing and unboxing, but when you say "int myVal=42", .NET allocates 32-bits and stores the Integer in them. When you say, "myVal.ToString()" .NET boxes it as an object- but I'm fairly certain that the compiler doesn't always create a new object every time it boxes. I believe it maintains a pool of boxes. I could be mistaken on that part though.

  • (cs) in reply to tiller
    tiller:
    Making string non-final would not solve many things as long as instances still need to non-mutable.

    Nah. Non-mutable strings aren't hard to deal with, not when you've got functional programming elements in your language (I'm told Java has added lambdas). I tend to write a lot of code as non-mutable, but I'm the sort of person that likes LISP, so I'm a bad example.

    The point is: non-mutable strings aren't a big deal- methods that operate on a string in a mutable fashion simply need to return a new string as their result.

    And it is possible to solve the inheritance problem as well, without wrapping it up in Util classes- there are design patterns specifically for cases where you can't inject or inherit on objects.

  • (cs) in reply to Remy Porter

    To Remy Porter: Boxing and unboxing shouldn't even be necessary to treat primitives as objects, as long as the primitive types cannot be subclassed. Since no polymorphism is possible, the compiler can just pass the primitives as an invisible parameter to their methods, essentially doing what one would do explicitly in a non-OO language.

    To all the people whining about OO as a religion: there are a number of programming paradigms in which everything in the language can be treated as a single meta-type. For example, there's a functional language in which everything is a function - it's called the lambda calculus.

    When everything is an object, it's often not necessary to add syntactic salt to declare that things are objects, as it is in an impure OO language like Java. In a truly pure OO language, declaring a global variable or function would be trivial, since it would just be a member of the containing package/namespace - which is a singleton object, right? Static methods would be members of a singleton object with the same name as the type corresponding to the class they are declared in. And of course, these singletons would be able to implement interfaces, unlike static methods in Java.

    ... Java should never, EVER be used as an example in OO debates. Most of its language features and libraries are backwards-compatibility remnants from its early days, which were apparently before they hired software engineers who knew what they were doing. Primitive types that aren't objects, arrays that don't implement the standard collection interfaces, static members, utility classes, etc., etc., etc. are all examples of this. Also, Java doesn't have a mechanism for extending existing types without access to the original source code, which is another reason for the abundance of utility classes.

    One more thing: almost all of the optimizations that can be done by hand with non-OO design can be done automatically by the compiler if the type system is strong enough. Const-correctness helps a lot, but sadly few OO languages support it.

  • The Nerve (unregistered) in reply to arotenbe
    arotenbe:
    Java doesn't have a mechanism for extending existing types without access to the original source code

    That's pretty funny, considering every class I have ever written extends java.lang.Object or one of its derived classes.

    Are you looking for header files or something?

Leave a comment on “The Arralphalet”

Log In or post as a guest

Replying to comment #:

« Return to Article