View mode: basic / threaded / horizontal-split · Log in · Help
February 06, 2008
Re: x.sizeof vs typeid(x)
Sergey Gromov <snake.scaly@gmail.com> wrote:
> foo(double x) {...}
> property double distance() {return ...}
> 
> foo(distance);   // OK
> foo(distance()); // OK
> foo = distance;  // error

Or even forbid to use the `double()' syntax for properties, and forbid 
to overload properties with non-property functions.  In other words:

foo(distance()); // error, can't use call syntax for properties
double distance(int precision) {...} // error, can't overload a property
-- 
SnakE
February 06, 2008
Re: x.sizeof vs typeid(x)
Matti Niemenmaa wrote:
> 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.
> 

Oops, forgot about those... alright, well I guess then people just need 
to be careful with this syntax.
February 06, 2008
Re: x.sizeof vs typeid(x)
Sergey Gromov wrote:
> Sergey Gromov <snake.scaly@gmail.com> wrote:
>> foo(double x) {...}
>> property double distance() {return ...}
>>
>> foo(distance);   // OK
>> foo(distance()); // OK
>> foo = distance;  // error
> 
> Or even forbid to use the `double()' syntax for properties, and forbid 
> to overload properties with non-property functions.  In other words:
> 
> foo(distance()); // error, can't use call syntax for properties
> double distance(int precision) {...} // error, can't overload a property

From my limited experience with C#, I know there's some kind of special 
property syntax. Maybe something like this would be a better solution?

private double myDistance;
public property distance
{
   double __get { return myDistance; }
   void __set(double val) { myDistance= val; }
   double* __addressOf { return &myDistance; }
}

double x = distance;    // x = distance.__get();
distance = 50.0;        // distance.__set(50.0);
double* p = &distance;  // p = distance.__addressOf();

And maybe add more property-properties as needed. This would make them 
first-class, fully interchangeable with variables.
February 06, 2008
Re: x.sizeof vs typeid(x)
Robert Fraser:
>  From my limited experience with C#, I know there's some kind of special 
> property syntax. Maybe something like this would be a better solution?

If you take a look at my last post of notes (the 4th) you can see I suggested something even better, coming from C# 3.x ;-)

Bye,
bearophile
February 06, 2008
Re: x.sizeof vs typeid(x)
Robert Fraser <fraserofthenight@gmail.com> wrote:
>  From my limited experience with C#, I know there's some kind of special 
> property syntax. Maybe something like this would be a better solution?
> 
> private double myDistance;
> public property distance
> {
>     double __get { return myDistance; }
>     void __set(double val) { myDistance= val; }
>     double* __addressOf { return &myDistance; }
> }
> 
> double x = distance;    // x = distance.__get();
> distance = 50.0;        // distance.__set(50.0);
> double* p = &distance;  // p = distance.__addressOf();
> 
> And maybe add more property-properties as needed. This would make them 
> first-class, fully interchangeable with variables.

Yes, this would be far more consistent of course.  I've just tried to 
keep to the current syntax and semantics as close as possible.
-- 
SnakE
February 06, 2008
Re: x.sizeof vs typeid(x)
Robert Fraser wrote:
> Matti Niemenmaa wrote:
>> 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.
>> 
> 
> Oops, forgot about those... alright, well I guess then people just need 
> to be careful with this syntax.

I've actually used that when making bindings for a C library which has 
got some volatile globals.  Just property wrappers with volatile 
statements in them.  At least it made the examples easier to port. 
Whether this syntax is good or bad in general, I'm not sure.
February 07, 2008
Re: x.sizeof vs typeid(x)
Sergey Gromov wrote:
> 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) {...}
> 

I just don't like "});". The less closing parens the better. :)


Semantically, read it as "auto GetEven = stackthread
                                      = (int delegate() read, void delegate(int) yield) { ... };]".

--downs
February 07, 2008
Re: x.sizeof vs typeid(x)
Sergey Gromov 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 ?

Because expression.identifier always yields an expression, whereas 
typeof() always yields a type. It makes parsing easier and more consistent.
February 07, 2008
Re: x.sizeof vs typeid(x)
Walter Bright wrote:
> Sergey Gromov 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 ?
> 
> Because expression.identifier always yields an expression, whereas 
> typeof() always yields a type. It makes parsing easier and more consistent.

typeid yeilds an expression...
February 07, 2008
Re: x.sizeof vs typeid(x)
On Wed, 06 Feb 2008 18:51:49 -0800, Walter Bright wrote:

> Sergey Gromov 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 ?
> 
> Because expression.identifier always yields an expression, whereas
> typeof() always yields a type. It makes parsing easier and more
> consistent.

From a users perspective, my first thought is always that it should be 
used similar to a type alias in a struct/class.
.typeof feels also more consistent with .length, .sizeof or .stringof.

typeof() looks like a build-in compile time function, but the feeling to 
access the AST is definitely nicer.

Thought, I don't know if typeof() is worth the gains on the parsing side.
1 2 3 4
Top | Discussion index | About this forum | D home