Jump to page: 1 24  
Page
Thread overview
x.sizeof vs typeid(x)
Feb 06, 2008
Sergey Gromov
Feb 06, 2008
Janice Caron
Feb 06, 2008
Sergey Gromov
Feb 06, 2008
bearophile
Feb 06, 2008
Matti Niemenmaa
Feb 06, 2008
bearophile
Feb 07, 2008
Matti Niemenmaa
Feb 06, 2008
Robert Fraser
Feb 06, 2008
Matti Niemenmaa
Feb 06, 2008
Robert Fraser
Feb 06, 2008
torhu
Feb 06, 2008
Christian Kamm
Feb 06, 2008
Sergey Gromov
Feb 06, 2008
Sergey Gromov
Feb 06, 2008
Robert Fraser
Feb 06, 2008
bearophile
Feb 06, 2008
Sergey Gromov
Feb 07, 2008
downs
Feb 07, 2008
Tom S
Feb 07, 2008
Sergey Gromov
Feb 07, 2008
Tom S
Feb 07, 2008
Sergey Gromov
Feb 08, 2008
Tom S
Feb 08, 2008
Sergey Gromov
Feb 08, 2008
Anders Bergh
Feb 08, 2008
Sergey Gromov
Feb 08, 2008
Alexander Panek
Feb 08, 2008
Sergey Gromov
Feb 08, 2008
Alexander Panek
Feb 08, 2008
Tom S
Feb 08, 2008
bearophile
Feb 08, 2008
Tom S
Feb 08, 2008
bearophile
Feb 07, 2008
Walter Bright
Feb 07, 2008
Robert Fraser
Feb 07, 2008
Walter Bright
Feb 07, 2008
Christopher Wright
Feb 08, 2008
Walter Bright
Feb 08, 2008
Christopher Wright
Feb 07, 2008
Moritz Warning
February 06, 2008
I wonder why .sizeof is implemented as a property while typeof() and
typeid() are functions.  I can see no reasons for such inconsistency.
It's not that obvious for typeof() because it yields a type instead
of a value, but even then, why not ?
February 06, 2008
I believe there are plans afoot to remove the distinction, so that f(x) and x.f are, in general, interchangable. If and when that day comes, perhaps we'll be able to write sizeof(x) and x.typeid as well?

On 06/02/2008, Sergey Gromov <snake.scaly@gmail.com> wrote:
> I wonder why .sizeof is implemented as a property while typeof() and
> typeid() are functions.  I can see no reasons for such inconsistency.
> It's not that obvious for typeof() because it yields a type instead
> of a value, but even then, why not ?
>
February 06, 2008
Are you sure this is to the better ?  I'm not quite fond of D's freedom in syntax.  It already allows to write an unreadable code like this:

use(context) in (GL gl) {draw(gl);}

auto GetEven = stackthread = (int delegate() read, void delegate(int) yield) {...}

Less typing is often => less maintainable.  And Perl's slogan, "there is
more than one way to do things," is exactly what makes Perl
a write-only language.

SnakE

Janice Caron Wrote:
> I believe there are plans afoot to remove the distinction, so that f(x) and x.f are, in general, interchangable. If and when that day comes, perhaps we'll be able to write sizeof(x) and x.typeid as well?
> 
> On 06/02/2008, Sergey Gromov <snake.scaly@gmail.com> wrote:
> > I wonder why .sizeof is implemented as a property while typeof() and
> > typeid() are functions.  I can see no reasons for such inconsistency.
> > It's not that obvious for typeof() because it yields a type instead
> > of a value, but even then, why not ?
> >

February 06, 2008
Sergey Gromov:
> Less typing is often => less maintainable.

But that may be false if you take lot of care of keeping the language tidy, quite ergonomic. Python is quite maintainable, and it's far from being verbose. Haskell too is readable enough, if you know it, despite its programs being quite short.

In this regard, one of the things I don't like of D syntax is that it allows to call functions without the final () if they take no arguments. It may be useful for properties, but when you see something like:

foo = bar;

Is it a function call?
I am learning to always put the () there to be explicit:

foo = bar();

To improve code readability I think it may be better to remove this feature from the language (and later that may be used to simplify the object instantiation syntax).

Bye,
bearophile
February 06, 2008
bearophile wrote:
> In this regard, one of the things I don't like of D syntax is that it allows
> to call functions without the final () if they take no arguments. It may be
> useful for properties, but when you see something like:
> 
> foo = bar;
> 
> Is it a function call? I am learning to always put the () there to be
> explicit:
> 
> foo = bar();
> 
> To improve code readability I think it may be better to remove this feature
> from the language (and later that may be used to simplify the object
> instantiation syntax).

The point is that it shouldn't matter. If you want to change it later to a function, you have to change all the points where you use it as well.

Canonical example with classes:

class Vector { Point a, b; double distance; this(...) {...} }

Now, if you want to save memory by changing distance to a method instead:

class Vector { Point a, b; this(...) {...} double distance() {...} }

You would have to change all uses of distance, whether inside or outside the class, to be distance() instead of distance.

Except that D does give us the ability to always use just distance and not care about whether it's a function or not.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
February 06, 2008
bearophile wrote:
> Sergey Gromov:
>> Less typing is often => less maintainable.
> 
> But that may be false if you take lot of care of keeping the language tidy, quite ergonomic. Python is quite maintainable, and it's far from being verbose. Haskell too is readable enough, if you know it, despite its programs being quite short.
> 
> In this regard, one of the things I don't like of D syntax is that it allows to call functions without the final () if they take no arguments. It may be useful for properties, but when you see something like:
> 
> foo = bar;
> 
> Is it a function call?
> I am learning to always put the () there to be explicit:
> 
> foo = bar();
> 
> To improve code readability I think it may be better to remove this feature from the language (and later that may be used to simplify the object instantiation syntax).
> 
> Bye,
> bearophile

I agree with you on that particular syntax. I think when it's a member of some sort, that syntax should be allowed, though (to allow a property syntax), but for free functions it's a bad idea.
February 06, 2008
Robert Fraser wrote:
> I agree with you on that particular syntax. I think when it's a member of some sort, that syntax should be allowed, though (to allow a property syntax), but for free functions it's a bad idea.

The argument for class properties applies equally well to global variables.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
February 06, 2008
> It may be useful for properties, but when you see something like:
> 
> foo = bar;
> 
> Is it a function call?
> I am learning to always put the () there to be explicit:
> 
> foo = bar();

It really gets odd when foo is a function as well:

void foo(int i);
int bar();

foo = bar; // same as foo(bar());

I think property syntax is nice, but should only be valid where it makes sense (or only where the user explicitly allowed it).

Christian Kamm
February 06, 2008
Matti Niemenmaa:
> You would have to change all uses of distance, whether inside or outside the class, to be distance() instead of distance.
> 
> Except that D does give us the ability to always use just distance and not care about whether it's a function or not.

I was talking about free functions. I think for methods/properties the syntax without () can be kept...

Bye,
bearophile
February 06, 2008
Christian Kamm wrote:
> It really gets odd when foo is a function as well:
> 
> void foo(int i);
> int bar();
> 
> foo = bar; // same as foo(bar());
> 
> I think property syntax is nice, but should only be valid where it makes sense (or only where the user explicitly allowed it).

Agree. If there were, say, an attribute `property', so that you can write:

foo(double x) {...}
property double distance() {return ...}

foo(distance);   // OK
foo(distance()); // OK
foo = distance;  // error

it'd be much safer.

SnakE
« First   ‹ Prev
1 2 3 4