Just a few quick things I thought of while reading up on Phobos...

The naming convention doesn't seem particularly consistent.  Some functions use mixed case and others don't.  I assume the ones that don't are direct forwards to C library calls, but the difference is still a tad jarring.  I imagine it's too late to do anything about this?

Where is std.conv.toFloat?  It seems odd that I have to resort to streams just to convert to a floating point value.  Is there a reason for this?

Containers.  There aren't any.

I'll admit I was gearing up to find time to work on some perks for Phobos but I think I was being overly ambitious.  The library needs more core functionality first.  I've always liked the standard C++ library, but perhaps there's something better out there?  I'd like to work a bit on standard containers, algorithms, that kind of thing, which would mean establishing some standards (like how everything in the C++ world revolves around iterators).  I saw the "D standard library group proposal," where does that stand?


Sean

Sean Kelly wrote:

> Just a few quick things I thought of while reading up on Phobos...
> 
> The naming convention doesn't seem particularly consistent.  Some functions use mixed case and others don't.  I assume the ones that don't are direct forwards to C library calls, but the difference is still a tad jarring.  I imagine it's too late to do anything about this?

I agree. Although it's nice to use tolower, it should be toLower, etc.


> Where is std.conv.toFloat?  It seems odd that I have to resort to streams just to convert to a floating point value.  Is there a reason for this?

I think it just hasn't been made yet.


> Containers.  There aren't any.
> 
> I'll admit I was gearing up to find time to work on some perks for Phobos but I think I was being overly ambitious.  The library needs more core functionality first.  I've always liked the standard C++ library, but perhaps there's something better out there?  I'd like to work a bit on standard containers, algorithms, that kind of thing, which would mean establishing some standards (like how everything in the C++ world revolves around iterators).  I saw the "D standard library group proposal," where does that stand?
> 

-- 
Christopher E. Miller
www.dprogramming.com

Sean Kelly wrote:
> Containers.  There aren't any.
I'm working on a port of java collections, but interfaces and abstract classes have serious issues atm :(

Is a work-around to not have the class be abstract?  Will it behave properly? i.e inherit.  I'm running into this on the SWT port to D.


public abstract class Widget {}

public abstract class Drawable {}

public abstract class Control : Widget, Drawable {}

public class Button : Control {}


I think this is also causing some forward reference errors.

Brad




Sam McCall wrote:
> Sean Kelly wrote:
> 
>> Containers.  There aren't any.
> 
> I'm working on a port of java collections, but interfaces and abstract classes have serious issues atm :(

Don't write abstract on them. They become abstract automatically, but have right semantics.

You cannot inherit from 2 classes, only from a class and a number of interfaces. I think there was something like a special case for inheritance from a template.

-eye

Brad Anderson wrote:
> Is a work-around to not have the class be abstract?  Will it behave properly? i.e inherit.  I'm running into this on the SWT port to D.
> 
> 
> public abstract class Widget {}
> 
> public abstract class Drawable {}
> 
> public abstract class Control : Widget, Drawable {}
> 
> public class Button : Control {}
> 
> 
> I think this is also causing some forward reference errors.
> 
> Brad
> 

Okay, that was what I thought, but Drawable was an interface until the compiler complained about the function bodies being implemented:

<code>

public interface Drawable {

private import dwt.graphics.gcdata;

public int internal_new_GC (GCData data) {}

</code>

Compiler:
function internal_new_GC function body is not abstract in interface Drawable



Ilya Minkov wrote:

> Don't write abstract on them. They become abstract automatically, but have right semantics.
> 
> You cannot inherit from 2 classes, only from a class and a number of interfaces. I think there was something like a special case for inheritance from a template.
> 
> -eye
> 
> Brad Anderson wrote:
> 
>> Is a work-around to not have the class be abstract?  Will it behave properly? i.e inherit.  I'm running into this on the SWT port to D.
>>
>>
>> public abstract class Widget {}
>>
>> public abstract class Drawable {}
>>
>> public abstract class Control : Widget, Drawable {}
>>
>> public class Button : Control {}
>>
>>
>> I think this is also causing some forward reference errors.
>>
>> Brad
>>
> 

Ilya Minkov wrote:

> Don't write abstract on them. They become abstract automatically, but have right semantics.

Hmm, so is there anywhere we should use the abstract keyword?
This code still crashes.

interface Interface(T) {
	void foo();
}

class Abstract(T) : Interface!(T) {
	void foo();
}

class Concrete(T) : Abstract!(T) {
	void foo() {}
}

class Sub(T) : Concrete!(T) {
}

int main() {
	new Sub!(Object)();
	return 0;
}

"Sean Kelly" <sean@ffwd.cx> wrote in message news:c0bfs4$29o0$1@digitaldaemon.com...
> Just a few quick things I thought of while reading up on Phobos...
>
> The naming convention doesn't seem particularly consistent.  Some functions use mixed case and others don't.  I assume the ones that don't are direct forwards to C library calls, but the difference is still a tad jarring.  I imagine it's too late to do anything about this?

Not too late at all. In fact, I'll be rewriting some of them in the next few weeks

> Where is std.conv.toFloat?  It seems odd that I have to resort to streams just to convert to a floating point value.  Is there a reason for this?
>
> Containers.  There aren't any.
>
> I'll admit I was gearing up to find time to work on some perks for Phobos but I think I was being overly ambitious.  The library needs more core functionality first.  I've always liked the standard C++ library, but perhaps there's something better out there?  I'd like to work a bit on standard containers, algorithms, that kind of thing, which would mean establishing some standards (like how everything in the C++ world revolves around iterators).  I saw the "D standard library group proposal," where does that stand?

I don't think anything's happened with the DSLG. We're still waiting to hear from Walter on that one.

As for containers, please fire away. I'll be working on a DTL with Walter in March, but we welcome the competition. If we've two or three competing libraries, we stand a much better chance of getting something really good.

Cheers

Matthew