x.sizeof vs typeid(x)

[Tom S]

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