std.boxer vs Any

[Aarti_pl]

Bill Baxter pisze:
  > What's the difference between std.boxer and doost.core.Any?
> 
> Seems like they do basically the same thing.  Only big difference seems 
> to be that boxer is a struct, while Any is a class.
> 
> Boxer looks to be smarter about conversions (unbox!(uint) in the above 
> example looks like it would probably work.)
> 
> But boxer uses void[] storage, meaning it's not a good idea to use boxer 
> for floating point values or random hash-like integer values (will lead 
> to gc leaks).
> 
> Anyway, I suppose you had your reasons for writing Any rather than just 
> going with what's in the library... what were they?
> 
> 
> And part B) of my question is -- maybe you could borrow some of the 
> unboxing logic from boxer to make Any.as!(type) more flexible.  To me, 
> 'as' sounds like it's going to be a flexible conversion.  Maybe the 
> current behavior could be renamed to Any.get!(type) or Any.value!(type).
> 
> --bb

Boxer:

Main reason to port also 'Any' from Boost was that Box just doesn't work 
under linux, when I did conversion of Program Options (one of asserts 
was failing, as I remember). What's more Boxer has very unclear semantic 
for getting information if it is empty. It is necessary to ask if type 
of contained value is null. It's also not possible to clear contained 
value. But if Box was working under Linux that time I would probably use it.

----

Any:

Any is implemented as class. I did few tests of speed for Box / Any. Box 
is much faster than Any (about x10 as I remember). So it is big drawback 
of Any. I did not put much of time into making it very good after that 
tests ;-) As an argument for Any, I would say that it is very simple and 
clean.

----

Tango Variant:

Implementation looks very nice, but I thing it is not perfect currently 
(perfect in a sense that I will buy it right now for my project :D). 
Saying that I know that 'Any' has also few of below limitations...

1. It looks that opAssign is not very well suited for containers of this 
type. The problem is that it disallows to put Variant into Variant (what 
is sometimes very useful), as operator will not start work at all, but 
just pointers to/values of containers will be replaced. Because of that 
it is necessary to have free function, static opCall or use (ugly) 
opAssign() function explicitly to achieve desired effect.

Below simple testcase:

import std.stdio;
import std.boxer;
import variant; // I hacked Tango version a little bit
		// to work with Phobos

void main() {
     Box a = box(4);
     Box b = box(a);
     writefln(b.type);     //result: std.boxer.Box - OK!

     Variant x = 4;
     Variant y = x;
     writefln(y.type);    //result: int - WRONG!
     y.opAssign(x);

     writefln(y.type);    //result: variant.Variant - OK!
     writefln(y.get!(Variant).type);
}

I am not sure if it wouldn't be better to not use opAssign at all, and 
use only e.g. static opCall. This way you could avoid unpleasant 
surprises...

For reference: http://dsource.org/projects/tango/forums/topic/12

2. There is no isEmpty() function (same problem as in Box). I think that 
clear() would be nice also, but maybe not so useful.

3. Automatic conversion of arguments to variadic argument functions into 
Variant is not possible (Boxer has it.)

4. toUtf8 doesn't work in Tango.

------

'B' part of your question:
Yes, it is possible that I change .as() to something else (get!()?). But 
I am thinking also about dropping Any in favor of Box or Variant.

Variant would be my choose if only it fix reasonably above mentioned 
problems.

Best Regards
Marcin Kuszczak
(aarti_pl - www.zapytajmnie.com)