April 12, 2009
Bill Baxter:
> But since pull-everything-in *is* the default.  I agree with Lars. Symbols supplied by modules should look unambiguous even when undecorated by their module name.  Or you could use the trick that Tango often uses -- make a static struct with a few members.  It's pretty ugly though, if you ask me.  Introducing a static struct just to get a namespace to replace the namespace that is already there but gets stripped as the default action upon 'import'.  Ick.

I'm waiting still for the design of the D2 module system to be fixed to something more rational than the current one.

The following has to import only the module name "foo" in the current namespace: import foo;

This is a syntax that imports into the current namespace all the names contained into the "foo" module (but it doesn't import the "foo" name itself):
import foo: *;

This imports the "bar" and "baz" names into the current namespace (but it doesn't import the "foo" name itself): import foo: bar, baz;

This fixes several problems. It also allows me to have a "foo" name inside the "foo" module without troubles (as the current system leads me to).

Be well,
bearophile
April 12, 2009
Bill Baxter wrote:
> On Sun, Apr 12, 2009 at 5:50 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> Lars Kyllingstad wrote:
>>> I think isInfinite!() should be called isInfiniteRange!(). The current
>>> name is, in my opinion, too general.
>> I'm undecided about this (and similar cases). isInfinite sits inside
>> std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange
>> feels redundant. On the other hand, I don't want to use too common symbols
>> because then the user will be forced to prefix them whenever they clash.
> 
> This is one of the big reasons why "static import" by default would
> have been better than pull-everything-in by default.
> 
> But since pull-everything-in *is* the default.  I agree with Lars.
> Symbols supplied by modules should look unambiguous even when
> undecorated by their module name.  Or you could use the trick that
> Tango often uses -- make a static struct with a few members.  It's
> pretty ugly though, if you ask me.  Introducing a static struct just
> to get a namespace to replace the namespace that is already there but
> gets stripped as the default action upon 'import'.  Ick.
> 
> --bb

import range=std.range;
April 12, 2009
Jason House wrote:
...
> There's no need for imported names to be unambiguous. Users can give
aliases to imports or import specific members. I hate how Tango puts stuff in structs for no good reason

I agree. It's not that hard to alias / static import. It may just be a matter of preference, but more verbose declarations do not tend to be more readable imho.

You have import std.range and the one hand and on the other (the parameter) you are also operating on a range, what more information would one need?

If isInfinity would be a member of the range, then even in Java one would not think of writing such constructs:

std.range.Range.isInfinityRange()






April 12, 2009
Andrei Alexandrescu wrote:
> Lars Kyllingstad wrote:
>> Andrei Alexandrescu wrote:
>>> Hi everybody,
>>>
>>>
>>> I just committed all of Phobos into svn on dsource.org. That is not an
>>> official release and has known and unknown bugs, limitations, and
>>> rhinodemons. I expect some ripples before we stabilize, but when we will
>>> we'll stabilize at a higher potential.
>>
>> Some corrections/suggestions to std.range, if you are ready for such yet:
> 
>> I think isInfinite!() should be called isInfiniteRange!(). The current name is, in my opinion, too general.
> 
> I'm undecided about this (and similar cases). isInfinite sits inside std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange feels redundant. On the other hand, I don't want to use too common symbols because then the user will be forced to prefix them whenever they clash.

I'm not too worried about name clashes, I just think it sounds wrong. If R is a range with infinitely many elements, I think it's more correct to say "R is an infinite range" than to say "R is infinite".

As an example of what I mean, let the range R be the sequence 1, 1/4, 1/9, ...:

  alias Sequence!("1/(n*n)", 1) R

Then, isInfiniteRange!(R) should obviously yield true. From a mathematical standpoint, I think the result of isInfinite!(R) is less obvious. Yes, the range has infinitely many elements, but none of them are infinite, nor is their sum infinite.

-Lars
April 12, 2009
On Sun, Apr 12, 2009 at 11:06 PM, Christopher Wright <dhasenan@gmail.com> wrote:
> Bill Baxter wrote:
>>
>> On Sun, Apr 12, 2009 at 5:50 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>> Lars Kyllingstad wrote:
>>>>
>>>> I think isInfinite!() should be called isInfiniteRange!(). The current
>>>> name is, in my opinion, too general.
>>>
>>> I'm undecided about this (and similar cases). isInfinite sits inside
>>> std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange
>>> feels redundant. On the other hand, I don't want to use too common
>>> symbols
>>> because then the user will be forced to prefix them whenever they clash.
>>
>> This is one of the big reasons why "static import" by default would have been better than pull-everything-in by default.
>>
>> But since pull-everything-in *is* the default.  I agree with Lars. Symbols supplied by modules should look unambiguous even when undecorated by their module name.  Or you could use the trick that Tango often uses -- make a static struct with a few members.  It's pretty ugly though, if you ask me.  Introducing a static struct just to get a namespace to replace the namespace that is already there but gets stripped as the default action upon 'import'.  Ick.
>>
>> --bb
>
> import range=std.range;

Not a default.

--bb
April 12, 2009
On 2009-04-12 11:09:51 -0400, Lars Kyllingstad <public@kyllingen.NOSPAMnet> said:

> Andrei Alexandrescu wrote:
>> Lars Kyllingstad wrote:
>>> I think isInfinite!() should be called isInfiniteRange!(). The current name is, in my opinion, too general.
>> 
>> I'm undecided about this (and similar cases). isInfinite sits inside std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange feels redundant. On the other hand, I don't want to use too common symbols because then the user will be forced to prefix them whenever they clash.
> 
> I'm not too worried about name clashes, I just think it sounds wrong. If R is a range with infinitely many elements, I think it's more correct to say "R is an infinite range" than to say "R is infinite".
> 
> As an example of what I mean, let the range R be the sequence 1, 1/4, 1/9, ...:
> 
>    alias Sequence!("1/(n*n)", 1) R
> 
> Then, isInfiniteRange!(R) should obviously yield true. From a mathematical standpoint, I think the result of isInfinite!(R) is less obvious. Yes, the range has infinitely many elements, but none of them are infinite, nor is their sum infinite.

Perhaps it should be renamed to isUnbounded then.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

April 12, 2009
Michel Fortin, el 12 de abril a las 12:54 me escribiste:
> On 2009-04-12 11:09:51 -0400, Lars Kyllingstad <public@kyllingen.NOSPAMnet> said:
> 
> >Andrei Alexandrescu wrote:
> >>Lars Kyllingstad wrote:
> >>>I think isInfinite!() should be called isInfiniteRange!(). The current name is, in my opinion, too general.
> >>I'm undecided about this (and similar cases). isInfinite sits inside std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange feels redundant. On the other hand, I don't want to use too common symbols because then the user will be forced to prefix them whenever they clash.
> >I'm not too worried about name clashes, I just think it sounds wrong. If R is a range with infinitely many elements, I think it's more correct to say "R is
> >an infinite range" than to say "R is infinite".
> >As an example of what I mean, let the range R be the sequence 1, 1/4, 1/9, ...:
> >   alias Sequence!("1/(n*n)", 1) R
> >Then, isInfiniteRange!(R) should obviously yield true. From a mathematical standpoint, I think the result of isInfinite!(R) is less obvious. Yes, the range has infinitely many elements, but none of them are infinite, nor is their sum infinite.
> 
> Perhaps it should be renamed to isUnbounded then.

I was about to write exaclty the same suggestion. I'm glad I read the responses before posting =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
If you don't know what direction you should take
You don't know where you are
April 12, 2009
Leandro Lucarella, el 12 de abril a las 15:19 me escribiste:
> Michel Fortin, el 12 de abril a las 12:54 me escribiste:
> > On 2009-04-12 11:09:51 -0400, Lars Kyllingstad <public@kyllingen.NOSPAMnet> said:
> > 
> > >Andrei Alexandrescu wrote:
> > >>Lars Kyllingstad wrote:
> > >>>I think isInfinite!() should be called isInfiniteRange!(). The current name is, in my opinion, too general.
> > >>I'm undecided about this (and similar cases). isInfinite sits inside std.range, so std.range.isInfinite is clear and std.range.isInfiniteRange feels redundant. On the other hand, I don't want to use too common symbols because then the user will be forced to prefix them whenever they clash.
> > >I'm not too worried about name clashes, I just think it sounds wrong. If R is a range with infinitely many elements, I think it's more correct to say "R is
> > >an infinite range" than to say "R is infinite".
> > >As an example of what I mean, let the range R be the sequence 1, 1/4, 1/9, ...:
> > >   alias Sequence!("1/(n*n)", 1) R
> > >Then, isInfiniteRange!(R) should obviously yield true. From a mathematical standpoint, I think the result of isInfinite!(R) is less obvious. Yes, the range has infinitely many elements, but none of them are infinite, nor is their sum infinite.
> > 
> > Perhaps it should be renamed to isUnbounded then.
> 
> I was about to write exaclty the same suggestion. I'm glad I read the responses before posting =)

Maybe isBounded, to avoid the double negation when checking for !isUnbounded...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
PITUFO ENRIQUE ATEMORIZA CATAMARCA, AMPLIAREMOS
	-- Crónica TV
April 13, 2009
On 2009-04-12 14:24:07 -0400, Leandro Lucarella <llucax@gmail.com> said:

> Leandro Lucarella, el 12 de abril a las 15:19 me escribiste:
>> Michel Fortin, el 12 de abril a las 12:54 me escribiste:
>>> On 2009-04-12 11:09:51 -0400, Lars Kyllingstad <public@kyllingen.NOSPAMnet> said:
>>> 
>>> Perhaps it should be renamed to isUnbounded then.
>> 
>> I was about to write exaclty the same suggestion. I'm glad I read the
>> responses before posting =)
> 
> Maybe isBounded, to avoid the double negation when checking for
> !isUnbounded...

Which makes me think of one thing: why "isBounded" instead of plain and simple "bounded"? Ranges don't respond to "isEmpty": they have "empty" instead.

I think it is time to establish some kind of standard for naming things, and then follow it. Something a little like Cocoa's Coding Guidelines comes to mind:

<http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html>


-- 


Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

April 13, 2009

Michel Fortin wrote:
> On 2009-04-12 14:24:07 -0400, Leandro Lucarella <llucax@gmail.com> said:
> 
>> Leandro Lucarella, el 12 de abril a las 15:19 me escribiste:
>>> Michel Fortin, el 12 de abril a las 12:54 me escribiste:
>>>> On 2009-04-12 11:09:51 -0400, Lars Kyllingstad <public@kyllingen.NOSPAMnet> said:
>>>>
>>>> Perhaps it should be renamed to isUnbounded then.
>>>
>>> I was about to write exaclty the same suggestion. I'm glad I read the responses before posting =)
>>
>> Maybe isBounded, to avoid the double negation when checking for !isUnbounded...
> 
> Which makes me think of one thing: why "isBounded" instead of plain and simple "bounded"? Ranges don't respond to "isEmpty": they have "empty" instead.
> 
> I think it is time to establish some kind of standard for naming things, and then follow it. Something a little like Cocoa's Coding Guidelines comes to mind:
> 
> <http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html>

You mean http://digitalmars.com/d/1.0/dstyle.html ?  That said, the "Naming Conventions" section is actually about formatting names, not choosing them.

One major advantage Cocoa has over D is that argument names seem to be part of the function's name.  For example, this call:

  sendAction(aSelector, anObject, flag);

appears to be written like so in Objective C:

  [sendAction: aSelector to: anObject forAllCells: flag];

To be honest, there are times I almost wish we could not only name arguments on the caller side, but demand that they're named in the definition.

  void sendAction(SEL, Object to, extern bool forAllCells);

  sendAction(aSelector,
    to: anObject,         // optional
    forAllCells: true);   // required



  -- Daniel