View mode: basic / threaded / horizontal-split · Log in · Help
March 31, 2011
Re: __traits so long and ugly, what about ::?
On 3/30/11 8:42 PM, Ary Manzana wrote:
> I just hate it when you have to write too much to get simple things
> done.
>
> Does this type have a member? Current approach:
>
> 1. import std.traits;
> 2. invoke hasMember!(S, "m")
>
> Another approach:
>
> 1. I have the type, let's ask it: S::hasMember("m")
>
> Map's thought to code.
>
> My problem is that when you start using D's cool features you end up
> with a really hard to understand and obscure code...

I understand and to a good extent agree with the sentiment.

However, right now GSoC with student proposals to attract and review, an 
undergoing Phobos proposal review, one or a couple more waiting in the 
queue, good progress in core areas (64 bit stabilization, rigorous 
deterministic destruction, important bug fixes, and to follow the 
immutability subsystem and shared libraries) I can't stop feeling many 
of such discussions do more harm than good. There's always a better way 
to express a frequent idiom, and we may as well adopt one later. But 
this is the time to act, and there's plenty to act on.

Let's focus on getting real work done. This is the D Summer of Code. :o)


Andrei
March 31, 2011
Re: __traits so long and ugly, what about ::?
On Mar 31, 11 11:24, Andrei Alexandrescu wrote:
> On 3/30/11 8:42 PM, Ary Manzana wrote:
>> I just hate it when you have to write too much to get simple things
>> done.
>>
>> Does this type have a member? Current approach:
>>
>> 1. import std.traits;
>> 2. invoke hasMember!(S, "m")
>>
>> Another approach:
>>
>> 1. I have the type, let's ask it: S::hasMember("m")
>>
>> Map's thought to code.
>>
>> My problem is that when you start using D's cool features you end up
>> with a really hard to understand and obscure code...
>
> I understand and to a good extent agree with the sentiment.
>
> However, right now GSoC with student proposals to attract and review, an
> undergoing Phobos proposal review, one or a couple more waiting in the
> queue, good progress in core areas (64 bit stabilization, rigorous
> deterministic destruction, important bug fixes, and to follow the
> immutability subsystem and shared libraries) I can't stop feeling many
> of such discussions do more harm than good. There's always a better way
> to express a frequent idiom, and we may as well adopt one later. But
> this is the time to act, and there's plenty to act on.
>
> Let's focus on getting real work done. This is the D Summer of Code. :o)
>
>
> Andrei

I think the GSoC group and language feature discussion group should be 
separated.
March 31, 2011
Re: __traits so long and ugly, what about ::?
On 03/30/2011 10:30 PM, KennyTM~ wrote:
> On Mar 31, 11 11:24, Andrei Alexandrescu wrote:
>> On 3/30/11 8:42 PM, Ary Manzana wrote:
>>> I just hate it when you have to write too much to get simple things
>>> done.
>>>
>>> Does this type have a member? Current approach:
>>>
>>> 1. import std.traits;
>>> 2. invoke hasMember!(S, "m")
>>>
>>> Another approach:
>>>
>>> 1. I have the type, let's ask it: S::hasMember("m")
>>>
>>> Map's thought to code.
>>>
>>> My problem is that when you start using D's cool features you end up
>>> with a really hard to understand and obscure code...
>>
>> I understand and to a good extent agree with the sentiment.
>>
>> However, right now GSoC with student proposals to attract and review, an
>> undergoing Phobos proposal review, one or a couple more waiting in the
>> queue, good progress in core areas (64 bit stabilization, rigorous
>> deterministic destruction, important bug fixes, and to follow the
>> immutability subsystem and shared libraries) I can't stop feeling many
>> of such discussions do more harm than good. There's always a better way
>> to express a frequent idiom, and we may as well adopt one later. But
>> this is the time to act, and there's plenty to act on.
>>
>> Let's focus on getting real work done. This is the D Summer of Code. :o)
>>
>>
>> Andrei
>
> I think the GSoC group and language feature discussion group should be
> separated.

That makes sense, but I'd rather encourage our limited regular 
participants to use their limited time on constructive discussions that 
address needs both important and urgent. That would be a lot better than 
spreading ourselves too thin.

Andrei
March 31, 2011
Re: __traits so long and ugly, what about ::?
On 3/30/11 9:45 PM, KennyTM~ wrote:
> On Mar 31, 11 03:28, Ary Manzana wrote:
>> I think :: is not used in the language.
>>
>> In a recent article about D I saw:
>>
>> mixin(__traits(identifier, T) ~ " " ~
>> to!string(tolower(__traits(identifier, T)[0])) ~
>> __traits(identifier, T)[1..$] ~ ";");
>>
>> What if foo::bar were an alias for __traits(foo, bar) ?
>>
>> The code would look like this:
>>
>> mixin(T::identifier ~ " " ~
>> to!string(tolower(T::identifier[0])) ~
>> T::identifier[1..$] ~ ";");
>>
>> What do you think?
>>
>> Another uses:
>>
>> __traits(int, isArithmetic) ==> int::isArithmetic
>> __traits(C, isAbstractClass) ==> C::isAbstractClass
>>
>
> You've got the order wrong.
>
>> __traits(hasMember, S, "m") ==> S::hasMember("m")
>>
>> Well, you get the idea...
>>
>> :: might be applied to other compile time uses, but I just came up with
>> this...
>
> -1.
>
> This is confusing as :: is used to separate scopes in C++ (and PHP too).
> e.g.
>
> struct A {
> int x;
> bool isSame(const A other) pure const { return x == other.x; }
> }
>
> void main () {
> A a = A(2), b = A(2);
> assert ( a.isSame(b)); // ok
> assert (! a::isSame(b)); // ???
> }
>
> (How about that 'meta' namespace proposal? meta.hasMember(S, "m") )

I think think this is a valid reason. D does many things differently 
than C++. I don't know how many times I heard someone complaining about 
D's lack of struct inheritance.

-- 
/Jacob Carlborg
March 31, 2011
Re: __traits so long and ugly, what about ::?
On 3/30/11 9:28 PM, Ary Manzana wrote:
> I think :: is not used in the language.
>
> In a recent article about D I saw:
>
> mixin(__traits(identifier, T) ~ " " ~
> to!string(tolower(__traits(identifier, T)[0])) ~
> __traits(identifier, T)[1..$] ~ ";");
>
> What if foo::bar were an alias for __traits(foo, bar) ?
>
> The code would look like this:
>
> mixin(T::identifier ~ " " ~
> to!string(tolower(T::identifier[0])) ~
> T::identifier[1..$] ~ ";");
>
> What do you think?
>
> Another uses:
>
> __traits(int, isArithmetic) ==> int::isArithmetic
> __traits(C, isAbstractClass) ==> C::isAbstractClass
>
> __traits(hasMember, S, "m") ==> S::hasMember("m")
>
> Well, you get the idea...
>
> :: might be applied to other compile time uses, but I just came up with
> this...

I like it.

-- 
/Jacob Carlborg
March 31, 2011
Re: __traits so long and ugly, what about ::?
On Wed, 30 Mar 2011 22:28:27 +0300, Ary Manzana <ary@esperanto.org.ar>  
wrote:

> I think :: is not used in the language.
>
> In a recent article about D I saw:
>
> mixin(__traits(identifier, T) ~ " " ~
>        to!string(tolower(__traits(identifier, T)[0])) ~
>        __traits(identifier, T)[1..$] ~ ";");
>
> What if foo::bar were an alias for __traits(foo, bar) ?
>
> The code would look like this:
>
> mixin(T::identifier ~ " " ~
>        to!string(tolower(T::identifier[0])) ~
>        T::identifier[1..$] ~ ";");
>
> What do you think?
>
> Another uses:
>
> __traits(int, isArithmetic) ==> int::isArithmetic
> __traits(C, isAbstractClass) ==> C::isAbstractClass
>
> __traits(hasMember, S, "m") ==> S::hasMember("m")
>
> Well, you get the idea...
>
> :: might be applied to other compile time uses, but I just came up with  
> this...

I agree it is a problem (a small one) but i don't believe it deserves a  
new syntax. Especially not a major one like this.
Like many others i think "meta" is a much better choice.
March 31, 2011
Re: __traits so long and ugly, what about ::?
KennyTM~:

> I think the GSoC group and language feature discussion group should be 
> separated.

Regarding D/Phobos feature discussions, they don't damage the summer of code discussions significantly because they put in use almost a different part of the brain. The skills and attention required to write real code (or discuss closely about it, like discussion about what data structures to write down for the GSoC) are quite different from the skills needed to think about new design ideas for D or Phobos. For me such two things are so separated that I use one to relax my mind from doing the other too much.

Said that, and given the limited number of people here, a further newsgroup split is not good.

Bye,
bearophile
March 31, 2011
Re: __traits so long and ugly, what about ::?
On 03/31/2011 05:24 AM, Andrei Alexandrescu wrote:
>> My problem is that when you start using D's cool features you end up
>> with a really hard to understand and obscure code...
>
> I understand and to a good extent agree with the sentiment.

Pleased to read that :-) I've had this sentiment for a while as well. I'm 
afraid this is frightening. Large pieces of Phobos are hard to read, imo (eg 
std.format).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
March 31, 2011
Re: __traits so long and ugly, what about ::?
On 03/31/2011 03:52 AM, bearophile wrote:
> KennyTM~:
>
>> I think the GSoC group and language feature discussion group should
>> be separated.
>
> Regarding D/Phobos feature discussions, they don't damage the summer
> of code discussions significantly because they put in use almost a
> different part of the brain.

They do share the same time budget.

Andrei
March 31, 2011
Re: __traits so long and ugly, what about ::?
On Thu, 31 Mar 2011 10:16:58 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail@erdani.org> wrote:

> On 03/31/2011 03:52 AM, bearophile wrote:
>> KennyTM~:
>>
>>> I think the GSoC group and language feature discussion group should
>>> be separated.
>>
>> Regarding D/Phobos feature discussions, they don't damage the summer
>> of code discussions significantly because they put in use almost a
>> different part of the brain.
>
> They do share the same time budget.

So don't read/respond to the posts.  I think any discouragement for open  
discussion for any topic related to D is not a healthy attitude for an  
open community.

If you want to have a GSOC-only discussion group, create a new newsgroup  
or mailing list.  Do not hijack this group.

-Steve
1 2 3 4
Top | Discussion index | About this forum | D home