Warren Young wrote:
> Rick Gutleber wrote:
>>
>> Templates are definitely still not instinctive for me... especially
>> the idea of "faking" inheritance of an abstract interface.
>
> I particularly recommend Douglas Crockford's _JavaScript: The Good
> Parts_. If you think you know JavaScript already but haven't read
> Crockford, you've probably just been speaking pidgin JS. JS is
> probably the most widely-deployed language now: most browsers, most of
> the professional Adobe apps, Flash, various server-side
> implementations... All we're missing is wide deployment of it as a
> command-line interpreter, a la Perl.
I'll take that under consideration. JavaScript is something I'd like to
play around with, partly because of your mentions of it, and I am in
serious need of doing some programming for programming's sake just to
give my mental map an upgrade. Getting things done is obviously very
important to doing your job, and I've been doing plenty of that, but
that whole "learning thing" is where the real quantum leaps occur. ;-)
>> It feels like cheating from an OO point of view,
>
> It's just a different kind of OO. Alan Kay, co-creator of Smalltalk,
> famously said, "I made up the term 'object-oriented', and I can tell
> you I did not have C++ in mind." That's not [just] a swipe at C++.
> It reflects the fact that the two languages have an entirely different
> approach to OO. Both have their merits, and their demerits.
I can't speak for Smalltalk vs. C++, but I still find templates to be
very non-OO in many ways. That's not a swipe either (well, actually,
it's a small one), but I think it's true.
For instance your insert( ) method takes two template parameters of type
"class Iter". This is not meant as a criticism of your work on any
level, but I find that really, really lame that you have to do that. In
my old class library (which had no templates), I would have been able to
do this:
insert( const IIteratable & iteratable ) {
for ( RIterator it( iterable ); it.hasMore( ); it++ ) {
}
}
Now, this isn't inherently better in every way... in some ways it
definitely isn't (for instance, in this case you're still going to have
up downcast the iteratable to something you can actually do something
with, or worse, derive an abstract class from IIteratable and
ISomethingElse solely to use it has an argument type), but the
philosophical problem I have with that kind of use of templates is that
you can't really know what the template is expecting unless you read the
code. There's no declaration somewhere that says that the template is
expecting X interface and what that interface would be, except for the
template code itself, which is possibly very hard to read and definitely
not concise in terms of describing the interface.
Looking at trying to write insertfrom( ) it occurred to me that I would
like to do something like this:
template < template < class RowT > class Container >
Query& insertfrom(const Container& con, InsertPolicy& policy )
{
...
Container::iter it = con.first();
...
}
Now whether or not this is actually possible or I just couldn't figure
out the precise syntax, since you didn't do something like that, my
guess is that it's likely it either can't be done or isn't a good idea.
> My view is, even if it does come out next year, it's as good as C++1x
> to me. I still have to build MySQL++ for CentOS 3, and will for the
> foreseeable future. I'll be lucky to start using new C++ constructs
> in production code before the twenty-teens.
I don't even know how long it took the compilers to catch up with the
C++98 standard. I'd always understood that Microsoft C++ 2003 was the
most fully standards-compliant compiler at the time, implying that no
one was completely compliant for several years after the standard was
published (assuming they even are now!). I can't imagine that it would
go any faster this time around, possibly much, much slower since I find
it hard to believe that you could actually prove the language as
represented by the current candidate for the new standard is even
consistent and implementable without years of study, leave alone
actually doing it. (Ah, Tcl, _you'll_ never have that problem.)
I think C++ will eventually have to simply be replaced, which they've
been trying to do for 15 years or more, but the right candidate hasn't
come along yet. One of my former co-workers and I used to carpool
together and that was a frequent topic of discussion: What should a
proper successor to C++ actually look like? He's subsequently become a
zealous devotee of Tcl, which is how I got involved doing some good Tcl
work at AOL a few years ago, and I haven't talked to him about the topic
lately.
