Arcane Jill <Arcane_member@pathlink.com> wrote in news:ce4ucm$1sqm$1@digitaldaemon.com:

> In article <Xns95337DF59537itsFarmer@63.105.9.61>, Farmer says...
> 
>>Why should D take the look-up rules of a legacy language called Java? Isn't it better to stick with the way modern languages like C++ and C# do it?
> 
> Not wishing to be /too/ pedantic, but C++ came before Java. So by that reckoning, C++ is "legacy" and Java is "modern".
> 
> Jill
> 
> 
Ops,
should read:
Forget about the rules of the archaic C++ language and the legacy language
Java. Better stick with modern languages: Smalltalk. :-)


Farmer.

Walter wrote:

> 
> The rule to apply is straightforward - look up the name, *then* apply
> overload resolution.
> 

I have read what /feels/ like thousands of posts in which you repeated that phrase. I am reluctant to add even another drop to this river but sadly it looks like I will be contributing.

In the context of resolving names within a nested scope the rule is simple and straightforward:

  1) Attempt overload resolution in the most specific scope
     first and if that fails then try the next more general
     scope... rinse... repeat.

How could it be simpler? You have said elsewhere that you are concerned making exceptions to this rule will result in an arcane language with arcane rules. That is a valid fear.

The very people asking for an exception are motivated by exactly the same fear. However they want to see this rule applied:

  2) A subclass inherits everything from its base class.
    (emphasis on the period.)

Surely you can understand that the following seems arcane:

  2) A subclass inherits everything from its base class,
 2a) except for the purpose of satisfying an interface and
 2b) except when overload resolution is satisfied by something
     in the subclass
  2bi) unless that something is 'alias'ed to bring a base class'
       name into scope.

Now consider the suggested amended 1):

  1) Attempt overload resolution in the most specific scope
     first and if that fails then try the next more general
     scope... rinse... repeat
 1a) except when finding inherited functions which should
     first be attempted without overload resolution.

It seems obvious to me that either the scope resolution rules or the inheritance rules are going to get more complicated. Unless someone else can find a less complicated way to amend 2) I do not believe it is wise to make inheritance overly complicated to keep scope resolution simple.

Of course this tendency is also influenced by the fact that I believe inheritance is more important than scope rules simply because it has more intuitive oomph which is really what makes the OO paradigm so useful.

It feels like the scope rules are more helpful to people from a C++ background than the general population who can inuit OO's inheritance rather easily. That is why I believe you have had to explain the simple scope rules over and over in the thread...

parabolis wrote:
> 
> It feels like the scope rules are more helpful to people from a C++ background than the general population who can inuit OO's inheritance rather easily. That is why I believe you have had to explain the simple scope rules over and over in the thread...

They are.  But as I pointed out in another post, D is different from C++ in that D method functions are virtual by default.  For this reason I think your argument is worth considering.  In C++ ther rules make sense because all default behavior is static.  In D the rules make less sense because most default behavior is dynamic.  The presence of interfaces and the lack of multiple inheritance just strengthens the argument in my mind.  Though I think it is important to note that the override issue that Regan has mentioned should be considered separately from this one.


Sean

Sean Kelly wrote:

> parabolis wrote:
> 
>>
>> It feels like the scope rules are more helpful to people from a C++ background than the general population who can inuit OO's inheritance rather easily. That is why I believe you have had to explain the simple scope rules over and over in the thread...
> 
> 
> They are.  But as I pointed out in another post, D is different from C++ in that D method functions are virtual by default.  For this reason I think your argument is worth considering.  In C++ ther rules make sense because all default behavior is static.  In D the rules make less sense because most default behavior is dynamic.  The presence of interfaces and the lack of multiple inheritance just strengthens the argument in my 

That is good to hear. I am by no means an avid C++ programmer mostly because I have not internalized what other C++ programmers have internalized and so I am rather cautious about advocating a suggestion for D that would be violently counter-intuitive to C++ programmers.

> mind.  Though I think it is important to note that the override issue that Regan has mentioned should be considered separately from this one.

Yes the two are seperate and it was probably bad form to include the interface issue in a post that deals mostly with the seperate issue of overriding. (The post was actually about overriding and not interfaces)

However I felt I had to include the interface issue to illustrate the ways in which D is already tending towards arcane as far exceptions to the inheritance go.