Andrei Alexandrescu wrote:
dsimcha wrote:
== Quote from dsimcha (dsim...@yahoo.com)'s article
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
I'm quite unhappy with the API of std.regexp. It's a chaotic design
that
provides a hodgepodge of functionality and tries to use as many
synonyms
of "to find" in the dictionary (e.g. search, match). I could swear
Walter never really cared for using regexps, and that is felt
throughout
the design: it fills the bullet point but it's asinine to use.
Besides std.regexp only works with (narrow) strings and we want it to
work on streams of all widths and structures. One pet complaint I have
is that std.regexp puts a class around it all as if everybody's
favorite
pastime would be to inherit Regexp and override some random function
in it.
In the upcoming releases of D 2.0 there will be rather dramatic
breaking
changes of phobos. I just wanted to ask whether y'all could stomach yet
another rewritten API or you'd rather use std.regexp as it is for the
time being.
Andrei
As I've said before, anyone who can't stomach breaking changes w/o
complaining has
no business using D2 at this point. I'd rather deal with the
aggravation of stuff
breaking in the sort run to have a nice language and libraries to go
with it in
the long run.
This whole concept of ranges as you've created them seems to have
achieved the the
holy grail of both making simple things simple and complex things
possible, where
"complex things" includes needing code to be efficient, so I can see
your reason
for wanting to redo all kinds of stuff in them. This compares
favorably to C++
STL iterators, which are very flexible and efficient but a huge PITA
to use for
simple things because the syntax is so low-level and ugly, and to the
D1/early D2
way, which gives beautiful, simple notation for the more common cases
(basic
dynamic arrays), at the expense of flexiblity when doing more
complicated things
like streams, chaining, strides, etc.
BTW, can you elaborate on how arrays, both builtin and any library
versions, will
work when everything is finalized?
Well finalizations hinges not only on me but on Walter (bugfixes and a
couple of new features) and on all of you with the continuous stream of
great suggestions and ideas. Again, without being able to experiment
much I don't have a clear idea on how arrays/containers should at best
look like. The interesting challenge is accommodating good, precise
semantics with the freedom given by garbage collection. Here are some
highlights:
* Today's T[] will be firmly an incarnation of the random-access range
concept, to the extent that all code expecting a random-access range can
always be passed a T[] without any impedance adaptation.
* $ will be generalized to mean "end of range" even for infinite ranges.
* We don't have a solution to address the perils of extending a slice by
using ~=. We're considering adding the type T[new], but I'm not sure we
should take the hit of a new built-in type constructor, particularly
when it's implementable as a library.
* Fixed-size arrays will in all likelihood be value types. We couldn't
find any other semantics that works.
* Containers will have value semantics.
* "Resources come and go; memory is forever" is the likely default in D
resource management. This means that destroying e.g. an array of File
objects will close the underlying files, but will not deallocate the
memory allocated for them. In essence, destroying values means calling
the destructor but not delete-ing them (unless of course they're on the
stack). This approach has a number of disadvantages, but plenty of
advantages that compensate them in most applications.
* std.matrix will define memory layouts for a variety of popular
libraries and also the common means to iterate said layouts.
* For those who want containers with reference semantics, they can use
the type Class!(T) for any value type T. That includes built-in value
types (int, float...) and whichever value containers we define. It's
unclear to me whether this is enough to satisfy those in need for
complex container hierarchies.
Andrei
I've got a few questions about the proposed container value semantics:
a) I'd like to be able to do for instance:
List lst = new LinkedList();
i.e use interfaces everywhere and especially in functions so that I can
switch implementations easily when the need arises. In the above I can
choose to use singly or doubly linked list without making changes
throughout the code by using the List interface. Will this be possible
and how? is D going to get proper struct interfaces?
b) it is sometimes useful to have a container!(Base) store references to
instances of derived classes, a caconical example of this is a container
of Widget class in a UI framework, where you can, for instance iterate
over the container and paint all the different kinds of widgets on the
screen by calling the virtual paint method of the base class. How can
this be implemented with your proposed Class template?
-- Yigal
