Thread overview | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sergey Gromov | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Janice Caron | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sergey Gromov | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert Fraser | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matti Niemenmaa | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christian Kamm | 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
|
Copyright © 1999-2021 by the D Language Foundation