I'm wondering because I'm making a Deferred class for a D copy of Twisted, and central to it is users supplying delegates that take variadic arguments and return a variadic value and I need to save the variadic arguments for later to combine with an additional variadic value and pass this all to another user-delegate, so I'm using Box[] and Box.

But you can't have null-Box-references as a way of indicating null since it's a
struct (and I don't want struct pointers).  box(null) and
unboxable!(typeof(null))(mybox) work, but aren't as convenient.  And you have to
explicitly call Box.toString() for std.format because Box isn't an Object.  I
could easily make my own class wrapping a Box but I wanted to leverage the
standardized-ness of Box, but with Box as a struct users have to do box(null)
and unboxable!(typeof(null))(mybox) everytime to return and test for null.

I imagine it would be to avoid a call to new/malloc. Structs can simply be allocated on the stack, whereas classes can't. If you need long term persistence for Box, then one could wrap it as you suggested (or uses pointers).

- Kris

<derick_eddington@nospam.yashmoo.com> wrote in message news:d7oc8j$2m2j$1@digitaldaemon.com...
> I'm wondering because I'm making a Deferred class for a D copy of Twisted,
and
> central to it is users supplying delegates that take variadic arguments
and
> return a variadic value and I need to save the variadic arguments for
later to
> combine with an additional variadic value and pass this all to another user-delegate, so I'm using Box[] and Box.
>
> But you can't have null-Box-references as a way of indicating null since
it's a
> struct (and I don't want struct pointers).  box(null) and
> unboxable!(typeof(null))(mybox) work, but aren't as convenient.  And you
have to
> explicitly call Box.toString() for std.format because Box isn't an Object.
I
> could easily make my own class wrapping a Box but I wanted to leverage the standardized-ness of Box, but with Box as a struct users have to do
box(null)
> and unboxable!(typeof(null))(mybox) everytime to return and test for null.
>
>
>

Is the inout attribute applicable in this case?  (As a way of avoiding explicit pointers.)

-- Chris Sauls

Kris wrote:
> I imagine it would be to avoid a call to new/malloc. Structs can simply be
> allocated on the stack, whereas classes can't. If you need long term
> persistence for Box, then one could wrap it as you suggested (or uses
> pointers).
> 
> - Kris
> 
> <derick_eddington@nospam.yashmoo.com> wrote in message
> news:d7oc8j$2m2j$1@digitaldaemon.com...
> 
>>I'm wondering because I'm making a Deferred class for a D copy of Twisted,
> 
> and
> 
>>central to it is users supplying delegates that take variadic arguments
> 
> and
> 
>>return a variadic value and I need to save the variadic arguments for
> 
> later to
> 
>>combine with an additional variadic value and pass this all to another
>>user-delegate, so I'm using Box[] and Box.
>>
>>But you can't have null-Box-references as a way of indicating null since
> 
> it's a
> 
>>struct (and I don't want struct pointers).  box(null) and
>>unboxable!(typeof(null))(mybox) work, but aren't as convenient.  And you
> 
> have to
> 
>>explicitly call Box.toString() for std.format because Box isn't an Object.
> 
> I
> 
>>could easily make my own class wrapping a Box but I wanted to leverage the
>>standardized-ness of Box, but with Box as a struct users have to do
> 
> box(null)
> 
>>and unboxable!(typeof(null))(mybox) everytime to return and test for null.
>>
>>
>>
> 
> 
> 

That's what I thought, but wasn't sure because boxArray() or manually-made Box[]s, both of which I'm assuming will be used as much if not more than single Box's, have to 'new Box[]', so it's having to new the Box's anyways.

And I realized unboxable!(typeof(null))(mybox) won't work for what I'm doing
because the implicit casting allows all kinds of types to pass the predicate.

So if anyone cares, I've made a simple Var class wrapper around std.boxer and it's a little more class-like and it will allow using it as variadic arguments that want to be tested for being null.  It's attached.

In article <d7odpm$2n9d$1@digitaldaemon.com>, Kris says...
>
>I imagine it would be to avoid a call to new/malloc. Structs can simply be allocated on the stack, whereas classes can't. If you need long term persistence for Box, then one could wrap it as you suggested (or uses pointers).
>
>- Kris
>
><derick_eddington@nospam.yashmoo.com> wrote in message news:d7oc8j$2m2j$1@digitaldaemon.com...
>> I'm wondering because I'm making a Deferred class for a D copy of Twisted,
>and
>> central to it is users supplying delegates that take variadic arguments
>and
>> return a variadic value and I need to save the variadic arguments for
>later to
>> combine with an additional variadic value and pass this all to another user-delegate, so I'm using Box[] and Box.
>>
>> But you can't have null-Box-references as a way of indicating null since
>it's a
>> struct (and I don't want struct pointers).  box(null) and
>> unboxable!(typeof(null))(mybox) work, but aren't as convenient.  And you
>have to
>> explicitly call Box.toString() for std.format because Box isn't an Object.
>I
>> could easily make my own class wrapping a Box but I wanted to leverage the standardized-ness of Box, but with Box as a struct users have to do
>box(null)
>> and unboxable!(typeof(null))(mybox) everytime to return and test for null.
>>
>>
>>
>
>

<derick_eddington@nospam.yashmoo.com> wrote in message news:d7oc8j$2m2j$1@digitaldaemon.com...
> I'm wondering because I'm making a Deferred class for a D copy of Twisted,
> and
> central to it is users supplying delegates that take variadic arguments
> and
> return a variadic value and I need to save the variadic arguments for
> later to
> combine with an additional variadic value and pass this all to another
> user-delegate, so I'm using Box[] and Box.
>
> But you can't have null-Box-references as a way of indicating null since
> it's a
> struct (and I don't want struct pointers).  box(null) and
> unboxable!(typeof(null))(mybox) work, but aren't as convenient.  And you
> have to
> explicitly call Box.toString() for std.format because Box isn't an Object.
> I
> could easily make my own class wrapping a Box but I wanted to leverage the
> standardized-ness of Box, but with Box as a struct users have to do
> box(null)
> and unboxable!(typeof(null))(mybox) everytime to return and test for null.

here's a little helper:
class BoxObject {
  Box b;
  this(...) { this.b = box(_arguments[0],_argptr); }
  char[] toString() { return b.toString(); }
  uint toHash() { return b.toHash(); }
  int opEquals(Object o) {
    BoxObject bo = cast(BoxObject)o;
    if (!bo)
      return 0;
    return b == bo.b;
  }
  int opCmp(Object o) {
    BoxObject bo = cast(BoxObject)o;
    if (!bo)
      throw Exception("must compare a BoxObject with a BoxObject");
    return b.opCmp(bo.b);
  }
}

Of course I forgot to add .toString() and the operators Box supports; but after adding them by just calling the wrapped Box's methods, my Var is not working as an A.A. key but Box does works.  I.E.:

// works
assert (var(456) < var(567));
assert (var(787) == var(787));
assert (var("zzz") > var("xxx"));
assert (var("qwerty") == var("qwerty"));

// Box works
char[][Box] cbaa;
cbaa[box(45.234)] = "45.234";
Object o = new Object;
cbaa[box(o)] = "Object";
assert (cbaa[box(45.234)] == "45.234");
assert (cbaa[box(o)] == "Object");

// does NOT work
// but Var just wraps Box's operators
char[][Var] cvaa;
cvaa[var(45.234)] = "45.234";
o = new Object;
cvaa[var(o)] = "Object";
assert (cvaa[var(45.234)] == "45.234");
assert (cvaa[var(o)] == "Object");

I don't need these operators currently, but I'd like to have them work like Box. Does anyone know why Var just wrapping its Box's methods is not working?


In article <d7olfs$2se0$1@digitaldaemon.com>, derick_eddington@nospam.yashmoo.com says...
>
>That's what I thought, but wasn't sure because boxArray() or manually-made Box[]s, both of which I'm assuming will be used as much if not more than single Box's, have to 'new Box[]', so it's having to new the Box's anyways.
>
>And I realized unboxable!(typeof(null))(mybox) won't work for what I'm doing
>because the implicit casting allows all kinds of types to pass the predicate.
>
>So if anyone cares, I've made a simple Var class wrapper around std.boxer and it's a little more class-like and it will allow using it as variadic arguments that want to be tested for being null.  It's attached.
>
>In article <d7odpm$2n9d$1@digitaldaemon.com>, Kris says...
>>
>>I imagine it would be to avoid a call to new/malloc. Structs can simply be allocated on the stack, whereas classes can't. If you need long term persistence for Box, then one could wrap it as you suggested (or uses pointers).
>>
>>- Kris
>>

I guess I've answered my own question.  Apparently, unlike structs, Objects have
to have 'int opCmp(Object)' and not 'int opCmp(MySubclass)' even when only
comparing with other MySubclass's.

In article <d7onpm$2u3k$1@digitaldaemon.com>, derick_eddington@nospam.yashmoo.com says...
>
>Of course I forgot to add .toString() and the operators Box supports; but after adding them by just calling the wrapped Box's methods, my Var is not working as an A.A. key but Box does works.  I.E.:
>
>// works
>assert (var(456) < var(567));
>assert (var(787) == var(787));
>assert (var("zzz") > var("xxx"));
>assert (var("qwerty") == var("qwerty"));
>
>// Box works
>char[][Box] cbaa;
>cbaa[box(45.234)] = "45.234";
>Object o = new Object;
>cbaa[box(o)] = "Object";
>assert (cbaa[box(45.234)] == "45.234");
>assert (cbaa[box(o)] == "Object");
>
>// does NOT work
>// but Var just wraps Box's operators
>char[][Var] cvaa;
>cvaa[var(45.234)] = "45.234";
>o = new Object;
>cvaa[var(o)] = "Object";
>assert (cvaa[var(45.234)] == "45.234");
>assert (cvaa[var(o)] == "Object");
>
>I don't need these operators currently, but I'd like to have them work like Box. Does anyone know why Var just wrapping its Box's methods is not working?
>
>

Thanks.  JSYK, Box has 'float opCmp(Box)' so you have to cast(int).

In article <d7onls$2u1j$1@digitaldaemon.com>, Ben Hinkle says...
>here's a little helper:
>class BoxObject {
>  Box b;
>  this(...) { this.b = box(_arguments[0],_argptr); }
>  char[] toString() { return b.toString(); }
>  uint toHash() { return b.toHash(); }
>  int opEquals(Object o) {
>    BoxObject bo = cast(BoxObject)o;
>    if (!bo)
>      return 0;
>    return b == bo.b;
>  }
>  int opCmp(Object o) {
>    BoxObject bo = cast(BoxObject)o;
>    if (!bo)
>      throw Exception("must compare a BoxObject with a BoxObject");
>    return b.opCmp(bo.b);
>  }
>}
>
>

<derick_eddington@nospam.yashmoo.com> wrote in message news:d7oc8j$2m2j$1@digitaldaemon.com...
> I'm wondering because I'm making a Deferred class for a D copy of Twisted,
> and
> central to it is users supplying delegates that take variadic arguments
> and
> return a variadic value and I need to save the variadic arguments for
> later to
> combine with an additional variadic value and pass this all to another
> user-delegate, so I'm using Box[] and Box.
>
> But you can't have null-Box-references as a way of indicating null since
> it's a
> struct (and I don't want struct pointers).  box(null) and
> unboxable!(typeof(null))(mybox) work, but aren't as convenient.  And you
> have to
> explicitly call Box.toString() for std.format because Box isn't an Object.
> I
> could easily make my own class wrapping a Box but I wanted to leverage the
> standardized-ness of Box, but with Box as a struct users have to do
> box(null)
> and unboxable!(typeof(null))(mybox) everytime to return and test for null.
>
>
>

>But you can't have null-Box-references as a way of indicating null since it's a

Just wondering: why you cannot use just empty box?

Box b;
assert(b.toString == "<empty box>");

>>But you can't have null-Box-references as a way of indicating null since it's a
>
> Just wondering: why you cannot use just empty box?
>
> Box b;
> assert(b.toString == "<empty box>");

or
 assert( b is Box.init );