View mode: basic / threaded / horizontal-split · Log in · Help
February 07, 2008
Re: x.sizeof vs typeid(x)
bearophile wrote:
> I was talking about free functions. I think for methods/properties the syntax
> without () can be kept...

As I said in another post, that which applies to properties applies equally well 
to free functions, due to global variables.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
February 07, 2008
Re: x.sizeof vs typeid(x)
Robert Fraser wrote:
> 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...

The subject says typeid, the post says typeof !

typeid(type) looks for a type between the parentheses, and a type has a 
different grammar than an expression.
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);}

And when I actually asked for comments about that syntax, no one stated 
that it was unreadable ... thanks for the (mislocated) feedback.

As for the exact form of that use() in .. statement, I made it so with 
the sole purpose of it being *readable*. It may be new to you; it 
usually makes people think that the construct is built into D, resulting 
in some confusion ("did I miss anything in the spec?"). Yet ultimately 
using the language's features to write code which looks built-in makes 
code easier to read. If my statement is false, then using AST macros in 
lisp makes the code less readable as well.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
February 07, 2008
Re: x.sizeof vs typeid(x)
Walter Bright wrote:
> Robert Fraser wrote:
>> typeid yeilds an expression...
> 
> The subject says typeid, the post says typeof !
> 
> typeid(type) looks for a type between the parentheses, and a type has a 
> different grammar than an expression.

real.nan?
February 07, 2008
Re: x.sizeof vs typeid(x)
Tom S <h3r3tic@remove.mat.uni.torun.pl> wrote:
> 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);}
> 
> And when I actually asked for comments about that syntax, no one stated 
> that it was unreadable ... thanks for the (mislocated) feedback.

I don't know where or when you have asked for this.  It's not my job to 
read through years of discussions, and I'm not obligated to read every 
single post even though I do monitor the group.

Someone has cited this code in D.learn asking what it does.  That's 
exactly what I mean.

> As for the exact form of that use() in .. statement, I made it so with 
> the sole purpose of it being *readable*. It may be new to you; it 
> usually makes people think that the construct is built into D, resulting 
> in some confusion ("did I miss anything in the spec?"). Yet ultimately 
> using the language's features to write code which looks built-in makes 
> code easier to read. If my statement is false, then using AST macros in 
> lisp makes the code less readable as well.

I'm not familiar with Lisp.  Anyway, when I say 'readable,' I mean that 
I can look into an unfamiliar code written by other person and 
understand, in general, what's happening.  This class is having this 
method called with these arguments.  That template is instantiated with 
those types.  Basically, it should be enough to read language 
specification to understand the code.  In your case you're inventing a 
construct which doesn't quite fit into specs, which in turn causes 
confusion.

-- 
SnakE
February 07, 2008
Re: x.sizeof vs typeid(x)
Sergey Gromov wrote:
> I don't know where or when you have asked for this.  It's not my job to 
> read through years of discussions, and I'm not obligated to read every 
> single post even though I do monitor the group.
> 
> Someone has cited this code in D.learn asking what it does.  That's 
> exactly what I mean.

Ah, fine then, I thought you saw me pasting a more complete example on 
IRC on #d :)
Anyway, here it is, so maybe it makes some more sense this time: 
http://paste.dprogramming.com/dpn66vhk

It's an example from an unreleased OpenGL wrapper. The ext/use(...) in 
{}; constructs actually play an important role in its functioning, 
restricting access to the resource to a controlled region, executing 
special code before and after it, and in the case of 'ext', allowing an 
extra parameter after a variadic one.


> I'm not familiar with Lisp.  Anyway, when I say 'readable,' I mean that 
> I can look into an unfamiliar code written by other person and 
> understand, in general, what's happening.  This class is having this 
> method called with these arguments.  That template is instantiated with 
> those types.  Basically, it should be enough to read language 
> specification to understand the code.  In your case you're inventing a 
> construct which doesn't quite fit into specs, which in turn causes 
> confusion.

Doesn't fit into the specs? How so? It's not like I'm preprocessing D.
I've talked with a few folks who have been coding in D for a while, and 
they immediately recognized the constructs. The func call, proxy object, 
opIn and the inline delegate.
It's not a surprise that fancy D code may cause confusion in D.learn, 
since well, it's an NG for beginners...

Let's take another example. For someone coming from Java, operator 
overloads might be unreadable code because when they see a + b, they 
can't know what's happening. But it's normal for D code. Someone coming 
from C would see any OO stuff unreadable. D is a relatively new language 
and there really isn't a common understanding of how 'readable' D code 
should look like. It's got its very own feel and syntax, to which 
programmers must get used and perhaps notice that some things can be 
implemented in a much different way than in their old favorite language.



-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
February 07, 2008
Re: x.sizeof vs typeid(x)
Tom S <h3r3tic@remove.mat.uni.torun.pl> wrote:
> Sergey Gromov wrote:
> > I'm not familiar with Lisp.  Anyway, when I say 'readable,' I mean that 
> > I can look into an unfamiliar code written by other person and 
> > understand, in general, what's happening.  This class is having this 
> > method called with these arguments.  That template is instantiated with 
> > those types.  Basically, it should be enough to read language 
> > specification to understand the code.  In your case you're inventing a 
> > construct which doesn't quite fit into specs, which in turn causes 
> > confusion.
> 
> Doesn't fit into the specs? How so? It's not like I'm preprocessing D.
> I've talked with a few folks who have been coding in D for a while, and 
> they immediately recognized the constructs. The func call, proxy object, 
> opIn and the inline delegate.
> It's not a surprise that fancy D code may cause confusion in D.learn, 
> since well, it's an NG for beginners...

OK so I'm new to D, too.  It's a part of a problem.  I have quite strong 
C/C++/Java background, and I do like the strictness of Java.  But 
anyway.  opIn has a distinct default semantics in the language.  It's 
"check if," not an "apply to."  The ability to overload is here to mimic 
the default semantics for non-ordinary types.  It's a bad practice IMO 
to completely change operator semantics.  That's exactly why a 
concatenation operator is added to D: to ensure that what you think is 
being done is actually what is done, at least conceptually.

That's also the reason I didn't like the luabind library for C++. Here's 
a piece of C++ code:

   module(L)
   [
       def("greet", &greet)
   ];

What it does, God knows.

-- 
SnakE
February 08, 2008
Re: x.sizeof vs typeid(x)
Sergey Gromov wrote:
> opIn has a distinct default semantics in the language.  It's 
> "check if," not an "apply to."  The ability to overload is here to mimic 
> the default semantics for non-ordinary types.  It's a bad practice IMO 
> to completely change operator semantics.

Well then, the whole C++ committee is following bad practice as well, by 
making << and >> work with streams. Following semantics is one thing - 
sure. It's crucial when you're making your own Map container to support 
it in exactly the same way as the built-in AAs do. But if you can make 
your code more natural to write by abusing the operators a little - 
opIn, operator<<, etc, then it's not a very bad practice IMHO. In fact, 
anyone defining opMul for their matrix class/struct is breaking 
semantics. The spec states that opMul is commutative.


> That's exactly why a 
> concatenation operator is added to D: to ensure that what you think is 
> being done is actually what is done, at least conceptually.

Wrong. As far as I know, it was added because D was supposed to have 
array operations, so you could say [1, 2] + [10, 10] and have [11, 12], 
not the concatenation.


> That's also the reason I didn't like the luabind library for C++. Here's 
> a piece of C++ code:
> 
>     module(L)
>     [
>         def("greet", &greet)
>     ];
> 
> What it does, God knows.

It doesn't really matter. Would you actually know without looking at the 
implementation? It's easy to read, the language features used can be 
figured out rather easily.
What matters is that it's really easy to use. It's actually a very nice 
example of a DSL (Domain Specific Language) within C++. Would you rather 
write 4 times this much, in order just to have it look like the rest of 
C++ code? Because then, there's the low level C API...


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
February 08, 2008
Re: x.sizeof vs typeid(x)
What can I say.  I do not agree.  C++ committee is not the best 
exemplar.  Looking into implementation should be required to learn the 
details, not to understand what the hell is going on.  Creating the DSLs 
should be a privilege of scripting languages, that's what they are for, 
after all.

Tom S <h3r3tic@remove.mat.uni.torun.pl> wrote:
> Sergey Gromov wrote:
> > opIn has a distinct default semantics in the language.  It's 
> > "check if," not an "apply to."  The ability to overload is here to mimic 
> > the default semantics for non-ordinary types.  It's a bad practice IMO 
> > to completely change operator semantics.
> 
> Well then, the whole C++ committee is following bad practice as well, by 
> making << and >> work with streams. Following semantics is one thing - 
> sure. It's crucial when you're making your own Map container to support 
> it in exactly the same way as the built-in AAs do. But if you can make 
> your code more natural to write by abusing the operators a little - 
> opIn, operator<<, etc, then it's not a very bad practice IMHO. In fact, 
> anyone defining opMul for their matrix class/struct is breaking 
> semantics. The spec states that opMul is commutative.
> 
> 
> > That's exactly why a 
> > concatenation operator is added to D: to ensure that what you think is 
> > being done is actually what is done, at least conceptually.
> 
> Wrong. As far as I know, it was added because D was supposed to have 
> array operations, so you could say [1, 2] + [10, 10] and have [11, 12], 
> not the concatenation.
> 
> 
> > That's also the reason I didn't like the luabind library for C++. Here's 
> > a piece of C++ code:
> > 
> >     module(L)
> >     [
> >         def("greet", &greet)
> >     ];
> > 
> > What it does, God knows.
> 
> It doesn't really matter. Would you actually know without looking at the 
> implementation? It's easy to read, the language features used can be 
> figured out rather easily.
> What matters is that it's really easy to use. It's actually a very nice 
> example of a DSL (Domain Specific Language) within C++. Would you rather 
> write 4 times this much, in order just to have it look like the rest of 
> C++ code? Because then, there's the low level C API...

-- 
SnakE
February 08, 2008
Re: x.sizeof vs typeid(x)
On Feb 8, 2008 3:20 AM, Sergey Gromov <snake.scaly@gmail.com> wrote:
> What can I say.  I do not agree.  C++ committee is not the best
> exemplar.  Looking into implementation should be required to learn the
> details, not to understand what the hell is going on.  Creating the DSLs
> should be a privilege of scripting languages, that's what they are for,
> after all.

How is this different from other code? You have to look in any
implementation code to figure out what's going on internally, be it
with syntax sugar or not.

Anders
1 2 3 4
Top | Discussion index | About this forum | D home