The Artima Developer Community
Sponsored Link

Akka Concurrency Forum
Raw Strings not type safe: Page 91

4 replies on 1 page. Most recent reply: Jan 15, 2013 5:23 AM by Derek Wyatt

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 4 replies on 1 page
Mirco Dotta

Posts: 4
Nickname: mirco
Registered: Jul, 2011

Raw Strings not type safe: Page 91 Posted: Dec 2, 2012 2:32 PM
Reply to this message Reply
Advertisement
Hi Derek,

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 [1], 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".

[1] http://www.cis.upenn.edu/~bcpierce/tapl/


Derek Wyatt

Posts: 64
Nickname: dwyatt
Registered: Oct, 2012

Re: Raw Strings not type safe: Page 91 Posted: Dec 3, 2012 5:42 AM
Reply to this message Reply
> 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

vs.

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

vs.

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.

Mirco Dotta

Posts: 4
Nickname: mirco
Registered: Jul, 2011

Re: Raw Strings not type safe: Page 91 Posted: Dec 6, 2012 10:56 AM
Reply to this message Reply
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).

Oscar Vargas Torres

Posts: 4
Nickname: 85168
Registered: Dec, 2012

Re: Raw Strings not type safe: Page 91 Posted: Jan 14, 2013 8:13 PM
Reply to this message Reply
This was confusing for me too.

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.

Derek Wyatt

Posts: 64
Nickname: dwyatt
Registered: Oct, 2012

Re: Raw Strings not type safe: Page 91 Posted: Jan 15, 2013 5:23 AM
Reply to this message Reply
I'll see what I can do.

Flat View: This topic has 4 replies on 1 page
Topic: graphics tool? Previous Topic   Next Topic Topic: footnotes


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us