On Thursday, 19 April 2012 at 10:28:08 UTC, Tobias Pankrath wrote:
> On Thursday, 19 April 2012 at 09:24:23 UTC, Roman D. Boiko wrote:
>> On Friday, 13 April 2012 at 09:57:49 UTC, Ary Manzana wrote:
>>> Having a D compiler available as a library will (at least) give these benefits:
>>>
>
> What about joining forces with sdc then?

Wow! Didn't know there was a D compiler with Boost like licence.
Awesome job whoever started it.

On Thursday, 19 April 2012 at 11:01:10 UTC, Somedude wrote:
> Le 16/04/2012 13:58, Bernard Helyer a écrit :
>> 
>> I recall mentioning it via IRC. Which is hardly going to stand up
>> in a court. :V
>> 
> And given the ongoing Oracle-Google suit over the Java API license, this
> has to be taken seriously, I'm affraid....

Definitely. There are actually many stories to learn from. E.g.: http://en.wikipedia.org/wiki/SCO_v._IBM (and more at http://en.wikipedia.org/wiki/SCO_Group), http://blogs.computerworlduk.com/open-enterprise/2010/09/could-this-lawsuit-undermine-the-gnu-gpl/index.htm

On Thursday, 19 April 2012 at 09:58:52 UTC, Nick Sabalausky wrote:
> There's no attribution in MIT.

»The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software« – I am not a lawyer, but I what makes you so sure that binaries don't fall under this requirement as well?

The Boost people also seem to interpret MIT as requiring binary attribution; Dave Abrahams mentioned the binary clause in Boost as a difference to MIT in his OSI approval request at least ([1]).

David


[1] http://ideas.opensource.org/ticket/45

On Thursday, 19 April 2012 at 11:04:20 UTC, Ary Manzana wrote:
> On 4/19/12 12:48 AM, Jacob Carlborg wrote:
>> On 2012-04-18 14:49, Marco Leise wrote:
>>
>>> I want refactoring to be as simple as Foo.renameSymbol("std.path.sep",
>>> "std.path.dirSeperator"); if the connection between module- and
>>> filename allows "std.path" to be traced back to the original file.
>>
>> I'm not sure but I don't think that is enough. In Clang you do something
>> like this:
>>
>> 1. Get cursor of source location
>> 2. Get a unique global ID of the cursor the corresponds to the symbol
>> (unified symbol resolution)
>> 3. Walk the AST to find all matches of this ID
>> 4. Get the source location of the cursors which match
>> 5. Rename the symbol at the source location
>>
>
> Unfortunately rename can't be perfect in D because you can't apply it inside templates.

In general, there is nothing preventing renaming in templates or mixins, if you do renaming after semantic analysis. However, there can be some troubles, e.g., if mixin string is generated on the fly from some function. Compiler error should suffice in this case, or even better, refactoring tool should give a warning.

On Thursday, 19 April 2012 at 11:04:20 UTC, Ary Manzana wrote:
> On 4/19/12 12:48 AM, Jacob Carlborg wrote:
>> On 2012-04-18 14:49, Marco Leise wrote:
>>
>>> I want refactoring to be as simple as Foo.renameSymbol("std.path.sep",
>>> "std.path.dirSeperator"); if the connection between module- and
>>> filename allows "std.path" to be traced back to the original file.
>>
>> I'm not sure but I don't think that is enough. In Clang you do something
>> like this:
>>
>> 1. Get cursor of source location
>> 2. Get a unique global ID of the cursor the corresponds to the symbol
>> (unified symbol resolution)
>> 3. Walk the AST to find all matches of this ID
>> 4. Get the source location of the cursors which match
>> 5. Rename the symbol at the source location
>>
>
> Unfortunately rename can't be perfect in D because you can't apply it inside templates.

In general, there is nothing preventing renaming in templates or
mixins, if you do renaming after semantic analysis. However,
there can be some troubles, e.g., if mixin string is generated on
the fly from some function. Compiler error should suffice in this
case, or even better, refactoring tool should give a warning.

On 4/19/12 7:25 PM, Roman D. Boiko wrote:
> On Thursday, 19 April 2012 at 11:04:20 UTC, Ary Manzana wrote:
>> On 4/19/12 12:48 AM, Jacob Carlborg wrote:
>>> On 2012-04-18 14:49, Marco Leise wrote:
>>>
>>>> I want refactoring to be as simple as Foo.renameSymbol("std.path.sep",
>>>> "std.path.dirSeperator"); if the connection between module- and
>>>> filename allows "std.path" to be traced back to the original file.
>>>
>>> I'm not sure but I don't think that is enough. In Clang you do something
>>> like this:
>>>
>>> 1. Get cursor of source location
>>> 2. Get a unique global ID of the cursor the corresponds to the symbol
>>> (unified symbol resolution)
>>> 3. Walk the AST to find all matches of this ID
>>> 4. Get the source location of the cursors which match
>>> 5. Rename the symbol at the source location
>>>
>>
>> Unfortunately rename can't be perfect in D because you can't apply it
>> inside templates.
>
> In general, there is nothing preventing renaming in templates or
> mixins, if you do renaming after semantic analysis. However,
> there can be some troubles, e.g., if mixin string is generated on
> the fly from some function. Compiler error should suffice in this
> case, or even better, refactoring tool should give a warning.

T foo(T)(T x) {
  return x.something();
}

int something(int x) {
  return 1;
}

float something(float x) {
  return 1.0;
}

Now... go and rename the first function named "something". What do you do with "x.something()" inside the template... rename it or not?

On Thursday, 19 April 2012 at 12:16:05 UTC, Ary Manzana wrote:
> On 4/19/12 7:25 PM, Roman D. Boiko wrote:
>> On Thursday, 19 April 2012 at 11:04:20 UTC, Ary Manzana wrote:
>>> On 4/19/12 12:48 AM, Jacob Carlborg wrote:
>>>> On 2012-04-18 14:49, Marco Leise wrote:
>>>>
>>>>> I want refactoring to be as simple as Foo.renameSymbol("std.path.sep",
>>>>> "std.path.dirSeperator"); if the connection between module- and
>>>>> filename allows "std.path" to be traced back to the original file.
>>>>
>>>> I'm not sure but I don't think that is enough. In Clang you do something
>>>> like this:
>>>>
>>>> 1. Get cursor of source location
>>>> 2. Get a unique global ID of the cursor the corresponds to the symbol
>>>> (unified symbol resolution)
>>>> 3. Walk the AST to find all matches of this ID
>>>> 4. Get the source location of the cursors which match
>>>> 5. Rename the symbol at the source location
>>>>
>>>
>>> Unfortunately rename can't be perfect in D because you can't apply it
>>> inside templates.
>>
>> In general, there is nothing preventing renaming in templates or
>> mixins, if you do renaming after semantic analysis. However,
>> there can be some troubles, e.g., if mixin string is generated on
>> the fly from some function. Compiler error should suffice in this
>> case, or even better, refactoring tool should give a warning.
>
> T foo(T)(T x) {
>   return x.something();
> }
>
> int something(int x) {
>   return 1;
> }
>
> float something(float x) {
>   return 1.0;
> }
>
> Now... go and rename the first function named "something". What do you do with "x.something()" inside the template... rename it or not?

1. Ask the user or
2. Check if there is an instance of foo!int which refers to something. If so
and there is no other instance, that refers to another something: rename it.
3. If there in another instance: Ask the user to rename one, all, none.

On Thursday, 19 April 2012 at 12:31:24 UTC, Tobias Pankrath wrote:

>> T foo(T)(T x) {
>>  return x.something();
>> }
>>
>> int something(int x) {
>>  return 1;
>> }
>>
>> float something(float x) {
>>  return 1.0;
>> }
>>
>> Now... go and rename the first function named "something". What do you do with "x.something()" inside the template... rename it or not?
>
> 1. Ask the user or
> 2. Check if there is an instance of foo!int which refers to something. If so
> and there is no other instance, that refers to another something: rename it.
> 3. If there in another instance: Ask the user to rename one, all, none.

I would go ReSharper way: present user a tree with all occurrences of related symbols and checkboxes to include or exclude each. Or, in this particular case, display a list of affected types and checkboxes for each. This isn't VERY user friendly, though, but very flexible and reasonable. Give warnings if necessary.

Semantic analysis phase would provide information whether symbol is actually related, or only has the same name (but different semantics and scope).

On Thursday, 19 April 2012 at 12:55:50 UTC, Roman D. Boiko wrote:
> On Thursday, 19 April 2012 at 12:31:24 UTC, Tobias Pankrath wrote:
>
>>> T foo(T)(T x) {
>>> return x.something();
>>> }
>>>
>>> int something(int x) {
>>> return 1;
>>> }
>>>
>>> float something(float x) {
>>> return 1.0;
>>> }
>>>
>>> Now... go and rename the first function named "something". What do you do with "x.something()" inside the template... rename it or not?

> I would go ReSharper way: present user a tree with all occurrences of related symbols and checkboxes to include or exclude each. Or, in this particular case, display a list of affected types and checkboxes for each. This isn't VERY user friendly, though, but very flexible and reasonable. Give warnings if necessary.
>
> Semantic analysis phase would provide information whether symbol is actually related, or only has the same name (but different semantics and scope).

Respective convenience API would simply provide overloads and reasonable defaults for similar cases.

My point is that there is nothing in language itself preventing such functionality, if we have semantic analysis. The problem is related to user intentions, and decision should be made by the user (but the tool should provide good defaults and enough information).

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?

-- 
/Jacob Carlborg