• (nodebb)

    Not only he doesn't understand object oriented programming, he apparently doesn't understand functional programming, either.

    In fact, he looks like he doesn't understand programming at all.

  • Registered (unregistered)

    He's actually pioneering Dis-functional programming

  • GreatGobo (unregistered) in reply to Mr. TA

    I must admit, that I have serious problems even reading the code...

    There are two references to Url (uppercase U) and I have no idea where they are coming from or what it is supposed to mean. Help...

  • Jonathan (unregistered)

    This is a typed string concept where the idea is that it’s less likely to accidentally populate the incorrect string value between types.

    We tied this on a C# project about 10 years ago and although it helped avoid a certain class of mistake, overall it didn’t really feel worth it.

    It might be nice if C# had this as a more first class feature, but until then it’s too much of a pain.

  • Hanzito (unregistered)

    Does the extract function use a global? Or in seniorese: the singleton factory pattern?

  • OM222O (unregistered)

    Poor Remy ... "a private member with no accessors"? "It doesn't use the UrlHolder, because of course it couldn't"? TRWTF is Java reflections because you can easily get, set and modify private variables with reflections and stringly typed field names :) The even more RWTF is the Java standard library and things like sun.misc.unsafe which are by design meant to be used only with reflections :) Below code is not a joke, it is how you use most built in libraries in Java (such as sun.misc.unsafe, java.security.MessageDigest, etc.)

    Field f = Unsafe.class.getDeclaredField("theUnsafe"); f.setAccessible(true); unsafe = (Unsafe) f.get(null);

  • (nodebb)
    // does reading a local file satisfy the definition of "download"?
    // a book contains lots of pages, so we have our bases covered there!
    String s = File.readAllText("c:\\Shakespeare_Hamlet.txt"); 
    
    // if you think the below class instance holds a URL,
    UrlDownloader ud = new UrlDownloader("http/::this can be a URL, or [email protected]");
    // then you are wrong!
    ud.downloadPage = s;
    
    UrlLinkExtractor ule = new UrlLinkExtractor (ud);
    String[] extractedLinks = ule.extract();
    // result: "Ophelia, by some critics, can be seen as honest and fair; 
    // however, it is virtually impossible to link these two traits, since 'fairness' 
    // is an outward trait, while 'honesty' is an inward trait."
    
  • (nodebb)

    If these are inner classes (which they appear to be), you can access private members without doing anything special like reflection, so UrlHolder isn't useless. This compiles and runs perfectly fine:

    public class Test {
    	public static void main(String[] args) {
    		new Test().foo();
    	}
    
    	void foo() {
    		UrlHolder holder = new UrlHolder("www.example.com");
    		System.out.println(holder.url);
    	}
    	
    	class UrlHolder {
    		private String url;
    		
    		public UrlHolder(String url) {
    			this.url = url;
    		}
    	}
    }
    

    It's still a WTF if they don't actually use the UrlHolder's value though.

  • Willy (unregistered) in reply to OM222O

    you must be more "senior" than me because in 20 years I have never had to call a built in library this way

  • Naomi (unregistered) in reply to OM222O

    Er... Unsafe is used internally by the runtime. "By design", it isn't "meant to be used" at all, unless you're the runtime. Certain library authors have found that it's useful in certain highly specific reflective tasks, but they're knowingly using a highly internal implementation detail in an unsanctioned way. Newer versions of Java have introduced proper APIs for the functionality formerly provided by Unsafe.

    You're correct that reflection can be used to bypass access constraints. This is generally regarded as a bad idea in most cases, but has one really useful, er, use: a reflective library can provide a mechanism for a class to register a member with the library without making it part of the class's API. (This typically happens with default constructors.) Like everything in software, it's a tradeoff: it can be used to do terribly unsafe things, but I don't see that as a reason to prevent it entirely. Hell, even C++ has a standards-compliant template hack to access private members (and no, I don't mean #define public private).

  • (nodebb) in reply to Jonathan

    @Johnathan: So a very verbose form of Apps Hungarian. But with partial compile-time enforcement of correct usage.

    You can get from partial to total as long as you wrap every property and method parameter of every object in every API you use. Sounds ... laborious.

    Addendum 2024-11-18 11:06: I imagine the same effort spent on unit tests instead would produce far better software.

  • MRAB (unregistered) in reply to Registered

    No, it's Objectionable Programming.

Leave a comment on “Objectified”

Log In or post as a guest

Replying to comment #:

« Return to Article