Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment: Re:The answer has been clear (Score 1) 390

by lokedhs (#49516303) Attached to: Why the Journey To IPv6 Is Still the Road Less Traveled
Oh yes, the ICMPv6 issue is real. I made the same mistake when I configured my IPv6 firewall. It's subtle because things seem to work at first but connections just hang. And the behaviour from the client side is that "accessing Google is slow but other sites work". Of course, accessing any IPv6 site is slow, but the browsers won't tell you that.

Comment: Re:Missing the point (Score 1) 303

by lokedhs (#48771789) Attached to: Anthropomorphism and Object Oriented Programming
I've been consistent all along. you're the one who keeps moving the goal posts.

Let's pretend I'm stupid (which should be easy for you since you either seem to be convinced I'm intellectually inferior to you, or you are just being a condescending arse) and explain to me what part of method dispatch is done statically (in a "non-message-passing system" vs. dynamically in a "message-passing system").

Since you are arguing that these methods are so fundamentally different, I would expect to be able to see functionality in the latter that just can't be achieved in the former.

I argue that, once you strip out the terminology and look at what these systems actually do, there is not real difference.

Comment: Re:Missing the point (Score 1) 303

by lokedhs (#48755471) Attached to: Anthropomorphism and Object Oriented Programming
Saying something several times doesn't make it true. There is nothing in the behaviour of message passing that would prevent it from being compiled into a vtable call behind the scenes.

Of course, in highly dynamic systems you need to recompile method calls on the fly, but that is true for languages like Java as well, which also needs to do this.

Finally, CLOS has the most flexible method calling in existence. You can write your own methods that chooses the appropriate method to call (look up define-method-combination for the gritty details). Amazingly enough, it still manages to compile the method invocations into direct calls.

That said, the actual underlying implementation of the compiler is completely irrelevant in this case. The actual provided functionality available to the programmer, is. And from the point of view of the programmer, the difference between message passing and nay other calling style is minimal, at best.

Comment: Re:Missing the point (Score 1) 303

by lokedhs (#48734957) Attached to: Anthropomorphism and Object Oriented Programming
Clearly you never used CLOS. In CLOS, a generic function is called just like any function (in fact, you can compile a code that calls a generic function before that function has even been defined). Defining a GF means that the dispatcher function is created that allowed you to define methods on it.

The actual dynamic behaviour that you talk about has nothing to do with the object orientation at all. The "invokeMethod" that you talk of is simply the FUNCALL or APPLY functions that simply calls a function.

At the end of the day, regardless of how you choose to think about object orientation conceptually, all that really happens is that some code is called based on some property of the arguments that you pass in. The most common form is simply the choice of implementation based on the runtime datatype of the first argument.

Here's the important point: If I were to give the following statement: "Java uses message passing", it's actually very hard to contradict that. Every single feature and behaviour of message passing systems you mentioned above with the exception of having a fallback implementation can be replicated in Java with just a bit of reflection. If the designers of Java had really wanted (and IMHO, they should have) they could have added the necessary extra syntactic sugar to achieve that.

Whether or not an "actual" message object is constructed that is passed as an argument to a dispatcher, or if the compiler creates a vtable is really an implementation detail and as a programmer you very rarely, if ever, see the difference. You seem to have confused the difference between static and dynamic languages with that of object orientation style.

If you still feel the desire to reply, then I really would like to know how you categorise generic functions (in particular, the CLOS kind) in terms of message passing vs. something else.

Comment: Re:Missing the point (Score 1) 303

by lokedhs (#48729411) Attached to: Anthropomorphism and Object Oriented Programming
I'd argue that the difference is largely academic. They do refer to two distinctly different ways of thinking about it, but if you look at how method calls/message passing is actually implemented there is little difference. In both cases you request the invocation of a method, and there is a dispatcher that chooses at run time which actual implementation will be called.

Having the actual method implementation tied to a class (as is the case in most languages, including Java and C++) is again an implementation detail, albeit one that can limit the flexibility available to the programmer.

Extrapolating this further brings us to generic functions which are just plain functions which is a dispatcher to multiple implementations. I'm sure one can argue for hours whether or not that is message passing or not.

Comment: Re:Missing the point (Score 1) 303

by lokedhs (#48727283) Attached to: Anthropomorphism and Object Oriented Programming
Except in good object orientation systems, functions does not go with the data. That's a limitation introduced by Simula 67, which started a trend that survives till today, with Java, Ruby and all the other single-dispatch languages.

Far too many programmers these days seems to believe that object orientation is equivalent to the limited form available in languages like Java and C++. They would be helped by learning a language that has multiple dispatch before commenting on that object orientation is.

"Don't talk to me about disclaimers! I invented disclaimers!" -- The Censored Hacker

Working...