View mode: basic / threaded / horizontal-split · Log in · Help
December 24, 2012
Re: About Go, D module naming
On 12/24/12 06:20, Martin Nowak wrote:
> On 12/23/12 03:35, Walter Bright wrote:
>> On 12/22/2012 8:03 AM, Andrei Alexandrescu wrote:
>>> I think this is a fallacious argument because it concludes that apples
>>> should be
>>> peeled because oranges should.
>>
>> Given, in C++:
>>
>> struct S
>> {
>>    public:
>>       void foo(int);
>>    private:
>>       void foo(float);
>> }
>>
>> void bar()
>> {
>>      S s;
>>      s.foo(1.0f);
>> }
>>
>> This is an error in C++:
>
> Yeah, and it must stay one for D overload sets too.
> In my pull request I always used the most accessible protection for the
> visibility of an overload set without removing the access check after
> overload resolution.
>
> http://dlang.org/hijack.html
> https://github.com/D-Programming-Language/dmd/pull/739
>
Let me clarify the HideModuleMembers pull request.

Symbols with private protection are hidden when searching through 
imported modules.
Symbols with package protection are hidden when searching through 
imported modules from a different package.
The visibility of an overload set is determined by it's most visible member.
Protection does NOT alter overload resolution, i.e. matching within a 
visible overload set.
Members of classes and structs are always visible.

This mainly fixes #1238, i.e. name collisions in non static imports.
http://d.puremagic.com/issues/show_bug.cgi?id=1238
December 28, 2012
Re: About Go, D module naming
On 12/24/12 6:20 AM, Jacob Carlborg wrote:
> On 2012-12-24 01:11, Walter Bright wrote:
>
>> 1. what access means at module scope
>> 2. at class scope
>> 3. at template mixin scope
>> 4. backwards compatibility
>> 5. overloading at each scope level and the interactions with access
>> 6. I'd also throw in getting rid of the "protected" access attribute
>> completely, as I've seen debate over that being a useless idea
>> 7. there's also some debate about what "package" should mean
>
> I also want to add:
>
> 8. Investigate the usefulness and possibility to combine multiple access
> attributes for more fine grained control, i.e. using "package" and
> "protected" on a single declaration

Has anyone started a DIP on this? Let's not let things scroll away from 
the institutional memory.

Andrei
December 28, 2012
Re: About Go, D module naming
On Sunday, 23 December 2012 at 19:55:15 UTC, Jonathan M Davis 
wrote:
> On Sunday, December 23, 2012 12:20:01 Tobias Pfaff wrote:
>> So the nice thing to have here would be a standardized 
>> interface to the
>> compiler, or even compiler as a library, with direct data 
>> access to this
>> kind of information.
>
> The plan is to have a lexer and parser for D in the standard 
> library, which
> would greatly simplify creating tools that did this sort of 
> thing. We'd
> probably already have the lexer portion (I was working on it 
> earlier this
> year), but I got insanely busy in real life. I'm hoping to get 
> back to it
> fairly soon here though.
>
> - Jonathan M Davis

I stopped all work on that and am waiting for it. I've done a 
crappy wrapper around some existing code on the subject. I'd love 
you if something come out of your project !
December 28, 2012
Re: About Go, D module naming
On Friday, December 28, 2012 16:12:47 Andrei Alexandrescu wrote:
> Has anyone started a DIP on this? Let's not let things scroll away from
> the institutional memory.

I've only gotten as far as thinking about it and leaving the relevant e-mails 
marked as unread.

- Jonathan M Davis
December 28, 2012
Re: About Go, D module naming
On 12/28/12 4:45 PM, Jonathan M Davis wrote:
> On Friday, December 28, 2012 16:12:47 Andrei Alexandrescu wrote:
>> Has anyone started a DIP on this? Let's not let things scroll away from
>> the institutional memory.
>
> I've only gotten as far as thinking about it and leaving the relevant e-mails
> marked as unread.

Well given your passion in the matter I'd say everybody is waiting on 
the proverbial poster (i.e. you) to deliver!

Andrei
December 28, 2012
Re: About Go, D module naming
On Friday, 28 December 2012 at 21:12:48 UTC, Andrei Alexandrescu 
wrote:
> On 12/24/12 6:20 AM, Jacob Carlborg wrote:
>> On 2012-12-24 01:11, Walter Bright wrote:
>>
>>> 1. what access means at module scope
>>> 2. at class scope
>>> 3. at template mixin scope
>>> 4. backwards compatibility
>>> 5. overloading at each scope level and the interactions with 
>>> access
>>> 6. I'd also throw in getting rid of the "protected" access 
>>> attribute
>>> completely, as I've seen debate over that being a useless idea
>>> 7. there's also some debate about what "package" should mean
>>
>> I also want to add:
>>
>> 8. Investigate the usefulness and possibility to combine 
>> multiple access
>> attributes for more fine grained control, i.e. using "package" 
>> and
>> "protected" on a single declaration
>
> Has anyone started a DIP on this? Let's not let things scroll 
> away from the institutional memory.
>
> Andrei

I feel like the issue is much deeper. I have no clue what the 
priorities are when resolving some identifiers, and the doc is 
unclear about it, and dmd is sometime inconsistent, or some other 
time don't implement the feature (for instance multiple alias 
this).

In a.b , b can be :
 1 a member of a.
 2 a member of an alias this of a.
 3 any recursion of the case 2.
 4 an UFCS function.
 5 an UFCS function using an alias this of a as argument.
 6 any recursion of 5.
 7 an imported symbol at scope level.
 8 repeat 4, 5 and 6 with that imported symbol.
 9 an imported symbol at module level.
 10 repeat 4, 5 and 6 with that imported symbol.
 11 all cases I have forgotten as I wrote that quickly.

It is unclear when they take priorities over each other and when 
they collide. Visibility is another variable to the equation, but 
in a first place, this is unclear without them.
December 28, 2012
Re: About Go, D module naming
On 12/22/2012 1:29 AM, "Jérôme M. Berger" wrote:
> Walter Bright wrote:
>> It's that way in C++ mainly so that it doesn't make the already complex
>> overloading system even more so. And in 25 years of working with C++,
>> I've never seen this make anyone's list of horrible things about C++.
>>
> 	Actually, it is *not* that way in C++ for "module-private"
> functions. I know that C++ doesn't have true "modules" and a
> fortiori true "module-private" functions (or types or variables),
> but the C++ equivalent of module-private is file static (or the
> anonymous namespace) and those do *not* make it into the overload
> set and cannot affect user code.

I was talking about inside struct/class scope.
December 30, 2012
Re: About Go, D module naming
On Friday, December 28, 2012 16:52:32 Andrei Alexandrescu wrote:
> On 12/28/12 4:45 PM, Jonathan M Davis wrote:
> > On Friday, December 28, 2012 16:12:47 Andrei Alexandrescu wrote:
> >> Has anyone started a DIP on this? Let's not let things scroll away from
> >> the institutional memory.
> > 
> > I've only gotten as far as thinking about it and leaving the relevant
> > e-mails marked as unread.
> 
> Well given your passion in the matter I'd say everybody is waiting on
> the proverbial poster (i.e. you) to deliver!

The wiki.dlang.org DIP page claims that it's only a placeholder page (until 
all of them are copied over?). So, should I put the new DIP in both places, or 
should I just put it on the new one in spite of the fact that it claims that 
it's a placeholder?

http://wiki.dlang.org/DIPs
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs

- Jonathan M Davis
January 27, 2013
Re: About Go, D module naming
On Monday, 24 December 2012 at 15:36:47 UTC, Jonathan M Davis 
wrote:
> I believe that C# did something similar. It would certainly 
> solve the question
> of package's virtuality quite nicely and wouldn't change any 
> existing code,
> just allow for those who want virtual package functions to have 
> them.
>

Stopping to conflate visibility with virtuality would solve it in 
a more simple way.
Next ›   Last »
7 8 9 10 11
Top | Discussion index | About this forum | D home