On Thu, 10 Mar 2005 11:58:22 +0000, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> Regan Heath wrote:
> <snip>
>> C:\Library\D\src\temp>dmd b a
>> b.d: module b a.g is private
>> b.d(7): function expected before (), not 'void'
>>  So, using a mixin, defines a scope, using a template doesn't.
>
> What's that to do with your snippet?

My first example, didn't use a mixin, and worked.  This snippet, used a mixin, and didn't work.  This snippet was more like your code than my first example.  I was trying to show the difference between mixin template usage and standard template usage. Which is, I believe, that a mixin creates a scope where it's used.

>>> But therein lies the question - when you use it as a mixin, is it in the  scope of the module where the template is defined, or the scope in which  it is used?
>>  Currently, a mixin creates a new scope.
>
> Then the point becomes: what is this new scope a subscope of?

I believe it's a subscope of the scope in which it's used, i.e. where type 'mixin'.

>>> I'd like to say a bit of both.
>>   Perhaps. Is there a problem with collision resolution? eg.
> <snip>
>> You can't modify the template to read b.g, cos 'a' does not know about  'b', nor should it.
>> So, it seems the only solution is to 'assume' writef(g) means the a.g, not  b.g.
>
> Good question.  FWIW I've just taken another look at the mixins page of the spec, and it seems to the effect that a mixin is a subscope of the scope where it's used.

That is how I understood it.

> It doesn't seem to address the issue of access rights though.

True. Perhaps it should be explicit about it all. i.e. "mixins create their own sub-scope within the scope there they are used, not where they are defined. This means they have private access to the module where they are used, not where they are defined" .. or something.

> <snip>
>>> http://www.digitalmars.com/d/pretod.html#mixins
>>>
>>> OK, so half of those differences are really about the syntactic  fragility of C preprocessor macros, but there are a few actual semantic  differences as I see it.
>>  The important one (in this case) seems to be: "Mixins create a scope,  macros do not."
>
> Similarly, classes create a scope.  So do functions.  And yet classes have no trouble accessing private members in their modules, and functions have no trouble accessing private members in their classes.

The question, as you said, is where does it create that scope. In the case of classes it's created where it's defined, in the case of mixins it's where it's used.

It seems it needs to be explicit about this behaviour in the docs.

> <snip>
>> Ahh.. yes, sort of like how in Java .. (bear with me I'm relatively new to  Java) I seem to recall something like:
>>  interface foo {}
>> class SimpleFoo implements foo {}
>>  You extend SimpleFoo, which provides the basic methods for you, and  conforms to the interface.
>
> But in Java you can't (directly at least) share implementation details between classes that implement an interface.

Not that implement the interface, no, but you can derive all the classes from SimpleFoo, which in effect contains the shared implementation details.

>> In D you'd go:
>>  interface IWindow {}
>> class ChildWindow : IWindow {
>>   mixin ..
>> }
>>  ..
>>  class MyWindow : ChildWindow {}
> <snip>
>
> At the moment I have
>
> class Window : WindowBase { ... }
> class FrameWindow : Window { ... }
> class MDIFrameWindow : FrameWindow { ... }
> class MDIClientPane : WindowBase { ... }
> template MDIChildWindow() { ... }
>
> The application window is an MDIFrameWindow, which frames an MDIClientPane (the standard Windows control that holds the child windows).  To create a child window class, one uses
>
> class ChildWindow : Window {
>      mixin MDIChildWindow;
>      ...
> }
>
> But I'm now thinking maybe I should predefine the ChildWindow and ChildFrameWindow classes, and have the lib user create subclasses of these.  I can think of a few other benefits to this approach....

Excellent.. so it seems it's a better approach all round.

Regan

Regan Heath wrote:
> On Thu, 10 Mar 2005 11:58:22 +0000, Stewart Gordon <smjg_1998@yahoo.com>  wrote:
<snip>
>> Good question.  FWIW I've just taken another look at the mixins page of the spec, and it seems to the effect that a mixin is a subscope of the scope where it's used.
> 
> That is how I understood it.

I guess we've come to an agreement on this then.

>> It doesn't seem to address the issue of access rights though.
> 
> True. Perhaps it should be explicit about it all. i.e. "mixins create  their own sub-scope within the scope there they are used, not where they are defined. This means they have private access to the module where they are used, not where they are defined" .. or something.
<snip>
> The question, as you said, is where does it create that scope. In the case of classes it's created where it's defined, in the case of mixins it's where it's used.
> 
> It seems it needs to be explicit about this behaviour in the docs.

Good idea.

<snip>
>> But in Java you can't (directly at least) share implementation details between classes that implement an interface.
> 
> Not that implement the interface, no, but you can derive all the classes from SimpleFoo, which in effect contains the shared implementation details.
<snip>

But not if the classes may already be derived from different classes. This is where mixins become useful - as a way of creating shared implementation details that may be applied to a variety of classes. Kind of like a makeshift form of multiple inheritance....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

On Fri, 11 Mar 2005 12:53:37 +0000, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> Regan Heath wrote:
>> On Thu, 10 Mar 2005 11:58:22 +0000, Stewart Gordon <smjg_1998@yahoo.com>  wrote:
> <snip>
>>> Good question.  FWIW I've just taken another look at the mixins page of the spec, and it seems to the effect that a mixin is a subscope of the scope where it's used.
>>  That is how I understood it.
>
> I guess we've come to an agreement on this then.

I'm not sure we disagreed to begin with :)

> <snip>
>>> But in Java you can't (directly at least) share implementation details between classes that implement an interface.
>>  Not that implement the interface, no, but you can derive all the classes from SimpleFoo, which in effect contains the shared implementation details.
> <snip>
>
> But not if the classes may already be derived from different classes. This is where mixins become useful - as a way of creating shared implementation details that may be applied to a variety of classes. Kind of like a makeshift form of multiple inheritance....

Indeed. Good point.

Regan