[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r30773 - trunk/notes

From: Branko Čibej <brane_at_xbc.nu>
Date: Thu, 24 Apr 2008 21:33:46 +0200

Karl Fogel wrote:
> brane_at_tigris.org writes:
>> --- trunk/notes/wc-ng-design Thu Apr 24 12:04:37 2008 (r30772)
>> +++ trunk/notes/wc-ng-design Thu Apr 24 12:07:54 2008 (r30773)
>> @@ -267,6 +267,9 @@ One way to prevent the lengthy 'if()' bl
>> to design a dispatch mechanism based on the path-state in WORKING/BASE and the
>> required transformation, dispatching to (small) functions which perform
>> solely that specific task.
>> +#####XBC Do please note that this suggests yet another instance of
>> + pure polymorphism coded in C. This runs contrary to the
>> + developer sanity requirement.
> Are we positive that wc-ng can't introduce C++?
> Just trying to keep an open mind. I've virtually no C++ experience
> myself, but I'm not necessarily opposed. I do want to make sure we're
> not ruling things out-of-bounds thoughtlessly, at least.

I'm frankly quite agnostic as to whether it's C++ or some other language
that directly supports the kinds of patterns that we use (with great
exertions) in our code. Our choice of implementation style is IMHO
becoming more and more of a burden.

The other issue is code size, which affects the time it takes to
read/understand and write/debug a piece of code. C has a relatively low
"semantic density" (for want of a better term ...); C++ is not
significantly better. If I had a choice, where raw computation
performance isn't absolutely critical, I'd implement new modules in
Python 3 and use an embedded interpreter to run them.

(Note that I'm not saying that the choice of C was wrong 10 ... er, I
mean 7 :) ... years ago. But times change.)

-- Brane

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-24 21:34:11 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.