• Uncle Al (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.

    When you get around to implementing a Singleton design pattern without something like a static method/variable, be sure to let us know how that worked out for you. And if you've never been in a situation where a Singleton was the right answer, I question the breadth of your experience.

  • (cs) in reply to The Nerve
    The Nerve:
    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?

    Subtyping != extension.

    Subtyping is used to implement abstract parts of an interface, while extension adds functionality to an existing object. Java's "extends" syntax for subtyping is heavily misleading, as is its ability to inherit from concrete classes. ("final" is your friend.)

    What I was referring to is something like C#'s extension methods. If you aren't familiar with those, I suggest Google.

  • (cs)

    Generally I find that programmers that claim "everything in an OO language must be OO", are also the same programmers who fail to realize the impact of having a million methods on a type, as opposed to having a small number of (frequently-used) methods on the type and the less-frequently-used methods in utility clases.

    But hey, what do Sun, Microsoft, et al. know about designing programming languages? I'm sure each of the first-year CompSci students promoting OO purity here, could design a better language than these industry giants. Of course, it would be slow as shit and horrible to use, but hey, it's completely OO, so all other considerations aren't important!

    There is a time and a place for everything, OO and utility classes included. A good programmer knows when to use them and when not to; a bad programmer tries to force the same pattern on everything, and their code ends up on this site.

  • (cs) in reply to arotenbe
    arotenbe:
    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.

    You're correct. I just double checked- value types only need to be boxed when they're interacting with data structures that aren't generic. Another good reason to use generics.

    Basically, in .NET, if you put integers in an ArrayList, they need to be boxed, but if you put them in a List<Int32> they don't.

  • (cs) in reply to The_Assimilator
    The_Assimilator:
    Generally I find that programmers that claim "everything in an OO language must be OO", are also the same programmers who fail to realize the impact of having a million methods on a type, as opposed to having a small number of (frequently-used) methods on the type and the less-frequently-used methods in utility clases.

    OOOOORRR, you could do the right thing and apply one of the many design patterns that retain object purity, avoid spaghetti code, and keep your code maintainable while solving that problem.

  • (cs) in reply to Remy Porter
    Remy Porter:
    arotenbe:
    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.

    You're correct. I just double checked- value types only need to be boxed when they're interacting with data structures that aren't generic. Another good reason to use generics.

    Basically, in .NET, if you put integers in an ArrayList, they need to be boxed, but if you put them in a List<Int32> they don't.

    Meanwhile, in Java, generics are erased at compile-time, so this is impossible.

    Further proof that C# is just Java with most of the stupid sucked out. (And some stupid added, but you can avoid it if you want to.)

  • North Shore Beach Bum (unregistered) in reply to Remy Porter
    Remy Porter:
    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.

    Autoboxing of primitives was introduced in Java 5. Before then, one would have to call the valueOf method of whatever numeric type was wanted (Float, Integer, etc). These numeric types are still immutable, so a new object would have to be created to hold the result of the operation. Putting the math operations on the individual numbers would have carried a heavy performance hit.

    Today I would like to see sqrt and its ilk delegated to the numbers. Can you imagine 4.sqrt()?

  • (cs) in reply to North Shore Beach Bum
    North Shore Beach Bum:
    Today I would like to see sqrt and its ilk delegated to the numbers. Can you imagine 4.sqrt()?

    Yes, but it's multivalued.

  • Ben (unregistered) in reply to arotenbe
    arotenbe:
    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.

    And no one writes actual code in lambda calculus, just as no one writes actual code with Turing machines. Various ML derivatives like Haskell have a rich and varied set of meta-types, to include machine types, algebraic types, types themselves, and, yes, functions. And none of them are the red-headed stepchildren the way non-objects are in an OOP environment.

    In a truly pure OO language, declaring a global variable or function would be trivial...

    But there is no "truly pure OO language." Turing machines are real. The lambda calculus is real. So there is a solid mathematical basis for imperative languages and functional languages. But attempts at forming a basis for OO languages have all been miserable failures. The Liskov substitution principle can't even get a simple type hierarchy like "A square is-a rectangle" to work.

    Without that mathematical basis, you're basically left with a "no true Scotsman" argument.

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

    Oh, please. You're seriously saying that if Sun's people "knew what they were doing" they would have broken backwards compatibility?

  • (cs) in reply to North Shore Beach Bum
    North Shore Beach Bum:
    Today I would like to see sqrt and its ilk delegated to the numbers. Can you imagine 4.sqrt()?

    In Ruby, it's quite common to see loops implemented as things like

    10.times { //code }
    .

    Even in .NET and Java, you can call functions on String literals: "Foo".toCharArray()[2] for example.

  • The Nerve (unregistered) in reply to arotenbe
    arotenbe:
    Remy Porter:
    arotenbe:
    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.

    You're correct. I just double checked- value types only need to be boxed when they're interacting with data structures that aren't generic. Another good reason to use generics.

    Basically, in .NET, if you put integers in an ArrayList, they need to be boxed, but if you put them in a List<Int32> they don't.

    Meanwhile, in Java, generics are erased at compile-time, so this is impossible.

    Further proof that C# is just Java with most of the stupid sucked out. (And some stupid added, but you can avoid it if you want to.)

    Ah, the advantages of having a language developed 7 years later vs. the disadvantages of backwards compatibility.

    It seems like many people think that TRWTF here is Java. That is TRWTF.

  • (cs) in reply to Ben
    Ben:
    But there is no "truly pure OO language." Turing machines are real. The lambda calculus is real.

    And that's why I advocate using functional languages that are provable subsets of lambda calculus. Because they're awesome.

  • Ben (unregistered) in reply to Uncle Al
    Uncle Al:
    And if you've never been in a situation where a Singleton was the right answer, I question the breadth of your experience.

    Whereas your knowledge of Singleton clearly demonstrates that the breadth of your experience extends at least as far as chapter 1 of "Teach Yourself Design Patterns in 30 Days."

  • Very Inspiring Racist Narrative (unregistered)

    You speak Spanish. Therefore you are a half-breed and must die. You speak French. Therefore you are a half-breed and must die. You speak Italian. You are a half-breed and therefore must die. You are not of the Klan. Therefore, you are a half-breed and must die.

  • (cs) in reply to Ben
    Ben:
    And no one writes actual code in lambda calculus, just as no one writes actual code with Turing machines. Various ML derivatives like Haskell have a rich and varied set of meta-types, to include machine types, algebraic types, types themselves, and, yes, functions. And none of them are the red-headed stepchildren the way non-objects are in an OOP environment.
    You got me there, and that was a stupid argument on my part. Let's try a different argument. Object-orientation represents a fundamental concept in programming, namely reification. "Everything is an object" really means "everything can be treated as a first-class object", which is an extremely useful and powerful concept.
    Ben:
    But there is no "truly pure OO language." Turing machines are real. The lambda calculus is real. So there is a solid mathematical basis for imperative languages and functional languages. But attempts at forming a basis for OO languages have all been miserable failures. The Liskov substitution principle can't even get a simple type hierarchy like "A square is-a rectangle" to work.

    Without that mathematical basis, you're basically left with a "no true Scotsman" argument.

    It's not a No True Scotsman argument, because it's possible to quantify OO purity. Here's your metric: every concept in the language that is not reifiable within a single common type system is a step away from OO purity. And extremely pure OO languages exist (Smalltalk is the classic example).

    The square-rectangle argument is irrelevant. It's is an application domain problem, not a language problem; you'd have the same sort of issue in any other paradigm. Furthermore, it's one of the most trivially-solved examples - make the Rectangle and Square classes immutable! (And why shouldn't they be, it's not like mathematics allows squares to change shape.)

    Ben:
    Oh, please. You're seriously saying that if Sun's people "knew what they were doing" they would have broken backwards compatibility?
    Yes. See every language that has ever broken backward compatibility to fix mistakes made early on. Python 3, anyone?
  • (cs)

    We've got a bunch of ivory tower crap going on here today. To me, programming is a means to an end. Doing it in a simple, pragmatic manner trumps theoretical ideals. Always.

  • (cs) in reply to veniam
    veniam:
    I might let you keep one static main() to get things rolling.
    I see no reason why you can't just have a class that implements an abstract java.lang.Program (made up name; no clue if it already exists) which has a main method. :) The VM would then know that your main class has to inherit that class, would instantiate it, and invoke your main method. No need for static. I actually find it sort of awkward defining everything as static when writing a simple C# program, where your code just consists of various methods (functions, really) that are called from main. At least if the application was actually an instance then it would sort of make sense defining it as a class. ;D
  • eporter (unregistered)

    I have people code this in Java all the time during interviews. Many people can't get it working at all and some do things that are very complicated. This is one of the worst I've seen but at least it works. I ask interviewees to code it 0-indexed, not 1-indexed like this one is. I'm looking for something like this:

    public static String toColumnName(int index) {
        	Validate.isTrue(index >= 0, "The column index must be >= 0: " + index);
        	StringBuilder buf = new StringBuilder(5);
        	for ( ; index >= 0; index = index / 26 - 1) {
        		buf.append((char) ('A' + (index % 26)));
        	}
        	return buf.reverse().toString();
        }
    
  • The Nerve (unregistered) in reply to frits
    frits:
    We've got a bunch of ivory tower crap going on here today. To me, programming is a means to an end. Doing it in a simple, pragmatic manner trumps theoretical ideals. Always.
    [image]
  • Anoncow (unregistered) in reply to The Nerve

    Hey! That was on Wikipedia's front page today! The article kind of relates here.

    The tower began to sink after construction had progressed to the third floor in 1178. This was due to a mere three-metre foundation, set in weak, unstable subsoil, a design that was flawed from the beginning.

    Ok, so they're 3 floors up, and the building is sinking. What would you do?

    In an effort to compensate for the tilt, the engineers built upper floors with one side taller than the other. This made the tower begin to lean in the other direction.

    Oh, man. Starting to sound more and more like a software solution all the time.

    On February 27, 1964, the government of Italy requested aid in preventing the tower from toppling. It was, however, considered important to retain the current tilt, due to the vital role that this element played in promoting the tourism industry of Pisa.

    There's backwards compatibility for ya. Design flawed from the beginning leads engineers to jump through hoops to keep the building up nearly 1000 years later.

    Pictures are funny. Check out the ones where you actually have to walk through the door, which is at an angle.

  • (cs)

    Anything worth doing is worth doing in as abstruse a manner as possible.

  • YE OLDE (unregistered) in reply to Remy Porter

    eh?! creating a util class is breaking oop?! you are smoking something

  • Troy (unregistered) in reply to veniam

    Really!?!? So, how would you get an instance of a singleton?

  • Schol-R-LEA (unregistered) 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.

    I sincerely hope you are both joking, and that you do in fact know what class methods are meant for.

    Though I suppose Veniam could simply be in favor of prototype-based OOP rather than class-based OOP, or just dislikes OOP in general...

    odio - the original code was indeed odious

  • NFG (unregistered) in reply to frits
    frits:
    We've got a bunch of ivory tower crap going on here today. To me, programming is a means to an end. Doing it in a simple, pragmatic manner trumps theoretical ideals. Always.

    Hurrah!

  • Troy (unregistered) in reply to Ben
    Ben:
    Uncle Al:
    And if you've never been in a situation where a Singleton was the right answer, I question the breadth of your experience.

    Whereas your knowledge of Singleton clearly demonstrates that the breadth of your experience extends at least as far as chapter 1 of "Teach Yourself Design Patterns in 30 Days."

    It is so nice that you have added a constructive comment. I wonder what your argument would be for a non-static get instance on a singleton.

  • (cs) in reply to Erik
    Erik:
    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.

    QFT. Like so many other things, Delphi got OOP right where the C-derivatives screwed it all up.

  • Veldan (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?

    Fine, you made me bite.

    First off, remember that the distinction between types of numbers (int, double, etc.) is purely man made and mostly implemented for memory reasons.

    Hence a pure OO approach to the problem would be to have a number class (who'da thunk it?) which can be typed to behave like any required variable (int, double, long, short, so on...). This means that all numbers have access to the same methods AND can be typed to behave in certain ways for memory reasons or formatting.

    To paraphrase Shakespeare: An int by any other numeric variable would add just as sweetly...

  • unekdoud (unregistered)

    Hint: the code was written separately by two programmers.

    Object oriented numbers: cool! Program set inclusion according to http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers , and you will then need a math class to use the Math class.

  • Adam (unregistered) in reply to Adam
    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.
    But nobody says "Floor 1" they say "First floor." And ordinals start with First, not with zeroth. Nobody says "zrth post lololo"
  • CodeMacho (unregistered) in reply to North Shore Beach Bum
    North Shore Beach Bum:
    Today I would like to see sqrt and its ilk delegated to the numbers. Can you imagine 4.sqrt()?
    using System;
    static class Test
    {
      static double Sqrt(this double value)
      {
        return Math.Sqrt(value);
      }
    
      static void Main()
      {
        Console.WriteLine(5.0.Sqrt());
      }
    }

    Welcome to crazy world of C#. captcha: vindico

  • blunder (unregistered)

    I've never understood why Java arrays are objects but their methods are in a separate library. Assuming there's a reason, would anyone care to point me at some reading material?

    On a side note, the overgeneralizing in this thread is getting to me. Obviously pragmatism has value, but sometimes "I used the practical solution" is shorthand for "there's probably a pattern for this, but I was too lazy to learn it. As a result I've reinvented the wheel badly... have fun tracing!"

  • (cs) in reply to arotenbe
    arotenbe:
    Subtyping != extension.

    Subtyping is used to implement abstract parts of an interface, while extension adds functionality to an existing object. Java's "extends" syntax for subtyping is heavily misleading, as is its ability to inherit from concrete classes. ("final" is your friend.)

    What I was referring to is something like C#'s extension methods. If you aren't familiar with those, I suggest Google.

    Java's "extends" keyword does just that: it extends a class. You can implement an abstract method, or override the behaviour of an existing method, or add a new method.

    C#'s extension methods do not, in fact, extend a method: they just pretend that they do, and essentially it's syntactic sugar hiding a utility class with static methods.

    What you're complaining about is Java's reluctance for syntactic sugar (the enhanced 'for' loop as one of the few examples).

    But on the other hand, if in one piece of code you have a class with a certain method and in another piece of code that class does not have that method, that's not what I would call clarity.

  • Brit Banking Contractor (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?

    Nah we stop at every floor. Our buildings make much more sense - it's very confusing working in an American building if you're from the UK!!

  • Sergeant Flippy (unregistered)

    /**

    • The utilize methods. */

    French-speaking programmer by any chance? they regularly leave you with crap like:

    public string MethodeGetLangue(string motDuLangue){}

    which is about as pleasant as finding a lump.

    captcha: gravis, c'est tres gravis

  • (cs)

    ok now for my PROPER review of the code.

    public final class Util {
    
    /**
     * The ARRALPHALET chars .
     */
    private static final String[] ARRALPHALET = new String[] { 
    "Z", "A", "B", "C", "D", "E", "F", "G", "H", "I", "J",
        "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", 
    "V", "W", "X", "Y", "Z" };
    

    If we have to use an array here why can't we use an array of char? Not hugely familiar with Java details as to whether you can convert numbers to their ASCII equivalents and use arithmetic on them, thus 'A' is guaranteed to be exactly 25 less than 'Z' etc. If coding in C or C++ I would take advantage of this. Failing that I would create an array but I know in Java that strings are not arrays of characters.

        private static final int      VALUE       = 26;
    

    Ok, why the word VALUE? This is Utils::VALUE. Maybe we will have other utils and it does not make sense. Utils::LETTERS_IN_ALPHABET maybe. Maybe needs more typiing later in one place.

        public static String dec2Alpha(final int decimal) {
            final ArrayList<String> arrResult = new ArrayList<String>();
            int a = decimal;
            int b = decimal;
    
    Put a comment at the top of the function saying what it is meant to achieve.

    Does StringBuilder allow inserts at the front? Even if not I would think of whether we should be using StringBuilder.

    Don't use a and b here but a meaningful names.

            do {
                b = a / VALUE;
               final int c = a % VALUE;
                if (c == 0 && b == 0) {
                    arrResult.add(0, "0");
    
    This will happen only if number was originally 0.
                } else if (c == 0 && b != 0) {
                    b = b - 1;
    
    We have already determined that b and c are not both 0 because that was handled by the previous block, so the last test is redundant. Use --b rather than b = b-1 (with the more meaningful name, of course).
                    arrResult.add(0, ARRALPHALET[c]);
                } else {
                    arrResult.add(0, ARRALPHALET[c]);
                }
    
    We could have managed without doing that in both blocks by opening a brace between the else and the if above (rather than else if).
                a = b;
            }
            while (a > VALUE);
    
        if (a != 0) {
            arrResult.add(0, ARRALPHALET[a]);
        }
    

    but a could be equal to VALUE which is the only reason we need to make the array 27 in size.

        return StringUtils.join(arrResult.toArray());
    }
    

    }

    Probably does what we need to concatenate all the strings in our array, all of which were one character long.

    This is a good coding exercise I think to give to candidates applying for a job. The sort of thing you can ask them to do in their favourite programming language.

  • MOD26 (unregistered) in reply to someGuy

    Answer in two points :

    • With a good compiler it's not a problem.
    • And if time were always a relevant question, python, perl, java, .net won't exist.
  • (cs) in reply to MOD26
    MOD26:
    Answer in two points : * With a good compiler it's not a problem. * And if time were always a relevant question, python, perl, java, .net won't exist.

    Time always matters, just depends whether it's developer time, deployment time or execution time that you wish to optimise on.

  • methinks (unregistered) in reply to Remy Porter
    Remy Porter:
    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.

    Sorry, but no.

    It is extremely dangerous for "treated nearly as primitives"-classes to be mutable and non-final.

    Sun did get it right for String and the wrapper classes for primitives (which are all immutable and final), but screwed it up e.g. for java.util.Date, which is neither immutable, nor final, but still treated by most developers like a primitive, i.e. they are passing around instances which should (but do not) pose an invariant and are e.g. used as keys in collections. And then such instances get changed their value by some external part of the programm having a reference to the same instance whilst still being used as key - consequently wreaking complete havoc on the internals of the collection.

    It is for a reason that all mutators in java.util.Date are deprecated - which unfortunately does not stop anyone from using them anyways, ignoring each and every warning by the compiler - and afterwards complaining about "broken" or "slow" collection implementations...

    I also like LISP a lot and did my fare share with it, mostly for fun - but admiring and liking its concepts does not by itself a good OO-developer make...

  • Indrek (unregistered) in reply to Mike D.
    Mike D.:
    CAPTCHA: dignissim <- Okay, now you're just making these up.
    Try reading it backwards. dignissim -> missingid -> missing ID. The captcha is trying to tell you something...
  • tragomaskhalos (unregistered) in reply to Hugh Brown
    Hugh Brown:
    For me, TRWTF is that it's not written in python:
    from string import uppercase
    def dec2alpha(num):
    	result = []
    	while num:
    		num, x = divmod(num, 26)
    		result.append(uppercase[x])
    	return "".join(reversed(result)) or "A"
    In Ruby you could just do:
    def dec2alpha(num)
      c="A"
      num.times{c.succ!};c
    end
    
  • Dann (unregistered) in reply to Mike D.

    13th Floor? We don't even have a 13th House. http://www.stuff.co.nz/oddstuff/2441831/No-number-for-witches-in-Palmy/

  • (cs) in reply to Severity One
    Severity One:
    Java's "extends" keyword does just that: it extends a class. You can implement an abstract method, or override the behaviour of an existing method, or add a new method.
    That's true, but it also completely misses the point. Inheritance is used for "is-a" relationships. An Integer is a Number. Inheritance adds functionality only in the sense of adding specificity - e.g. you can take the twos complement of an integer, but it wouldn't make much sense for, say, a rational number.

    But when you want to add functionality to an EXISTING object, you need to use composition. You can't just subclass any random type to add functionality to that type. Well, actually, I take that back - you can, and many programmers do, inherit from classes that were never meant to be inherited from for the sole purpose of adding functionality. It's conceptually nonsensical and practically counterproductive, but that doesn't stop people from doing it.

    Severity One:
    C#'s extension methods do not, in fact, extend a method: they just pretend that they do, and essentially it's syntactic sugar hiding a utility class with static methods.
    C#'s extension methods are a bit of a bad example. They're rather limited, in that you can't define an overridable extension method for a superclass and then override it polymorphically with an extension method for a subclass. If this were possible, it would completely obviate the Visitor pattern and allow better separation of concerns. But, in order to do that, it would be necessary to have a concept of types that can contain functionality but not data (sometimes called "mixins" and occasionally and incorrectly "traits"), which Java butchered into types that can contain only abstract functionality without concrete implementation ("interfaces").
  • Anonymous (unregistered) in reply to Adam
    Adam:
    Nobody says "zrth post lololo"
    Well not up until *NOW* they didn't... I'll bet you just gave everyone a great idea for a new twist on "frist". ;-)
  • Varcour (unregistered)
    Or it could be that method for turning letters into numbers.

    Or rather turning numbers into letters?

  • CMMI Snob (unregistered) in reply to anon
    anon:
    You have failed when you don't know what an acronym is. It's actually impossible for an acronym to take more letters than the words it is an acronym for, since an acronym is comprised solely of the letters in those words.

    frist +1... or is that FRIST?

    captcha: suscipit - wtf?

  • someone (unregistered) in reply to Cbuttius
    Cbuttius:
    [I]s there not an unsigned int in Java?
    Correct--there is not an unsigned int in Java. I've heard that their rationale is that it would "confuse the language" or something like that. It's very inconvenient.
  • Neil (unregistered) in reply to Big Excel Sheet
    Big Excel Sheet:
    13733 319786 16074 253 356974 9 274076222 1963523940 4129617901 2097999 357181
    I thought I'd decode this using HTML. But
    doesn't work in either of the 64-bit browsers I tried; they must still be using 32 bit list numbering internally.

    Interestingly you can however encode/decode bigger numbers using Netscape 7.1 (or later) Composer's List Properties dialog, which goes up to about 15 digits, although the resulting numbers do not display properly in the actual list.

  • vydf (unregistered) in reply to JdFalcon04
    JdFalcon04:
    The beginning "Z" value in the array is likely so that A maps to 1 instead of 0. I was honestly taught to do things like this in a business "programming" class that a few of us Comp Sci majors took for a laugh. Apparently 0-based values are MUCH more confusing than 1-based ones.

    People teaching this should be fired. Out of a cannon into the sun.

  • Jay (unregistered) in reply to Fred
    Fred:
    /** * 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.

    Never use a big word when a diminutive one will do.

Leave a comment on “The Arralphalet”

Log In or post as a guest

Replying to comment #:

« Return to Article