List:MySQL++« Previous MessageNext Message »
From:Rick Gutleber Date:November 3 2008 4:47pm
Subject:Re: InsertPolicy and Transactions
View as plain text  
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.



Thread
InsertPolicy and TransactionsRick Gutleber30 Oct
  • Re: InsertPolicy and TransactionsWarren Young31 Oct
    • Re: InsertPolicy and TransactionsRick Gutleber31 Oct
      • Re: InsertPolicy and TransactionsWarren Young31 Oct
        • Re: InsertPolicy and TransactionsRick Gutleber3 Nov