www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why not?

reply Uriel <uriel inbox.ru> writes:
Lets consider following code:

class Foo {
   private Foo[] m_SomeData;

   public this(int a, double b, string c) {}

   public Foo append(Foo obj) {
     m_SomeData ~= obj;
     return this;
   }
}

void foo(Foo obj) {}

void main() {
   foo(1, 1.0, "1");

   Foo obj = new Foo();
   obj.append(1, 1.0, "1").append(2, 2.0, "2");
}

Why not to do implicitly cast of these three parameters to new Foo 
object. We know that bar should recieve a Foo object and we have a call 
with parameters which exactly match one of Foo's constructors. It could 
be a nice syntactic sugar though not very hard to implement I think.
Nov 29 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Uriel wrote:
 ...
 
 Why not to do implicitly cast of these three parameters to new Foo
 object. We know that bar should recieve a Foo object and we have a call
 with parameters which exactly match one of Foo's constructors. It could
 be a nice syntactic sugar though not very hard to implement I think.

Why allow it?
 foo(new Foo(1, 1.0, "1"))

isn't much more typing, and makes it explicit what's going on. Consider it from a maintenance perspective: with this addition, you can't actually tell what's being called. Is it that foo function there, or is there another overload somewhere in the imports that takes those arguments? There should be a very good reason for having any form of "magic" syntax.
Nov 29 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 isn't much more typing, and makes it explicit what's going on.  Consider
 it from a maintenance perspective: with this addition, you can't
 actually tell what's being called.  Is it that foo function there, or is
 there another overload somewhere in the imports that takes those
 arguments?  There should be a very good reason for having any form of
 "magic" syntax.

C++ has such conversions, and the trouble happens when there are two many possible conversions. One loses track of what is happening.
Nov 29 2009
parent Uriel <uriel inbox.ru> writes:
Walter Bright wrote:
 Daniel Keep wrote:
 isn't much more typing, and makes it explicit what's going on.  Consider
 it from a maintenance perspective: with this addition, you can't
 actually tell what's being called.  Is it that foo function there, or is
 there another overload somewhere in the imports that takes those
 arguments?  There should be a very good reason for having any form of
 "magic" syntax.

C++ has such conversions, and the trouble happens when there are two many possible conversions. One loses track of what is happening.

Definately, I just hadn't thought about situation where there is many classes with matching contructors. And keeping this behavior only for the case of one possible conversion would just complicate the code. It's all the laziness. :)
Nov 29 2009
prev sibling next sibling parent reply Matti Niemenmaa <see_signature for.real.address> writes:
Uriel wrote:
 class Foo {
   private Foo[] m_SomeData;
 
   public this(int a, double b, string c) {}
 
   public Foo append(Foo obj) {
     m_SomeData ~= obj;
     return this;
   }
 }
 
 void foo(Foo obj) {}
 
 void main() {
   foo(1, 1.0, "1");
 
   Foo obj = new Foo();
   obj.append(1, 1.0, "1").append(2, 2.0, "2");
 }
 
 Why not to do implicitly cast of these three parameters to new Foo 
 object. We know that bar should recieve a Foo object and we have a call 
 with parameters which exactly match one of Foo's constructors. It could 
 be a nice syntactic sugar though not very hard to implement I think.

This feature already exists, you just need to declare append and foo a bit differently: public Foo append(Foo obj...) {} void foo(Foo obj...) {}
Nov 29 2009
next sibling parent Uriel <uriel inbox.ru> writes:
Matti Niemenmaa wrote:
 Uriel wrote:
 class Foo {
   private Foo[] m_SomeData;

   public this(int a, double b, string c) {}

   public Foo append(Foo obj) {
     m_SomeData ~= obj;
     return this;
   }
 }

 void foo(Foo obj) {}

 void main() {
   foo(1, 1.0, "1");

   Foo obj = new Foo();
   obj.append(1, 1.0, "1").append(2, 2.0, "2");
 }

 Why not to do implicitly cast of these three parameters to new Foo 
 object. We know that bar should recieve a Foo object and we have a 
 call with parameters which exactly match one of Foo's constructors. It 
 could be a nice syntactic sugar though not very hard to implement I 
 think.

This feature already exists, you just need to declare append and foo a bit differently: public Foo append(Foo obj...) {} void foo(Foo obj...) {}

Hm, very interesting, thanks. Anyway this will work only if the source code is available. But in general I'd agree that may be this isn't worth possible troubles in the future. It was just an idea. :)
Nov 29 2009
prev sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 11/29/2009 03:45 AM, Matti Niemenmaa wrote:
 This feature already exists, you just need to declare append and foo a
 bit differently:

 public Foo append(Foo obj...) {}
 void foo(Foo obj...) {}

You're supposed to assume that obj is allocated on the stack, though, which requires you to make a copy of it if you want to use it later, which obviates the point of the syntax. I haven't found this feature to be useful.
Nov 29 2009
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Uriel (uriel inbox.ru)'s article
 Lets consider following code:
 class Foo {
    private Foo[] m_SomeData;
    public this(int a, double b, string c) {}
    public Foo append(Foo obj) {
      m_SomeData ~= obj;
      return this;
    }
 }
 void foo(Foo obj) {}
 void main() {
    foo(1, 1.0, "1");
    Foo obj = new Foo();
    obj.append(1, 1.0, "1").append(2, 2.0, "2");
 }
 Why not to do implicitly cast of these three parameters to new Foo
 object. We know that bar should recieve a Foo object and we have a call
 with parameters which exactly match one of Foo's constructors. It could
 be a nice syntactic sugar though not very hard to implement I think.

It's gratuitous complexity. Anytime you add complexity to the language, it should have to remove enough complexity from user code to justify the complication of the language. IMHO the amount of complexity added to the language here would be orders of magnitude less than the amount removed from user code.
Nov 29 2009