View mode: basic / threaded / horizontal-split · Log in · Help
August 24, 2006
Re: Suggestion: shortcut for 'new X'
Kristian wrote:
> On Thu, 24 Aug 2006 21:17:23 +0300, BCS <BCS@pathlink.com> wrote:
> 
>> Kristian wrote:
>>>  However, I don't think that it's good programming style to use auto 
>>> a  lot. :/
>>>
>>
>> substitute excessive for a lot and I agree.
>>
>>> Consider the following:
>>>  Obj func2() {...}
>>>  void func() {
>>>     auto obj = func2();
>>> }
>>>  When looking at 'func()' only it's impossible to know the type of 
>>> 'obj'.
>>
>> that can be a bit of a gotcha. I haven't done it but putting in a
>>
>> static assert(is(obj : Obj));
>>
>> could serve as a bit of type documentation and as a guard against API 
>> changes.
> 
> That's too hackish to my taste, and who have energy to write such long 
> statements for simple variable declarations? ;)
> 
> Better have a simple, clear way to declare a variable, haven't it?
> 
> "Obj obj = new;" is short, non-redundant, and it tells everybody that 
> 'obj' is of type 'Obj'.

Well true, but
auto obj = new Obj();

is not much longer, also isn't redundant and it also tells everyone what 
type 'obj' is.
August 24, 2006
Re: Suggestion: shortcut for 'new X'
On Thu, 24 Aug 2006 23:30:25 +0300, Ivan Senji  
<ivan.senji_REMOVE_@_THIS__gmail.com> wrote:

> Kristian wrote:
>> On Thu, 24 Aug 2006 21:17:23 +0300, BCS <BCS@pathlink.com> wrote:
>>
>>> Kristian wrote:
>>>>  However, I don't think that it's good programming style to use auto  
>>>> a  lot. :/
>>>>
>>>
>>> substitute excessive for a lot and I agree.
>>>
>>>> Consider the following:
>>>>  Obj func2() {...}
>>>>  void func() {
>>>>     auto obj = func2();
>>>> }
>>>>  When looking at 'func()' only it's impossible to know the type of  
>>>> 'obj'.
>>>
>>> that can be a bit of a gotcha. I haven't done it but putting in a
>>>
>>> static assert(is(obj : Obj));
>>>
>>> could serve as a bit of type documentation and as a guard against API  
>>> changes.
>>  That's too hackish to my taste, and who have energy to write such long  
>> statements for simple variable declarations? ;)
>>  Better have a simple, clear way to declare a variable, haven't it?
>>  "Obj obj = new;" is short, non-redundant, and it tells everybody that  
>> 'obj' is of type 'Obj'.
>
> Well true, but
> auto obj = new Obj();
>
> is not much longer, also isn't redundant and it also tells everyone what  
> type 'obj' is.


That's right, but it raises a matter of (in)consistence in some cases as I  
wrote in my earlier post:

>
> However, I don't think that it's not good programming style to use auto  
> a lot. :/
>
> Consider the following:
>
> Obj func2() {...}
>
> void func() {
>      auto obj = func2();
> }
>
> When looking at 'func()' only it's impossible to know the type of 'obj'.
>
> Of course I could write "auto Obj obj" or "Obj obj", but it's  
> inconsistent with 'anonymous autos':
>
> void func() {
>      auto Obj obj1 = func();
>      auto obj2 = new Obj;
> }
>
> I would really prefer the following:
>
> void func() {
>      Obj obj1 = func();
>      Obj obj2 = new;
>      Obj obj3;
> }
>
> Or:
>
> void func() {
>      auto Obj obj1 = func();
>      auto Obj obj2 = new;
>      auto Obj obj3;
> }
>
> (Note the usage of the shortcut of 'new'.)
August 24, 2006
Re: Suggestion: shortcut for 'new X'
Chris Nicholson-Sauls wrote:
> Kristian wrote:
>> How about this:
>>
>>     Obj obj1 = new Obj;
>>     Obj obj2 = new Obj(10);
>>
>> could be reduced to:
>>
>>     Obj obj1 = new;
>>     Obj obj2 = new(10);
>>
>> This way only one class name would be required per variable. (That is, 
>> one  at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid of 
>> course.)  Redundance would be reduced.
>>
>> I know, it looked quite 'odd' for me too at first, but now it looks 
>> very  natural, and even clearer than the longer way.
>>
>>
>> I'm not sure if using of this syntax should be possible outside the  
>> variable declarations. Later in a code "obj1 = new;" is less 
>> informative  than "obj1 = new Obj;". However, someone may like it 
>> too... it's up to a  programmer how to code (which is not always a 
>> good thing(tm) though).
> 
> Would this pose any ambiguities with custom class allocators?

I was wondering the same thing, but I think it could be resolved via 
look-ahead.  That said, I'm not sure I like the syntax as it seems a bit 
confusing.  Is it really so hard to specify the type name?


Sean
August 25, 2006
Re: Suggestion: shortcut for 'new X'
On Fri, 25 Aug 2006 00:01:46 +0300, Sean Kelly <sean@f4.ca> wrote:
> Chris Nicholson-Sauls wrote:
>> Kristian wrote:
>>> How about this:
>>>
>>>     Obj obj1 = new Obj;
>>>     Obj obj2 = new Obj(10);
>>>
>>> could be reduced to:
>>>
>>>     Obj obj1 = new;
>>>     Obj obj2 = new(10);
>>>
>>> This way only one class name would be required per variable. (That is,  
>>> one  at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid of  
>>> course.)  Redundance would be reduced.
>>>
>>> I know, it looked quite 'odd' for me too at first, but now it looks  
>>> very  natural, and even clearer than the longer way.
>>>
>>>
>>> I'm not sure if using of this syntax should be possible outside the   
>>> variable declarations. Later in a code "obj1 = new;" is less  
>>> informative  than "obj1 = new Obj;". However, someone may like it  
>>> too... it's up to a  programmer how to code (which is not always a  
>>> good thing(tm) though).
>>  Would this pose any ambiguities with custom class allocators?
>
> I was wondering the same thing, but I think it could be resolved via  
> look-ahead.  That said, I'm not sure I like the syntax as it seems a bit  
> confusing.  Is it really so hard to specify the type name?

Never underestimate the power of the dark laziness! But seriously... One  
could also ask why 'this' is used in constructors/destructors instead of  
the class name. I was very pleased to find out that D does that.

In Qt, for instance, you normally use pointers to objects. So, every time  
I wrote "X ... X" (e.g. "QCanvasPolygonalItem *item = new  
QCanvasPolygonalItem;") I was thinking that there must be a better way to  
do that.


I started to use a new, bigger monitor a while ago. There was a negative  
side to it, however, paying money. And I thought I don't need it, not  
really, the old one has served me fine in the past... Well, now I wouldn't  
switch back to the old one.
August 25, 2006
Re: Suggestion: shortcut for 'new X'
>> Kristian wrote:
>> Consider the following:
>>
>> Obj func2() {...}
>>
>> void func() {
>>      auto obj = func2();
>> }

For such cases, there is the typeof() operator :

Obj func2 () { ... }

void func ()
{	typeof ( func2 ) obj = func2 ();
}

And one knows exactly that obj's type is the same as func2 return type, 
and there is no mistake possible with an auto type, althought it becomes
redundant.
It does not matter that much in a dynamically typed language :

def func2 (): return Something ()

def func ():
    obj = func2 ()

It seems that there will always be some redundancy in a typed language à 
la C, nonetheless D has made great improvement.
August 25, 2006
Re: Suggestion: shortcut for 'new X'
Rémy J. A. Mouëza wrote:
> 
>>> Kristian wrote:
>>> Consider the following:
>>>
>>> Obj func2() {...}
>>>
>>> void func() {
>>>      auto obj = func2();
>>> }
> 
> For such cases, there is the typeof() operator :
> 
> Obj func2 () { ... }
> 
> void func ()
> {    typeof ( func2 ) obj = func2 ();
> }

Why that when this works:

void func() {
     auto obj = func2();
}

What I think Kristian was saying is that you cannot see the type from 
the above, but you can know the type if it is:

Obj obj1 = func2();
Obj obj1 = new;

While it does make sense, I don't think that "auto obj = func2();" is a 
big problem and prefer auto.
August 25, 2006
Re: Suggestion: shortcut for 'new X'
On Fri, 25 Aug 2006 11:38:18 +0300, Rémy J. A. Mouëza  
<ray.jay.ay.moueza@do.not.spam.gmail.com> wrote:

>
>>> Kristian wrote:
>>> Consider the following:
>>>
>>> Obj func2() {...}
>>>
>>> void func() {
>>>      auto obj = func2();
>>> }
>
> For such cases, there is the typeof() operator :
>
> Obj func2 () { ... }
>
> void func ()
> {	typeof ( func2 ) obj = func2 ();
> }
>
> And one knows exactly that obj's type is the same as func2 return type,  
> and there is no mistake possible with an auto type, althought it becomes
> redundant.
> It does not matter that much in a dynamically typed language :
>
> def func2 (): return Something ()
>
> def func ():
>      obj = func2 ()
>
> It seems that there will always be some redundancy in a typed language à  
> la C, nonetheless D has made great improvement.

Well yes, but you missed my point though.

void func() {
    auto obj1 = func2();
    typeof(func2) obj2 = func2();
}

You (or someone reading the code, lets say, a year later) know that the  
type of both 'obj1' and 'obj2' are the same as the type of 'func2()'. But  
you don't know the type of 'func2()' without looking at the definion of  
'func2()' or at the docs.

Someone may argue that declaring 'Obj' in "auto obj1 = func2();" is  
redundant because 'func2()' returns 'Obj'. But that information is not  
apparent to you when you look at 'func()'. So it's not redundant code  
inside 'func()'. If you like to use 'obj1', then you have to know its  
type, of course. It's good programming style to declare the type for  
'obj1' or you may end up with code that nobody knows the types of objects  
without looking at the documention/function declarations all the time. It  
would be very painful to modify the code later, even if you do it by  
yourself.
August 25, 2006
Re: Suggestion: shortcut for 'new X'
Kristian a écrit :
> On Fri, 25 Aug 2006 11:38:18 +0300, Rémy J. A. Mouëza 
> <ray.jay.ay.moueza@do.not.spam.gmail.com> wrote:
> 
>>
>>>> Kristian wrote:
>>>> Consider the following:
>>>>
>>>> Obj func2() {...}
>>>>
>>>> void func() {
>>>>      auto obj = func2();
>>>> }
>>
>> For such cases, there is the typeof() operator :
>>
>> Obj func2 () { ... }
>>
>> void func ()
>> {    typeof ( func2 ) obj = func2 ();
>> }
>>
>> And one knows exactly that obj's type is the same as func2 return 
>> type, and there is no mistake possible with an auto type, althought it 
>> becomes
>> redundant.
>> It does not matter that much in a dynamically typed language :
>>
>> def func2 (): return Something ()
>>
>> def func ():
>>      obj = func2 ()
>>
>> It seems that there will always be some redundancy in a typed language 
>> à la C, nonetheless D has made great improvement.
> 
> Well yes, but you missed my point though.
> 
> void func() {
>     auto obj1 = func2();
>     typeof(func2) obj2 = func2();
> }
> 
> You (or someone reading the code, lets say, a year later) know that the 
> type of both 'obj1' and 'obj2' are the same as the type of 'func2()'. 
> But you don't know the type of 'func2()' without looking at the definion 
> of 'func2()' or at the docs.
> 
> Someone may argue that declaring 'Obj' in "auto obj1 = func2();" is 
> redundant because 'func2()' returns 'Obj'. But that information is not 
> apparent to you when you look at 'func()'. So it's not redundant code 
> inside 'func()'. If you like to use 'obj1', then you have to know its 
> type, of course. It's good programming style to declare the type for 
> 'obj1' or you may end up with code that nobody knows the types of 
> objects without looking at the documention/function declarations all the 
> time. It would be very painful to modify the code later, even if you do 
> it by yourself.

Thus it has nothing to do with syntax : it's more about documenting 
one's code. I completely missed your point, indeed. My apologizes.
I sometimes code that way :

void aMethod ( Something aThing )
{	Something a = this.processIt ( this.thing );
	auto b = processIt ( aThing );
	...
}
The first line of the method is a kind of reminder to tell the reader 
about the types and the methods used. In the remaining lines, I use the 
possible shortcuts. It's a matter of discipline ( or good programming 
style ). We, programmers, too often speak about code : source code looks 
more like some kind of software text/litterature than cryptic and secret 
code that only few people can understand.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home