Implicit Promotion of value to Values?

18 views
Skip to first unread message

Stefan Marr

unread,
Aug 4, 2015, 11:28:00 AM8/4/15
to newspeak...@googlegroups.com
Hi:

Getting now slowly a little bit of experience with Newspeak and actors, I wonder what your opinion on the treatment of values is that fulfill the requirements for Value.

In my implementation, I decided to automatically promote all values to be Value.
[Technically it is currently a flag, and is not exactly the same as mixing in Value, but it probably should be eventually.]

However, this can be confusing and unexpected.

I just implemented a little benchmark (https://github.com/smarr/SOMns-corelib/commit/8579c2bc7c4f8c0483b97844a841c2ae79d5adcf)
and was confused by the resulting behavior.

I defined a ProducerActor class without any mutable field, which makes it a Value implicitly (outer scope is immutable as well).
However, I actually wanted to get a far reference to an instance of that class instead of the instance directly, because that’s how the benchmark is supposed to be working (taken from an existing benchmark suite).

Now I wonder whether it would be better to require that Value is mixed in explicitly to get value semantics.
That of course has the tradeoff that perhaps many interesting values are not easily shared because the relevant classes didn’t mixin Value.

As a work around for the moment, I just added a mutable field to the ProducerActor, which makes sure that I get the desired far reference.

Would be interesting to hear your opinions on the topic.

Thanks
Stefan

--
Stefan Marr
Johannes Kepler Universität Linz
http://stefan-marr.de/research/



Ryan Macnak

unread,
Aug 5, 2015, 12:17:02 AM8/5/15
to newspeak...@googlegroups.com
On Tue, Aug 4, 2015 at 8:26 AM, Stefan Marr <goo...@stefan-marr.de> wrote:
Hi:

Getting now slowly a little bit of experience with Newspeak and actors, I wonder what your opinion on the treatment of values is that fulfill the requirements for Value.

In my implementation, I decided to automatically promote all values to be Value.
[Technically it is currently a flag, and is not exactly the same as mixing in Value, but it probably should be eventually.]

You mean removing the requirement that value objects must have a class that inherits from Value? I'd lean toward keeping the requirement. It seems easy to unintentionally leak data across actors without it.
 
However, this can be confusing and unexpected.

I just implemented a little benchmark (https://github.com/smarr/SOMns-corelib/commit/8579c2bc7c4f8c0483b97844a841c2ae79d5adcf)
and was confused by the resulting behavior.

I defined a ProducerActor class without any mutable field, which makes it a Value implicitly (outer scope is immutable as well).

The enclosing object has a promise-resolver pair. I don't think either promises or resolvers qualify as value objects, so ProducerActors shouldn't qualify either.
Reply all
Reply to author
Forward
0 new messages