Here's the test case:

auto e = new shared(Exception)("hi");
writeln(e);

and the error:

std/format.d(1293): Error: function object.Throwable.toString () is not callable using argument types ()

I'm guessing this is because toString() isn't a shared method.  Interestingly, also means that it isn't possible to put a shared class into a Variant, since it provides a toString method.  So I guess it's becoming pretty important to sort out the qualifiers for Object methods.  I'd considered providing both a shared and unshared toString (and others), but then child classes defining only one get compile errors about hiding the method in question.  It doesn't seem reasonable to expect people to supply both, and I don't believe inout works for the hidden "this" parameter, so... ideas?  I don't know that we can provide only a shared version of these methods because they may reference non-shared static data so I'm at a bit of a loss for what to do.

I've been thinking about this and realized that shared shouldn't be applied to any of the methods in Object--only const. That I ran into this at all was the result of a contrivance rather than a realistic scenario. I think Variant will need a fix to handle the toString issue, but that's all.

Sent from my iPhone

On Sep 30, 2010, at 3:50 PM, Sean Kelly <sean at invisibleduck.org> wrote:

> Here's the test case:
> 
> auto e = new shared(Exception)("hi");
> writeln(e);
> 
> and the error:
> 
> std/format.d(1293): Error: function object.Throwable.toString () is not callable using argument types ()
> 
> I'm guessing this is because toString() isn't a shared method.  Interestingly, also means that it isn't possible to put a shared class into a Variant, since it provides a toString method.  So I guess it's becoming pretty important to sort out the qualifiers for Object methods.  I'd considered providing both a shared and unshared toString (and others), but then child classes defining only one get compile errors about hiding the method in question.  It doesn't seem reasonable to expect people to supply both, and I don't believe inout works for the hidden "this" parameter, so... ideas?  I don't know that we can provide only a shared version of these methods because they may reference non-shared static data so I'm at a bit of a loss for what to do.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Yah, same here.

andrei

On 9/30/10 16:50 PDT, Sean Kelly wrote:
> I've been thinking about this and realized that shared shouldn't be applied to any of the methods in Object--only const. That I ran into this at all was the result of a contrivance rather than a realistic scenario. I think Variant will need a fix to handle the toString issue, but that's all.
>
> Sent from my iPhone
>
> On Sep 30, 2010, at 3:50 PM, Sean Kelly<sean at invisibleduck.org>  wrote:
>
>> Here's the test case:
>>
>> auto e = new shared(Exception)("hi");
>> writeln(e);
>>
>> and the error:
>>
>> std/format.d(1293): Error: function object.Throwable.toString () is not callable using argument types ()
>>
>> I'm guessing this is because toString() isn't a shared method.  Interestingly, also means that it isn't possible to put a shared class into a Variant, since it provides a toString method.  So I guess it's becoming pretty important to sort out the qualifiers for Object methods.  I'd considered providing both a shared and unshared toString (and others), but then child classes defining only one get compile errors about hiding the method in question.  It doesn't seem reasonable to expect people to supply both, and I don't believe inout works for the hidden "this" parameter, so... ideas?  I don't know that we can provide only a shared version of these methods because they may reference non-shared static data so I'm at a bit of a loss for what to do.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Would Object be any usable without shared qualifiers? Would you be able to compare two objects if the opEquals method doesn't accept shared parameters?

/Jacob Carlborg

On 1 okt 2010, at 01:50, Sean Kelly wrote:

> I've been thinking about this and realized that shared shouldn't be applied to any of the methods in Object--only const. That I ran into this at all was the result of a contrivance rather than a realistic scenario. I think Variant will need a fix to handle the toString issue, but that's all.
> 
> Sent from my iPhone
> 
> On Sep 30, 2010, at 3:50 PM, Sean Kelly <sean at invisibleduck.org> wrote:
> 
>> Here's the test case:
>> 
>> auto e = new shared(Exception)("hi");
>> writeln(e);
>> 
>> and the error:
>> 
>> std/format.d(1293): Error: function object.Throwable.toString () is not callable using argument types ()
>> 
>> I'm guessing this is because toString() isn't a shared method.  Interestingly, also means that it isn't possible to put a shared class into a Variant, since it provides a toString method.  So I guess it's becoming pretty important to sort out the qualifiers for Object methods.  I'd considered providing both a shared and unshared toString (and others), but then child classes defining only one get compile errors about hiding the method in question.  It doesn't seem reasonable to expect people to supply both, and I don't believe inout works for the hidden "this" parameter, so... ideas?  I don't know that we can provide only a shared version of these methods because they may reference non-shared static data so I'm at a bit of a loss for what to do.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

The object would have to define a shared opEquals.

On Oct 1, 2010, at 1:36 AM, Jacob Carlborg wrote:

> Would Object be any usable without shared qualifiers? Would you be able to compare two objects if the opEquals method doesn't accept shared parameters?
> 
> /Jacob Carlborg
> 
> On 1 okt 2010, at 01:50, Sean Kelly wrote:
> 
>> I've been thinking about this and realized that shared shouldn't be applied to any of the methods in Object--only const. That I ran into this at all was the result of a contrivance rather than a realistic scenario. I think Variant will need a fix to handle the toString issue, but that's all.
>> 
>> Sent from my iPhone
>> 
>> On Sep 30, 2010, at 3:50 PM, Sean Kelly <sean at invisibleduck.org> wrote:
>> 
>>> Here's the test case:
>>> 
>>> auto e = new shared(Exception)("hi");
>>> writeln(e);
>>> 
>>> and the error:
>>> 
>>> std/format.d(1293): Error: function object.Throwable.toString () is not callable using argument types ()
>>> 
>>> I'm guessing this is because toString() isn't a shared method.  Interestingly, also means that it isn't possible to put a shared class into a Variant, since it provides a toString method.  So I guess it's becoming pretty important to sort out the qualifiers for Object methods.  I'd considered providing both a shared and unshared toString (and others), but then child classes defining only one get compile errors about hiding the method in question.  It doesn't seem reasonable to expect people to supply both, and I don't believe inout works for the hidden "this" parameter, so... ideas?  I don't know that we can provide only a shared version of these methods because they may reference non-shared static data so I'm at a bit of a loss for what to do.
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> -- 
> /Jacob Carlborg
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

This is turning out to be rather tricky.  The following produces a compile error:

class C
{
    string toString() { return ""; }
    string toString() shared { return ""; }
}

void main()
{
    auto c = new shared(C);
    c.toString();
}

abc.d(4): Error: function abc.C.toString of type shared string() overrides but is not covariant with object.Object.toString of type string()

If I replace "shared" with "const" however, this works just fine.  I guess for now, the only solution is for Tuple to not attempt to call toString for shared objects, and I suppose have writeln() return a more meaningful compile-time error for shared objects.  The only alternative I can think of is to define a toStringShared() routine, which doesn't seem at all ideal.

On Sep 30, 2010, at 4:50 PM, Sean Kelly wrote:

> I've been thinking about this and realized that shared shouldn't be applied to any of the methods in Object--only const. That I ran into this at all was the result of a contrivance rather than a realistic scenario. I think Variant will need a fix to handle the toString issue, but that's all.
> 
> Sent from my iPhone
> 
> On Sep 30, 2010, at 3:50 PM, Sean Kelly <sean at invisibleduck.org> wrote:
> 
>> Here's the test case:
>> 
>> auto e = new shared(Exception)("hi");
>> writeln(e);
>> 
>> and the error:
>> 
>> std/format.d(1293): Error: function object.Throwable.toString () is not callable using argument types ()
>> 
>> I'm guessing this is because toString() isn't a shared method.  Interestingly, also means that it isn't possible to put a shared class into a Variant, since it provides a toString method.  So I guess it's becoming pretty important to sort out the qualifiers for Object methods.  I'd considered providing both a shared and unshared toString (and others), but then child classes defining only one get compile errors about hiding the method in question.  It doesn't seem reasonable to expect people to supply both, and I don't believe inout works for the hidden "this" parameter, so... ideas?  I don't know that we can provide only a shared version of these methods because they may reference non-shared static data so I'm at a bit of a loss for what to do.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos