View mode: basic / threaded / horizontal-split · Log in · Help
February 06, 2008
x.sizeof vs typeid(x)
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
Re: x.sizeof vs typeid(x)
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
Re: x.sizeof vs typeid(x)
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
Re: x.sizeof vs typeid(x)
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
Re: x.sizeof vs typeid(x)
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
Re: x.sizeof vs typeid(x)
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
Re: x.sizeof vs typeid(x)
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
Re: x.sizeof vs typeid(x)
> 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
Re: x.sizeof vs typeid(x)
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
Re: x.sizeof vs typeid(x)
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
Top | Discussion index | About this forum | D home