July 23, 2009
Jason House wrote:
> Andrei Alexandrescu Wrote:
> 
>> I suggest anyone who wants to do something for D to focus on the installation aspect. It's a relatively well-defined project of high importance and high visibility. We simply can't afford to introduce D to the world without a state-of-the-art installation procedure.
>>
>>
>> Andrei
> 
> Not everyone is capable of effeciently helping in that area. Will there ever be an official list of things like this? Searching the mailing list is not an effective way of finding what you/Walter consider to be valuable additions. A list allows a motivated contributor to quickly find something that interests them. Having only one item also makes people think that somebody else is probably doing it and they don't need to help. 
> 

You may want to bookmark http://www.prowiki.org/wiki4d/wiki.cgi?PhobosToDo


Andrei
July 27, 2009
Andrei Alexandrescu wrote:
> Benji Smith wrote:
> Maybe if Andrei put together a list of 
>> missing Phobos functionality, we could get people from the community to flesh out the libs.
> 
> I think we'd need at a minimum:

<snip>

> That would be great. In general, it would be awesome to gather more contributions from the community. There's a thirst to contribute and we'll be glad to involve this group into some serious design e.g. for concurrency support, as well as accept code for functionality that belongs to the standard library.
> 
> In the bulleted list above there are many mini-projects that are confined enough to be done by one willing individual in a relatively short time.

Are there contributor guidelines somewhere?

For example, should the author of a container library prefer classes or structs? Should other (non-container) modules accept container classes as arguments? Or only container interfaces (if there are any such things) or just ranges?

Is it appropriate to use an empty struct purely as a namespace for the introduction of free functions? Or should free functions be placed at the module level?

Is it appropriate to define multiple classes, structs, templates, etc within a single module? What considerations should inform the decision regarding the placement of module boundaries?

What constitutes appropriate/inappropriate usage of opCall?

Anyhoo...

Point being, Phobos_1 was a hodgepodge of different conventions and styles. Tango_1 was considerably better, in terms of stylistic uniformity. But it used a very different set of idioms than Phobos_1 (lots of predicate functions, "sink" delegates, etc). Probably any author contributing code to Phobos_2 should spend a little time getting up to speed with the preferred idioms before writing code.

I suspect that my humble little JSON parser uses styles and idioms that would clash with the majority of Phobos_2 (since my programming pedigree comes from Java, C#, JavaScript, and Perl much moreso than C or C++).

--benji
July 27, 2009
Benji Smith wrote:
> Andrei Alexandrescu wrote:
>> Benji Smith wrote:
>> Maybe if Andrei put together a list of
>>> missing Phobos functionality, we could get people from the community to flesh out the libs.
>>
>> I think we'd need at a minimum:
> 
> <snip>
> 
>> That would be great. In general, it would be awesome to gather more contributions from the community. There's a thirst to contribute and we'll be glad to involve this group into some serious design e.g. for concurrency support, as well as accept code for functionality that belongs to the standard library.
>>
>> In the bulleted list above there are many mini-projects that are confined enough to be done by one willing individual in a relatively short time.
> 
> Are there contributor guidelines somewhere?

Not at the moment.

> For example, should the author of a container library prefer classes or structs?

I've been struggling with this forever. I don't know. I don't even know whether reference or value semantics are best for containers. I don't know whether abstract container interfaces and container-independent code are a net win; experience with STL seems to say "don't" and experience with Java seems to say "ho-hum".

> Should other (non-container) modules accept container classes as arguments? Or only container interfaces (if there are any such things) or just ranges?

I think ranges should be preferred wherever applicable.

> Is it appropriate to use an empty struct purely as a namespace for the introduction of free functions? Or should free functions be placed at the module level?

I think module-level functions are best. If there are lookup issues due to that, we need to fix the language. D is conceived to allow proper coexistence of functions in different modules without forcing the user to take too many precautions.

> Is it appropriate to define multiple classes, structs, templates, etc within a single module? What considerations should inform the decision regarding the placement of module boundaries?

I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails.

> What constitutes appropriate/inappropriate usage of opCall?

What examples do you have in mind?

> Anyhoo...
> 
> Point being, Phobos_1 was a hodgepodge of different conventions and styles. Tango_1 was considerably better, in terms of stylistic uniformity. But it used a very different set of idioms than Phobos_1 (lots of predicate functions, "sink" delegates, etc). Probably any author contributing code to Phobos_2 should spend a little time getting up to speed with the preferred idioms before writing code.

I agree. I am obviously subjective, but here are a few modules in phobos2 that seem to me close to the desired look and feel:

* std.algorithm is a large collection of functions mostly operating on one abstraction (ranges). If you know how to use one algorithm, you probably know how to use all others. Defining ranges that std.algorithm can work with is also a breeze.

* std.getopt is a very effective module. Although it does a fair amount of stuff, it has a simple interface that can be learned in minutes. I haven't seen an options parsing library that has the same power/ease ratio. Its usage of static types to infer what you want to do is a good showcase for the power of D templates and variadics.

* std.conv is simple (in interface), convenient, and general.

* std.range could use some maturing. I'm currently not 100% pleased about it.

* std.file looks a bit quaint (e.g. no classes) but I'm comfortable around it. It does what it's supposed to do and does it well.

* std.numeric is an example of a library that has a mix of functions and objects collected under an umbrella topic. I'm ok with it, but at some point I suspect I'd start worrying about its growth. Same about e.g. std.typecons.

* std.md5 is an example on why it's not that advisable to just copy a C interface into D. (This is a negative example.)

* std.random is a simple, extensible design, and has convenience functions  (such as uniform) that are, well, darn convenient. I see it growing easily and nicely.

> I suspect that my humble little JSON parser uses styles and idioms that would clash with the majority of Phobos_2 (since my programming pedigree comes from Java, C#, JavaScript, and Perl much moreso than C or C++).

Phobos2 doesn't have (m)any hierarchies not because Walter or I don't use them or like them. It's just that the particular stuff that's in Phobos right now is at an advantage by using other design means. But if you come with a good hierarchy implementing a piece of functionality, great.


Andrei
July 27, 2009
Andrei Alexandrescu Wrote:

> > Is it appropriate to define multiple classes, structs, templates, etc within a single module? What considerations should inform the decision regarding the placement of module boundaries?
> 
> I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails.
> 
> Andrei

The rule of thumb above is good in theory but in practice such a given bundle of functionality can produce a 30_000 line file. while all those lines should be "bundled" conceptually together, D's restriction of module == file makes for a huge file that is a hassle to work with.

yes, a "module" should represent a conceptual bundle of functionallity but forcing this into one huge file is wrong.

-- Yigal
July 27, 2009
yigal chripun wrote:
> Andrei Alexandrescu Wrote:
> 
>>> Is it appropriate to define multiple classes, structs, templates, etc within a single module? What considerations should inform the decision regarding the placement of module boundaries?
>> I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails.
>>
>> Andrei
> 
> The rule of thumb above is good in theory but in practice such a given bundle of functionality can produce a 30_000 line file. while all those lines should be "bundled" conceptually together, D's restriction of module == file makes for a huge file that is a hassle to work with. 
> 
> yes, a "module" should represent a conceptual bundle of functionallity but forcing this into one huge file is wrong. 

I think public import can help with that.

Andrei
July 27, 2009
Andrei Alexandrescu, el 27 de julio a las 07:59 me escribiste:
> >For example, should the author of a container library prefer classes or structs?
> 
> I've been struggling with this forever. I don't know. I don't even know whether reference or value semantics are best for containers. I don't know whether abstract container interfaces and container-independent code are a net win; experience with STL seems to say "don't" and experience with Java seems to say "ho-hum".

About values vs. reference semantics, I think reference is the best.
Containers usually are big, and you don't want to copy them arround.
I find myself using lots of references to pass containers arround in C++
and almost never use the copy() method of Python containers, so based on
*my* experience, I'd say that reference as the default is the best
approach.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Seducimos a una minita con el objetivo de llevarla a nuestro hogar; más
que seducirla la amenazamos con una botella.
	-- Sidharta Kiwi
July 27, 2009
Andrei Alexandrescu Wrote:

> yigal chripun wrote:
> > Andrei Alexandrescu Wrote:
> > 
> >>> Is it appropriate to define multiple classes, structs, templates, etc within a single module? What considerations should inform the decision regarding the placement of module boundaries?
> >> I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails.
> >>
> >> Andrei
> > 
> > The rule of thumb above is good in theory but in practice such a given bundle of functionality can produce a 30_000 line file. while all those lines should be "bundled" conceptually together, D's restriction of module == file makes for a huge file that is a hassle to work with.
> > 
> > yes, a "module" should represent a conceptual bundle of functionallity but forcing this into one huge file is wrong.
> 
> I think public import can help with that.
> 
> Andrei

That is just a work-around and not a full solution. this is a weak spot in D which I'd like to see fixed. I've already suggested in the past some ideas on how this can be solved. we need a reasonable tradeoff between the namespaces design of C# which is completely seperated from physical layout (filesystem) and the packages design of Java which is tightly coupled with the filesystem.
July 27, 2009
yigal chripun wrote:
> Andrei Alexandrescu Wrote:
> 
>> yigal chripun wrote:
>>> Andrei Alexandrescu Wrote:
>>> 
>>>>> Is it appropriate to define multiple classes, structs,
>>>>> templates, etc within a single module? What considerations
>>>>> should inform the decision regarding the placement of module
>>>>> boundaries?
>>>> I think it's appropriate because many pieces of functionality
>>>> come as a bundle. The rule of thumb is, module provides the
>>>> functionality, and it's up to the designer to decide what that
>>>> entails.
>>>> 
>>>> Andrei
>>> The rule of thumb above is good in theory but in practice such a
>>> given bundle of functionality can produce a 30_000 line file.
>>> while all those lines should be "bundled" conceptually together,
>>> D's restriction of module == file makes for a huge file that is a
>>> hassle to work with.
>>> 
>>> yes, a "module" should represent a conceptual bundle of
>>> functionallity but forcing this into one huge file is wrong.
>> I think public import can help with that.
>> 
>> Andrei
> 
> That is just a work-around and not a full solution.

Why?

> this is a weak
> spot in D which I'd like to see fixed.

Why is it a weak spot? What problems mar its advantages?


Andrei
July 27, 2009
Leandro Lucarella wrote:
> Andrei Alexandrescu, el 27 de julio a las 07:59 me escribiste:
>>> For example, should the author of a container library prefer classes or structs?
>> I've been struggling with this forever. I don't know. I don't even know
>> whether reference or value semantics are best for containers. I don't
>> know whether abstract container interfaces and container-independent
>> code are a net win; experience with STL seems to say "don't" and
>> experience with Java seems to say "ho-hum".
> 
> About values vs. reference semantics, I think reference is the best.
> Containers usually are big, and you don't want to copy them arround.
> I find myself using lots of references to pass containers arround in C++
> and almost never use the copy() method of Python containers, so based on
> *my* experience, I'd say that reference as the default is the best
> approach.

Sounds convincing.

Andrei
July 27, 2009
On Mon, 27 Jul 2009 08:59:40 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Benji Smith wrote:
>> For example, should the author of a container library prefer classes or structs?
>
> I've been struggling with this forever. I don't know. I don't even know whether reference or value semantics are best for containers. I don't know whether abstract container interfaces and container-independent code are a net win; experience with STL seems to say "don't" and experience with Java seems to say "ho-hum".

If you use classes with interfaces, then ranges can't be part of that equation.  Since ranges are for the most part structs, and structs can't currently support interfaces, you can't make an interface that accepts a range.  That's not to say ranges can't be part of classes, but they can't be part of interfaces.

When making dcollections, I tried to separate out what should be part of the interface, and what should be specific to each class.  What I found was that all the cursors (what you would call unsafe C++ iterators ;) ) could not be interface types, because they were structs for performance.  However, I wanted to have the ability to have two different containers ineroperate seamlessly with eachother, as long as the types were the same.  That suggested interfaces.  What I ended up with is two ways to deal with container elements, opApply and cursors.  I am biased of course, but I think it's the perfect combination of power, ease of use, and low cost of implementation.

I still have yet to incorporate a range concept into my design, but I think it can be bolted on using a container with two cursors.

>
>> Should other (non-container) modules accept container classes as arguments? Or only container interfaces (if there are any such things) or just ranges?
>
> I think ranges should be preferred wherever applicable.

Ranges imply templated functions, which mean:

- no polymorphism (although this requirement is questionable, most users don't derive from containers).
- no usage of interfaces
- each call may compile a new function (i.e. code bloat)

There is something to be said with the power of opApply here, since you can do it with a class or interface, with very decent performance (only one virtual call).

As I said earlier, a combination of both ranges and interfaces would be ideal.

-Steve