Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:Security and IPv6 (Score 1) 166 166

That security is provided by RFC 4941 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6).

It's even better than IPv4 with NAT since it will actually rotate in new random IP addresses every so often (every hour or so). That means that your source IP will change over time which makes tracking harder.

Comment: Re:How about basic security? (Score 1) 390 390

If you are stupid enough to be running without a firewall, sure they your entire address space can be scanned. I hope they have lots of time though since even the smallest allocation gives you an address space of 18446744073709551616 addresses. That'll take a while to scan.

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

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 303

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 303

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 303

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 303

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.

The major difference between bonds and bond traders is that the bonds will eventually mature.