Moving the discussion about type safety from Twitter, so that we can fully express our points.
To give a bit of background to whoever is going to read this, the discussion started from the following comment I had: Toward the end of this page, you say: "We generally don’t use raw Strings to communicate with Actors due to the fact that it’s not type safe".
Why sending a raw string should not be type safe? I'd definitely agree that it is bad practice and should be avoided, but type safety here is not at stake.
Which determined a number of tweets between Derek and myself: Derek: @mircodotta Strings aren't "type safe" as messages because the compiler can't tell the diff betw "DoWork1" and "DoWork2".
Me: @derekwyatt While I of course agree with your point, the example in the book is based on an untyped actor, so why should that matter?
Derek: @mircodotta Untyped endpoints and strongly typed messages. You want the msgs strongly type, not the endpoints.
Me: @derekwyatt Sure, but how this has anything to do with type safety? There is likely smth that is not crossing the 140 chars barrier :-)
Derek: @mircodotta prolly not :) But, if you represented all your diff msgs as one type, you get no type safety. That's it.
I believe the source of confusion on my side is the definition of type safety that it's being used, so let's first agree on the definition.
If you ask me, type safety is about compile-time correctness, i.e., the compiler throws at you a compiler error if your program is ill-typed. (If we need a better definition, we should describe it in terms of Preservation and Progress , but I hope we can agree on a more practical and down-to-earth definition)
If you agree with this definition, then it should be clearer why I find confusing talking about type safety in the paragraph quoted from the book. The Scala compiler won't prevent you from sending a String message to an actor, therefore there is nothing (type) unsafe in using String as a message in Scala. I definitely agree with you that it is bad practice, and should be avoided. But, if you send a String message to an actor, your program will compile just fine and hence it is type safe by definition.
Bottom line, it appears to me that you are misusing the term "type safety".
> Bottom line, it appears to me that you are misusing the > term "type safety".
I don't disagree, but I don't necessarily agree either. The crux of my argument is about this:
case "Message" => // do something
case Message => // do something
In the first case, all of the client code is great - you've got actor ! "Message" everywhere that matters. The compiler doesn't know it's right, but it is. In the second case, you've got everything correct too, but the compiler understands it better.
The key is when you change it:
case "NewMessage" => // do something
case NewMessage => // do something
If you delete the Message type, then the compiler will tell you at each and every call site where things are guaranteed to go bad. In the first case, the compiler can't tell the difference between actor ! "Message" or someOtherActorAllTogether ! "My shoes are too tight".
Granular use of many different types gives you compile-time type safety. The use a single type to represent everything gives you squat.
Having real message types for refactoring purpose is absolutely a great point, one that you should definitely make in the book :) (I only read the first 6/7 chapters, so maybe you discuss this later on).
I understand that you'd rather "stretch" a bit the definition of type-safety to scare the heck out of people and force them into using proper types for messages.
But, in my opinion, your message will get trough much better if you discuss refactoring (a concept any developer is familiar with), rather than type-safety (a concept not that mainstream).
I would say the solution is to be more strict with the usage of terms. You might be giving an interpretation of the term that is not common, and therefore might be not the best way of expressing your thoughts.