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