View mode: basic / threaded / horizontal-split · Log in · Help
April 19, 2012
Re: D Compiler as a Library
On Thursday, 19 April 2012 at 14:46:26 UTC, Jacob Carlborg wrote:
> On 2012-04-19 13:05, Ary Manzana wrote:
>
>> Unfortunately rename can't be perfect in D because you can't 
>> apply it
>> inside templates.
>
> Could you elaborate a bit on why this is?

Please see several last messages for this discussion.
April 19, 2012
Re: D Compiler as a Library
On Thursday, 19 April 2012 at 14:46:26 UTC, Jacob Carlborg wrote:
> On 2012-04-19 13:05, Ary Manzana wrote:
>
>> Unfortunately rename can't be perfect in D because you can't 
>> apply it
>> inside templates.
>
> Could you elaborate a bit on why this is?

A template can be instantiated in user code with parameters that 
can't be known at library compile/refactor time (or mixed into, 
again unknown, scopes), and this can OTOH lead to problems like:

---
int doSomething(int a) {
  return a;
}

auto foo(T)(T t) {
  // User renames doSomething(int) above – should this be
  // changed as well?
  return t.doSomething();
}

unittest {
  assert(foo(3) == 3);
}
---

The question is, though, whether »perfect« renaming support is 
really required, or if a defensive solution warning on potential 
ambiguities isn't already useful enough for most cases.

David
April 19, 2012
Re: D Compiler as a Library
On Thursday, 19 April 2012 at 14:55:50 UTC, David Nadlinger wrote:
> The question is, though, whether »perfect« renaming support 
> is really required, or if a defensive solution warning on 
> potential ambiguities isn't already useful enough for most 
> cases.
>
> David

"Perfect" support is impossible, I guess. For example, if a 
library has been released,  a rename would cause API breaking 
changes. But for code under control of user which is doing the 
raname it is possible to provide customization what to rename 
(ReSharper does that, for example).
April 19, 2012
Re: D Compiler as a Library
On Thursday, 19 April 2012 at 10:15:36 UTC, Roman D. Boiko wrote:
> Actually, I prefer Boost only because it is slightly more 
> popular […]

Not to argue about the Boost license being popular in the D 
community, and not that the question would really matter, but 
what leads you to this general conclusion? I couldn't find any 
credible statistics on a quick Google search, but a numer of well 
known projects use the/a MIT license (X, Ruby on Rails, Mono, 
Lua, …).

David
April 19, 2012
Re: D Compiler as a Library
On Thursday, 19 April 2012 at 15:11:50 UTC, David Nadlinger wrote:
> On Thursday, 19 April 2012 at 10:15:36 UTC, Roman D. Boiko 
> wrote:
>> Actually, I prefer Boost only because it is slightly more 
>> popular […]
>
> Not to argue about the Boost license being popular in the D 
> community, and not that the question would really matter, but 
> what leads you to this general conclusion? I couldn't find any 
> credible statistics on a quick Google search, but a numer of 
> well known projects use the/a MIT license (X, Ruby on Rails, 
> Mono, Lua, …).
>
> David

I wish I could delete that post :) My claim is not based on any 
research.
However, I prefer Boost because:

"The Boost Software License is based upon the MIT license, but 
differs from the MIT license in that it:

(i) makes clear that licenses can be granted to organizations as 
well as individuals;

(ii) does not require that the license appear with executables or 
other binary uses of the library;

(iii) expressly disclaims -- on behalf of the author and 
copyright holders of the software only -- the warranty of title 
(a warranty that, under the Uniform Commercial Code, is separate 
from the warranty of non-infringement)

(iv) does not extend the disclaimer of warranties to licensees, 
so that they may, if they choose, undertake such warranties 
(e.g., in exchange for payment)."

http://ideas.opensource.org/ticket/45
April 19, 2012
Re: D Compiler as a Library
Le 19/04/2012 17:23, Roman D. Boiko a écrit :
> On Thursday, 19 April 2012 at 15:11:50 UTC, David Nadlinger wrote:
>> On Thursday, 19 April 2012 at 10:15:36 UTC, Roman D. Boiko wrote:
>>> Actually, I prefer Boost only because it is slightly more popular […]
>>
>> Not to argue about the Boost license being popular in the D community,
>> and not that the question would really matter, but what leads you to
>> this general conclusion? I couldn't find any credible statistics on a
>> quick Google search, but a numer of well known projects use the/a MIT
>> license (X, Ruby on Rails, Mono, Lua, …).
>>
>> David
>
> I wish I could delete that post :) My claim is not based on any research.
> However, I prefer Boost because:
>
> "The Boost Software License is based upon the MIT license, but differs
> from the MIT license in that it:
>
> (i) makes clear that licenses can be granted to organizations as well as
> individuals;
>
> (ii) does not require that the license appear with executables or other
> binary uses of the library;
>
> (iii) expressly disclaims -- on behalf of the author and copyright
> holders of the software only -- the warranty of title (a warranty that,
> under the Uniform Commercial Code, is separate from the warranty of
> non-infringement)
>
> (iv) does not extend the disclaimer of warranties to licensees, so that
> they may, if they choose, undertake such warranties (e.g., in exchange
> for payment)."
>
> http://ideas.opensource.org/ticket/45

Very good point. Is it too late to change again ?

By the way, what is the status of the attribution clause ?
April 19, 2012
Re: D Compiler as a Library
On Thursday, 19 April 2012 at 15:30:21 UTC, deadalnix wrote:

>> "The Boost Software License is based upon the MIT license, but 
>> differs
>> from the MIT license in that it:
>>
>> (i) makes clear that licenses can be granted to organizations 
>> as well as
>> individuals;
>>
>> (ii) does not require that the license appear with executables 
>> or other
>> binary uses of the library;
>>
>> (iii) expressly disclaims -- on behalf of the author and 
>> copyright
>> holders of the software only -- the warranty of title (a 
>> warranty that,
>> under the Uniform Commercial Code, is separate from the 
>> warranty of
>> non-infringement)
>>
>> (iv) does not extend the disclaimer of warranties to 
>> licensees, so that
>> they may, if they choose, undertake such warranties (e.g., in 
>> exchange
>> for payment)."
>>
>> http://ideas.opensource.org/ticket/45
>
> Very good point. Is it too late to change again ?
>
> By the way, what is the status of the attribution clause ?

If it will be decided to change the license, please pay attention 
to how should programmers apply the license to source and header 
files:

"Add a comment based on the following template, substituting 
appropriate text for the italicized portion:

//          Copyright Joe Coder 2004 - 2006.
// Distributed under the Boost Software License, Version 1.0.
//    (See accompanying file LICENSE_1_0.txt or copy at
//          http://www.boost.org/LICENSE_1_0.txt)
Please leave an empty line before and after the above comment 
block. It is fine if the copyright and license messages are not 
on different lines; in no case there should be other intervening 
text. Do not include "All rights reserved" anywhere.

Other ways of licensing source files have been considered, but 
some of them turned out to unintentionally nullify legal elements 
of the license. Having fixed language for referring to the 
license helps corporate legal departments evaluate the boost 
distribution. Creativity in license reference language is 
strongly discouraged, but judicious changes in the use of 
whitespace are fine."

http://www.boost.org/users/license.html

Alternatively, a license copy may be referenced at 
http://opensource.org/licenses/bsl1.0.html, which looks nicer. :)
April 19, 2012
Re: D Compiler as a Library
> If it will be decided to change the license, please pay attention to how
> should programmers apply the license to source and header files:

or do it the way it is done in phobos.
April 19, 2012
Re: D Compiler as a Library
Am Thu, 19 Apr 2012 11:24:34 +0200
schrieb Jacob Carlborg <doob@me.com>:

> On 2012-04-19 10:48, Roman D. Boiko wrote:
> 
> > Convenience interface on top of low-level core functionality can be
> > provided and would suffice for many typical situations.
> 
> In that case I think something like this might work:
> 
> Foo.renameSymbol("file.d:16:4", "bar");
> 
> Where "file.d" is the file in which the symbol is located. ":16:4" would 
> be the row and column number. "bar" would be the new name of the symbol.

Doesn't the D module system make symbols unique? I thought with a set of open/relevant files (call it a project if you will) a symbol name can be given without ambiguities. This might go into bike shedding, but it looks like dropping one of D's strengths here. It is of course still necessary to have code to look up symbols under the cursor, no question.

-- 
Marco
April 19, 2012
Re: D Compiler as a Library
On Thursday, 19 April 2012 at 16:38:31 UTC, Marco Leise wrote:
> Am Thu, 19 Apr 2012 11:24:34 +0200
> schrieb Jacob Carlborg <doob@me.com>:
>
>> On 2012-04-19 10:48, Roman D. Boiko wrote:
>> 
>> > Convenience interface on top of low-level core functionality 
>> > can be
>> > provided and would suffice for many typical situations.
>> 
>> In that case I think something like this might work:
>> 
>> Foo.renameSymbol("file.d:16:4", "bar");
>> 
>> Where "file.d" is the file in which the symbol is located. 
>> ":16:4" would be the row and column number. "bar" would be the 
>> new name of the symbol.
>
> Doesn't the D module system make symbols unique? I thought with 
> a set of open/relevant files (call it a project if you will) a 
> symbol name can be given without ambiguities. This might go 
> into bike shedding, but it looks like dropping one of D's 
> strengths here. It is of course still necessary to have code to 
> look up symbols under the cursor, no question.

I doubt specifying symbol it would be any better than location. 
For example, you would not be able to rename a local variable or 
any other symbol nested in a function.
2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home