I want to voice my opinion on .sizeof, .mangleof and all the other `*of`
properties.   They don't make a whole lot of sense.  sizeof(<var>)
makes sense.  var.size makes sense.  var.sizeof, however, seems lacking as
nothing comes after the of.
Also, why isn't typeof() a property? I'm assuming it has something to do
with the fact that it's evaluated at compile-time instead of runtime.
However, I still think that var.type would be a lot more consistent.
My 2 cents, thanks for listening.

-- 
Email works.

I think Walter choose to rename .size (as initially was) to .sizeof in order to
avoid conflicts when porting C code, where "size" was a common variable name
while "sizeof" wasn't (since it was a function).
I have an ambiguous opinion im my head about that, but I admit that .size would
be more (human language) coherent.

F



In article <dpe6fj$edf$1@digitaldaemon.com>, S. Chancellor says...
>
>
>I want to voice my opinion on .sizeof, .mangleof and all the other `*of`
>properties.   They don't make a whole lot of sense.  sizeof(<var>)
>makes sense.  var.size makes sense.  var.sizeof, however, seems lacking as
>nothing comes after the of.
>Also, why isn't typeof() a property? I'm assuming it has something to do
>with the fact that it's evaluated at compile-time instead of runtime.
>However, I still think that var.type would be a lot more consistent.
>My 2 cents, thanks for listening.
>
>-- 
>Email works.
>

S. Chancellor wrote:
> I want to voice my opinion on .sizeof, .mangleof and all the other `*of`
> properties.   They don't make a whole lot of sense.  sizeof(<var>)
> makes sense.  var.size makes sense.  var.sizeof, however, seems lacking as
> nothing comes after the of.
> Also, why isn't typeof() a property? I'm assuming it has something to do
> with the fact that it's evaluated at compile-time instead of runtime. However, I still think that var.type would be a lot more consistent.
> My 2 cents, thanks for listening.
> 

While generally you make a point, the reason that 'tyepof()' isn't a property is because it can be used with expressions, and does *not* evaluate its expression for more than type information.  So, for example:

# typeof(foo(i) / bar(j)) var ;

Here we declare 'var' according to the final type of the given expression, but *without* actually evaluating either 'foo(i)' or 'bar(i)' beyond function-matching and return-type exraction.

-- Chris Sauls

> While generally you make a point, the reason that 'tyepof()' isn't a property is because it can be used with expressions, and does *not* evaluate its expression for more than type information.  So, for example:
>
> # typeof(foo(i) / bar(j)) var ;

But couldn't the following be treated the same way?  It is, perhaps, more difficult for the compiler to see that the expression should be evaluated at compile time?

(foo(i) / bar(j)).typeof var;

-Craig

Craig Black wrote:
>> While generally you make a point, the reason that 'tyepof()' isn't a property is because it can be used with expressions, and does *not* evaluate its expression for more than type information.  So, for example:
>>
>> # typeof(foo(i) / bar(j)) var ;
> 
> But couldn't the following be treated the same way?  It is, perhaps, more difficult for the compiler to see that the expression should be evaluated at compile time?

Perhaps, but sizeof is evaluated at compile time as well.


Sean

> Perhaps, but sizeof is evaluated at compile time as well.

This does seem odd.  If it doesn't overcomplicate the compiler, then typeof should be consistent with the rest of the "*of" family.

-Craig

"Craig Black" <cblack@ara.com> wrote in message news:dpej71$s0i$1@digitaldaemon.com...
>> While generally you make a point, the reason that 'tyepof()' isn't a property is because it can be used with expressions, and does *not* evaluate its expression for more than type information.  So, for example:
>>
>> # typeof(foo(i) / bar(j)) var ;
>
> But couldn't the following be treated the same way?  It is, perhaps, more difficult for the compiler to see that the expression should be evaluated at compile time?
>
> (foo(i) / bar(j)).typeof var;

That leads to parsing problems, unfortunately, as it becomes difficult to recognize a declaration vs an expression.

"Craig Black" <cblack@ara.com> wrote in message news:dpek7p$tga$1@digitaldaemon.com...
> > Perhaps, but sizeof is evaluated at compile time as well.
>
> This does seem odd.  If it doesn't overcomplicate the compiler, then
typeof
> should be consistent with the rest of the "*of" family.

My 2 cents: all should be non-member operators, a la typeof.

In article <dpf5i1$1dp6$1@digitaldaemon.com>, Matthew says...
>
>"Craig Black" <cblack@ara.com> wrote in message news:dpek7p$tga$1@digitaldaemon.com...
>> > Perhaps, but sizeof is evaluated at compile time as well.
>>
>> This does seem odd.  If it doesn't overcomplicate the compiler, then
>typeof
>> should be consistent with the rest of the "*of" family.
>
>My 2 cents: all should be non-member operators, a la typeof.

Wouldn't that clutter up the namespace with all the properties from float and whatnot?

-S.

On Tue, 03 Jan 2006 20:07:48 -0500, S. Chancellor <S._member@pathlink.com> wrote:

> In article <dpf5i1$1dp6$1@digitaldaemon.com>, Matthew says...
>>
>> "Craig Black" <cblack@ara.com> wrote in message
>> news:dpek7p$tga$1@digitaldaemon.com...
>>> > Perhaps, but sizeof is evaluated at compile time as well.
>>>
>>> This does seem odd.  If it doesn't overcomplicate the compiler, then
>> typeof
>>> should be consistent with the rest of the "*of" family.
>>
>> My 2 cents: all should be non-member operators, a la typeof.
>
> Wouldn't that clutter up the namespace with all the properties from float and
> whatnot?
>
> -S.
>

I think he means just the "*of" ones (mangleof,sizeof...) that apply to most everything, and I wouldn't be upset if this switch was made.