x.sizeof vs typeid(x)

Sergey Gromov snake.scaly at gmail.com
Thu Feb 7 15:45:34 PST 2008


Tom S <h3r3tic at 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



More information about the Digitalmars-d mailing list