On Fri, 27 May 2011 09:43:39 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2011-05-27 14:08, Steven Schveighoffer wrote:

>> I may see why you see so many cases -- dwt was likely ran through a java
>> to d converter, and such converters often add unnecessary lines, because
>> it is easier to do that than to examine each individual case.
>
> DWT is manually ported from Java. A automatic port was tried and it didn't workout that well, too much of the Java standard library needed to be reimplemented in D. The port tries to stay as close to the original code base as possible to ease merging future versions of SWT and to minimize porting bugs.
>

Why is this comment in the file given?

/* language convertion www.dsource.org/project/tioport */

Regardless of whether this was a manual port or not, the profuse aliasing is unnecessary, and does not provide a valid use case for the proposal.

-Steve

On 5/27/11 1:34 AM, Matthew Ong wrote:
> Hi All,
>
> Currently within D, to make use of a parent class method you have to do:
> class Parent{
> void methodA(int x){...}
> }
>
> class Child : Parent{
> // I understand that it has to do with preventing accidental hijacking
> alias Parent.methodA methodA;
> void methodA(long x){...}
> }
>
> void main(string[]){
> Child obj=new Child();
> obj.methodA(1); // expecting to call Child.methodA but calling
> Parent.methodA;
> }
>
> and also from this URL.
> http://www.digitalmars.com/d/2.0/function.html
> If, through implicit conversions to the base class, those other
> functions do get called, an std.HiddenFuncError exception is raised.

I can't believe this has fallen off the radar.

There should be no std.HiddenFuncError. Such errors must ALL be detected during compilation.


Andrei

On Fri, 27 May 2011 10:10:25 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 5/27/11 1:34 AM, Matthew Ong wrote:
>> Hi All,
>>
>> Currently within D, to make use of a parent class method you have to do:
>> class Parent{
>> void methodA(int x){...}
>> }
>>
>> class Child : Parent{
>> // I understand that it has to do with preventing accidental hijacking
>> alias Parent.methodA methodA;
>> void methodA(long x){...}
>> }
>>
>> void main(string[]){
>> Child obj=new Child();
>> obj.methodA(1); // expecting to call Child.methodA but calling
>> Parent.methodA;
>> }
>>
>> and also from this URL.
>> http://www.digitalmars.com/d/2.0/function.html
>> If, through implicit conversions to the base class, those other
>> functions do get called, an std.HiddenFuncError exception is raised.
>
> I can't believe this has fallen off the radar.
>
> There should be no std.HiddenFuncError. Such errors must ALL be detected during compilation.

You have three options:

1. keep the base implementation in place.  If someone casts to the base class, and calls the hidden function, it just works.
2. force the user to override *all* overloads of the base, or alias them in.
3. Throw the hidden function error.

1 is how D used to be.  I think Walter has some good case for why it is undesirable.
2 is just annoying.  Either you will just alias the base functions (resulting in possible hijacking) or you will implement stub functions that throw an exception.  If you want to go this route, I'd rather just have default aliasing of base functions.

2 is the only way to have a "compile" error.  It is impossible to statically check if a function using a base class is actually using a derived class that hides the function being called.  That is, you can only statically disallow the compilation of the derived class, not the hidden function call.

Personally, I think the current implementation (item 3) is the least annoying.

-Steve

On 5/27/2011 9:37 PM, Jacob Carlborg wrote:
> On 2011-05-27 13:42, Matthew Ong wrote:
>> On 5/27/2011 7:08 PM, Steven Schveighoffer wrote:
>Maybe you are not doing something correctly, you shouldn't need this
feature all the time.
Not me, others that has coded the dwt and I suspect other code in
dsource where they tries to mimic Java Library and perhaps C# also.
>
> DWT is a direct port of the Java library SWT and it tries to stay as
> close to the original code base as possible to easy merges of future
> release of SWT.
No problem.I have not worked too much with SWT but people from development world told me they really do not like Swing. Yes. I agree
because of the heavy/deep tree inheritance/too much manual copy/paste/undo sort handling. Different topic.

>DWT is manually ported from Java. A automatic port was tried and it >didn't workout that well, too much of the Java standard library needed >to be reimplemented in D.
Yes. I notice that and notice that the language converter does
not work that well because of the semantics of differences in the languages. Not impossible, but too heavy. Unless something like JRuby(JVM) and also IronRuby(.NET) is done and made use of the existing script engine extensions with existing API libray.

> When coding my own projects (projects I've written from scratch and not
> ported from other languages) it's a feature I rarely use, don't know if
> I ever have used it.
Actually from scratch is NOT a good approach and migration approach. How do you
justify this to business management people or to your client? There are also your
learning cycle time.

Using Java well know Model-View-Controller as a simple model as a discussion. See:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Model= Business Data/IO/Persistance storage
Controller= Business Logic and where transaction code are done.
View= GUI/Web/Webservices(I am aware webservice is not a view)/Console.
Interconnection =  how all the MVC are interacting with each other. Those arrow in the diagram top right.

Model and Controller typically are similar if not identical across different languages and platform. Most people would just do as much POJO(Plain Old Java Object) as possible here.

However when it comes to the View and Interconnection...Those typically changed when moving into different platform. Unless there is someone that port them. Nothing much can be done here.

>it's a feature I rarely use, don't know if I ever have used it.
Because of many years of object-relational database management system (ORDBMS). Most Database table even the flat one like Mysql are design with this concept in mind. Hence, the Model and Controller will have
plenty of inheritance tree and mutually dependent code. That would mean
alias would be used.

If porting SWT has already such syntax and scatted aliases, that would be the burden that coder would have to take on, may I stress, could have been taken over my compiler with new sets of keyword.


-- 
Matthew Ong
email: ongbp@yahoo.com

On 5/27/11 9:26 AM, Steven Schveighoffer wrote:
> On Fri, 27 May 2011 10:10:25 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 5/27/11 1:34 AM, Matthew Ong wrote:
>>> Hi All,
>>>
>>> Currently within D, to make use of a parent class method you have to do:
>>> class Parent{
>>> void methodA(int x){...}
>>> }
>>>
>>> class Child : Parent{
>>> // I understand that it has to do with preventing accidental hijacking
>>> alias Parent.methodA methodA;
>>> void methodA(long x){...}
>>> }
>>>
>>> void main(string[]){
>>> Child obj=new Child();
>>> obj.methodA(1); // expecting to call Child.methodA but calling
>>> Parent.methodA;
>>> }
>>>
>>> and also from this URL.
>>> http://www.digitalmars.com/d/2.0/function.html
>>> If, through implicit conversions to the base class, those other
>>> functions do get called, an std.HiddenFuncError exception is raised.
>>
>> I can't believe this has fallen off the radar.
>>
>> There should be no std.HiddenFuncError. Such errors must ALL be
>> detected during compilation.
>
> You have three options:
>
> 1. keep the base implementation in place. If someone casts to the base
> class, and calls the hidden function, it just works.
> 2. force the user to override *all* overloads of the base, or alias them
> in.
> 3. Throw the hidden function error.

4. Statically disallow overloaded overridable methods when the parameters of one automatically convert to the parameters of another.

> 1 is how D used to be. I think Walter has some good case for why it is
> undesirable.
> 2 is just annoying. Either you will just alias the base functions
> (resulting in possible hijacking) or you will implement stub functions
> that throw an exception. If you want to go this route, I'd rather just
> have default aliasing of base functions.
>
> 2 is the only way to have a "compile" error. It is impossible to
> statically check if a function using a base class is actually using a
> derived class that hides the function being called. That is, you can
> only statically disallow the compilation of the derived class, not the
> hidden function call.
>
> Personally, I think the current implementation (item 3) is the least
> annoying.
>
> -Steve

It is completely against the spirit of the language to decide that a call is resolved to an invalid method during runtime. There is no other feature remotely related to hiddenfunc.

A couple of years ago, Walter gave a talk on hijacking to NWCPP. It all went well until HiddenFunc, at which point Walter's assertion that the way out was by throwing an exception was hotly debated. Several people suggested alternative, of whom one proposed (4) above. Everybody agreed it's a good solution, and Walter had the presence of mind and humility to acknowledge that solution and to promise to look into implementing it. Unfortunately, that event was forgotten... until now.


Andrei

On Fri, 27 May 2011 10:54:14 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> It is completely against the spirit of the language to decide that a call is resolved to an invalid method during runtime. There is no other feature remotely related to hiddenfunc.
>
> A couple of years ago, Walter gave a talk on hijacking to NWCPP. It all went well until HiddenFunc, at which point Walter's assertion that the way out was by throwing an exception was hotly debated. Several people suggested alternative, of whom one proposed (4) above. Everybody agreed it's a good solution, and Walter had the presence of mind and humility to acknowledge that solution and to promise to look into implementing it. Unfortunately, that event was forgotten... until now.

I just tried it out.  If one implements an overload that is not contentious (for example, between int and string), no hidden func error is thrown.  So indeed the compiler has a notion of when a function would be hijacked.

I thought HiddenFuncError was thrown whenever you called any overloaded base method.  So I agree with you, this needs to be fixed.  Is there a bugzilla on it, or should we file one?  Let's not lose it again.

-Steve

On 5/27/11 10:04 AM, Steven Schveighoffer wrote:
> On Fri, 27 May 2011 10:54:14 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> It is completely against the spirit of the language to decide that a
>> call is resolved to an invalid method during runtime. There is no
>> other feature remotely related to hiddenfunc.
>>
>> A couple of years ago, Walter gave a talk on hijacking to NWCPP. It
>> all went well until HiddenFunc, at which point Walter's assertion that
>> the way out was by throwing an exception was hotly debated. Several
>> people suggested alternative, of whom one proposed (4) above.
>> Everybody agreed it's a good solution, and Walter had the presence of
>> mind and humility to acknowledge that solution and to promise to look
>> into implementing it. Unfortunately, that event was forgotten... until
>> now.
>
> I just tried it out. If one implements an overload that is not
> contentious (for example, between int and string), no hidden func error
> is thrown. So indeed the compiler has a notion of when a function would
> be hijacked.
>
> I thought HiddenFuncError was thrown whenever you called any overloaded
> base method. So I agree with you, this needs to be fixed. Is there a
> bugzilla on it, or should we file one? Let's not lose it again.
>
> -Steve

Matthew's example fixed is this:

class Parent{
    void methodA(int x){}
}

class Child : Parent{
    //alias Parent.methodA methodA;
    void methodA(long x){}
}

void main(string[]){
    Parent obj = new Child();
    obj.methodA(1);
}

The program throws with the alias commented out, doesn't throw with the alias. The desired behavior is to enforce three things: (a) "override" must be required everywhere overriding takes place (no warning, no debug mode etc); (b) if a class introduces a method with parameter types covariant with those of a homonym base method, it must introduce all overloads of that name (via alias or overriding); (c) if a class introduces two overloaded AND overridable methods, those must NOT have covariant parameters.

(a) makes sure no undue overriding is ever present, (b) takes care of this example, and (c) takes care of the HiddenFunc examples given online at http://www.digitalmars.com/d/2.0/function.html.

If you find the time, please make a bug report out of it and insert a link to this discussion in the report.


Thanks much,

Andrei

> A couple of years ago, Walter gave a talk on hijacking to NWCPP. It all
> went well until HiddenFunc, at which point Walter's assertion that the
> way out was by throwing an exception was hotly debated. Several people
> suggested alternative, of whom one proposed (4) above. Everybody agreed
> it's a good solution, and Walter had the presence of mind and humility
> to acknowledge that solution and to promise to look into implementing
> it. Unfortunately, that event was forgotten... until now.
>
>
> Andrei

Andrei, there was a discussion about it here on this NG too. I too think that (4) is definitely the best solution. At least that is what I would like D2 to do...

On 5/27/2011 10:10 PM, Andrei Alexandrescu wrote:
> On 5/27/11 1:34 AM, Matthew Ong wrote:
>> Hi All,
At least not using foo and bar, I am able to understand some of that is being discussed here. Thank you all.

>2 is just annoying.
For the sake of backward compatibility, keep that machination.

How about the inheritall and nooverload pair? Or something like that, but different keyword or keyword pair. Could that be a way out of that
state of annoyance and counter the spirit of inheritance.

I am trying to show something like include-all/exclude-some filter like within a automatic list selections. But *please* make it easy to use and readable.

Suggestions?

-- 
Matthew Ong
email: ongbp@yahoo.com

On 5/27/11 1:06 PM, Dejan Lekic wrote:
>> A couple of years ago, Walter gave a talk on hijacking to NWCPP. It all
>> went well until HiddenFunc, at which point Walter's assertion that the
>> way out was by throwing an exception was hotly debated. Several people
>> suggested alternative, of whom one proposed (4) above. Everybody agreed
>> it's a good solution, and Walter had the presence of mind and humility
>> to acknowledge that solution and to promise to look into implementing
>> it. Unfortunately, that event was forgotten... until now.
>>
>>
>> Andrei
>
> Andrei, there was a discussion about it here on this NG too. I too think
> that (4) is definitely the best solution. At least that is what I would
> like D2 to do...

Just talked to Walter - he did implement something similar that eliminates HiddenFunc, just only with -w. I ran a couple of tests and I find the behavior reasonable. (He does require introducing all overloads in derived classes, which is more permissive than what I had in mind but still eliminates HiddenFunc.)

This is perhaps a good time to move these two -w features into the flag-free compiler: requiring override and detecting hidden functions during compilation.


Andrei