> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: vrijdag 13 maart 2015 08:53
> To: dev_at_subversion.apache.org
> Subject: Re: AW: Convenient array & hash iterators & accessors
>
> On 13.03.2015 08:43, Markus Schaber wrote:
> >
> > Hi,
> >
> >
> >
> > I just wanted to throw „Rust“ into the discussion.
> >
> >
> >
> > Rust seems to have a very expressive type model, which allows to
> > handle most of the memory management automatically and compile-time-
> safe.
> >
> >
> >
> > It also allows to go very “low level” / “lean” (they even wrote
> > bootloaders and POC Kernels with it).
> >
> >
> >
> > It is compiled to native code, and has rather good C interfacing
> > capabilities.
> >
> >
> >
> >
> >
> > On the other hand, I tend to oppose C++. While it feels “natural” to
> > “upgrade” from C to C++, the mere complexity of that language makes it
> > very difficult, at least if a project does not restrict itself to a
> > very well thought, strictly defined subset.
> >
> >
> >
> > Grüße,
> >
> > Markus
> >
> >
> >
> > *Von:*Erik Huelsmann [mailto:ehuels_at_gmail.com]
> > *Gesendet:* Freitag, 6. März 2015 22:37
> > *An:* Julian Foad
> > *Cc:* Branko Čibej; dev_at_subversion.apache.org
> > *Betreff:* Re: Convenient array & hash iterators & accessors
> >
> >
> >
> >
> >
> > > It would make sense to design type-safe, light-weight container and
> > > iterator template wrappers around the APR structures if we
> > decided to
> > > write code in C++. Since we're not, "explicit is better than
> > > implicit".
> >
> > I understand the point. I note that "explicit" is not a binary
> > quality: there are degrees of it.
> >
> > I suppose I want to be writing in a higher level language. Maybe I
> > should just go ahead and really do so.
> >
> >
> >
> > Exactly. There's been talk about doing so for much too long without
> > action (other than attempts - including my own) to find a way to
> > "upgrade" C to something less verbose and more expressive.
> >
> >
> >
> > I've been long thinking that there are specific areas which are
> > more-or-less stand-alone, might be a good place to start this
> > strategy. One place like that might qualify is the piece of code that
> > deduces the eligeable revisions in merge tracking. That's the code I'm
> > thinking you're now working in?
> >
> >
> >
> > What kind of language were you thinking about? One of the languages
> > that came to mind is 'lua' which seems to have a pretty strong focus
> > on being integratable with C code. For lua there are also tools to
> > embed the compiled bytecode in a C library so the entire higherlevel
> > language can be fully encapsulated inside our libraries.
> >
>
> Why not Groovy (soon to be incubating at the ASF). That way we keep
> things in the family, and we're likely to eventually move everything to
> a JVM-based implementation instead of this silly native-compiled, last
> century stuff.
I wouldn't have a problem with requiring a small bytecode interpreter/stack machine inside libsvn_*, but a full JVM is certainly not something that can be embedded in every application. That changes the entire process requirements.
I don't think multiple JVMs can run in the same process (especially different versions), and attaching to an existing VM introduces different problems. In AnkhSVN I run Subversion inside a process that potentially has multiple .Net runtimes loaded, and until Visual Studio is redesigned into a 64 bit process somewhere in the far future I certainly can't just load a JVM in the process.
TortoiseSVN has similar (if not stricter) limitations, but it is already multi process to avoid having to integrate everything into every process. (Not sure how much of Subversion they still load in every process that uses explorer infrastructure)
I don't see a problem using something internally, and still providing a 100% C compatible api...
A good subset of C++ to introduce more type safety would be a good option... But I can't think of a good way to define the subset and really limit us to such a subset...
And using more and more C++ will shrink the pool of developers that would be able to join.
By developing our own macro world in C we would have the same problem though...
Bert
>
> -- Brane
Received on 2015-03-13 10:06:55 CET