On Wednesday, 6 May 2015 at 17:01:05 UTC, Luís Marques wrote:
> That's sounds like a great story! What kind of "values" were you caching?

Without going into the details, we had entries in a DB, counting in the millions in the working set. Some of them where hammered heavily, most of them were only needed an handful of time. Problem is, there was no way upfront to know which ones, so we add there entries in a local cache, so we can find the heavily used ones in the cache, and fallback on the DB for the less commonly used ones.

On Wednesday, 6 May 2015 at 18:05:57 UTC, deadalnix wrote:
> Without going into the details, we had entries in a DB, counting in the millions in the working set. Some of them where hammered heavily, most of them were only needed an handful of time. Problem is, there was no way upfront to know which ones, so we add there entries in a local cache, so we can find the heavily used ones in the cache, and fallback on the DB for the less commonly used ones.

OK, so here the advantages of value vs ref types had to do "only" with allocation issues, and not (also) any advantages in how the values/objects were used per se. So, one could argue that this problem could also be solved through richer memory allocation primitives, without having to have value types?

BTW, given the GC behaviour you described, weak references wouldn't help, would they?

On Wednesday, 6 May 2015 at 18:28:28 UTC, Luís Marques wrote:
> On Wednesday, 6 May 2015 at 18:05:57 UTC, deadalnix wrote:
>> Without going into the details, we had entries in a DB, counting in the millions in the working set. Some of them where hammered heavily, most of them were only needed an handful of time. Problem is, there was no way upfront to know which ones, so we add there entries in a local cache, so we can find the heavily used ones in the cache, and fallback on the DB for the less commonly used ones.
>
> OK, so here the advantages of value vs ref types had to do "only" with allocation issues, and not (also) any advantages in how the values/objects were used per se. So, one could argue that this problem could also be solved through richer memory allocation primitives, without having to have value types?
>
> BTW, given the GC behaviour you described, weak references wouldn't help, would they?

It is not only with allocation issue, but that is certainly a benefit :)

Weak reference would have caused most of the cache to be scrapped at each GC cycle, so that would defeat the purpose of the cache to begin with.

At the end, we ended up using a quite complicated solution involving recycling objects in the cache.

On Wed, 06 May 2015 16:54:46 +0000, Luís Marques wrote:

> * Regular expressions -> I have no idea what you have in mind for this one; even after looking at std.regex...
I meant both patterns and matches/captures.

> * Tokens -> On the one hand, I think this could be an excellent example, since it's a case where the bit pattern is arbitrary (because it generally has no numeric properties). On the other hand, I could see people arguing that just using an int is perfectly fine, so it doesn't benefit from a custom type. Do notice that, even in D, an enum converts without a cast to an int, so the fact that an enum might be used to list the possible abstract values (the tokens) doesn't quite make it a completely independent type, IMHO.
By tokens I mean the output of a lexer, usually looking like:

struct Token
{
	Type type;
	uint line, uint col;
	string captured;
}

> * lazy generators -> explain, please?
Phobos is full of these.  A simple example is the result of std.range.iota.  The motivation is that a generator is actually an algorithm which happens to be wrapped up as a value.

> * digests -> do you mean the digest output, or the digest function state?
Certainly the output, haven't given much thought to the intermediate state.

>> Frankly, the real divide in my mind is polymorphic/non-polymorphic, not by-reference vs by-value, though I will occasionally use `final class` if I want a convenience reference type around a resource.
> 
> Aren't you arguing against yourself? In those cases you wanted your type to have reference semantics, even though it wasn't a polymorphic type. Doesn't that counterexample prove that polymorphic/non-polymorphic is just an heuristic, while the value/ref distinction is more fundamental?
Ideally they're orthogonal, though you need reference types to do true dynamic polymorphism.  Using `final class` is a pragmatic move given that D conflates reference types with polymorphic types, i.e. if there were a `ref struct` I'd use it.

On Tuesday, 5 May 2015 at 20:40:59 UTC, Luís Marques wrote:
> Hi,
>
> For a comparison with the Java language, I'm trying to come up with some good examples of custom types that should be value types (but that must be ref types in Java). I think the most obvious ones are numeric types. So BigNum, MyNum, etc. are good examples because programmers are used to numeric types being value types, and having them suddenly become a ref type just because it's MyNum instead of long is really annoying. Still, could you come up with some type that would really benefit from being a value type but that isn't numeric (or otherwise similar)?
>
> Thanks for your help!
>
> Luís
Immutable types?
It doesn't matter whether they are by value or by ref but by value usually has performance increases(especially considering you can by a value type by ref in D if you need to).

On Thursday, 7 May 2015 at 02:09:34 UTC, Freddy wrote:
> It doesn't matter whether they are by value or by ref but by value usually has performance increases(especially considering you can by a value type by ref in D if you need to).

Yep, this is very much true, but on x86 the register size is increasing so a good compiler could hold 512 bits in a register. If only compiler and backends weren't so far behind hardware developments...

On Tuesday, 5 May 2015 at 20:40:59 UTC, Luís Marques wrote:
> Hi,
>
> For a comparison with the Java language, I'm trying to come up with some good examples of custom types that should be value types (but that must be ref types in Java). I think the most obvious ones are numeric types. So BigNum, MyNum, etc. are good examples because programmers are used to numeric types being value types, and having them suddenly become a ref type just because it's MyNum instead of long is really annoying. Still, could you come up with some type that would really benefit from being a value type but that isn't numeric (or otherwise similar)?
>
> Thanks for your help!
>
> Luís

To add to what others have said - whenever you think you will benefit from stack-allocation. Read this article: http://www.ibm.com/developerworks/library/j-jtp09275/
Java is good at escape analysis. But I find it really useful to be able to specify a type that will always be allocated on the stack (unless you really want it on the heap).

On 5/7/15 4:15 AM, Dejan Lekic wrote:
> On Tuesday, 5 May 2015 at 20:40:59 UTC, Luís Marques wrote:
>> Hi,
>>
>> For a comparison with the Java language, I'm trying to come up with
>> some good examples of custom types that should be value types (but
>> that must be ref types in Java). I think the most obvious ones are
>> numeric types. So BigNum, MyNum, etc. are good examples because
>> programmers are used to numeric types being value types, and having
>> them suddenly become a ref type just because it's MyNum instead of
>> long is really annoying. Still, could you come up with some type that
>> would really benefit from being a value type but that isn't numeric
>> (or otherwise similar)?
>>
>> Thanks for your help!
>>
>> Luís
>
> To add to what others have said - whenever you think you will benefit
> from stack-allocation. Read this article:
> http://www.ibm.com/developerworks/library/j-jtp09275/
> Java is good at escape analysis. But I find it really useful to be able
> to specify a type that will always be allocated on the stack (unless you
> really want it on the heap).

(Not sure I'm not being confused about the topic.) A coworker mentioned they have big problems in Java whenever they need to return more than one thing from one function.

Reference types don't compose nicely that way. In a language with valye types, the juxtaposition of two items (value or reference) is a va;ue. In Java, it's a reference (so you need to allocate a new object etc.)


Andrei

java.lang.String

It is big problem in java. You have pointer to String object with fields: hashCode and chars array (UTF-16). But every array is object itself. So it is pointer to object again. There is pointer compression option in x64 JVM (it uses 32 bits per pointer), but in any way it is too many indirection and additional overhead for object headers.

FYI
It is possible that Java 9 will have value types (google: IBM Java PackedObjects)

On Thu, 2015-05-07 at 07:36 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]
> 
> Reference types don't compose nicely that way. In a language with valye types, the juxtaposition of two items (value or reference) is a va;ue. In Java, it's a reference (so you need to allocate a new object etc.)

But that object is likely very short lived, and (especially with the G1 GC), handled very efficiently. But as ever, without benchmarks and actual data there are no facts, only opinions.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder