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

> 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.

I think maybe this is a good thing for a bug report :)

I'll make one.

-Steve

On 2011-05-27 16:09, Steven Schveighoffer wrote:
> 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

I have no idea. The major part of DWT is manually ported, as far as I know. In this case it seems that not all of the aliases are necessary. But in general, in DWT, we want D to behave as Java, to ease porting. Just for the record, I'm not trying to argument for either anyone's side here, I'm just trying to correct facts about DWT that was incorrect. And apparently I was incorrect as well :)

-- 
/Jacob Carlborg

On 2011-05-27 16:38, Matthew Ong wrote:
> 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.

Of course, from "scratch" can be interpreted in different ways. I use the standard library and other libraries I need. But often when developing tools for D one can't use already existing tools because they don't support D or, in my opinion, aren't good enough. BWT, I don't have to justify my own private projects to anyone. One last thing: what's wrong with developing something from scratch just for the fun of it or for learning something from it :)

> 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.

I'm working with the MVC design pattern every day at work (Ruby on Rails).

>  >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.

As I said above: I'm using the MVC design pattern every day at work with Ruby on Rails which has, in my opinion, a great ORM library. It's not very often I create a class hierarchy of the models. Bacially the only hierarchy that exists is inheriting form the framework classes but when separating the framework from the user code there's basically no hierarchy in the user code.

> 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.

I can tell you this: after porting (almost) the whole SWT Mac OS X version to D I haven't seen this as a problem. Just inserting a few aliases and the problem is solved.

-- 
/Jacob Carlborg

On 2011-05-27 12:27, Jacob Carlborg wrote:
> On 2011-05-27 16:38, Matthew Ong wrote:
> > On 5/27/2011 9:37 PM, Jacob Carlborg wrote:
> >> 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.
> 
> Of course, from "scratch" can be interpreted in different ways. I use the standard library and other libraries I need. But often when developing tools for D one can't use already existing tools because they don't support D or, in my opinion, aren't good enough. BWT, I don't have to justify my own private projects to anyone. One last thing: what's wrong with developing something from scratch just for the fun of it or for learning something from it :)

Whether reimplementing from scratch or doing a more direct port makes more sense depends entirely on what you're doing. And when it's a personal project that you're doing for fun, it's that much more subjective than it would be when working on a project for work. It's definitely best to use as much knowledge as can be gained from the original code as best as possible when porting it to another language, but whether the actual code should be directly ported or just the basic ideas is very much dependent on the code and the situation. Sometimes it would be just plain stupid to rewrite the code, and in others, directly porting it would be a bad move.

I recently started on a port of Haskell's Parsec library to D, since I think that it's an absolutely fantastic parsing library. And being as how the original library is in Haskell (which you're _definitely_ not going to port directly to D) and how I wouldn't necessarily want to use whatever the original license is, it just plain makes more sense to take the basic ideas (and to some extent API) of the original and create a D version that applies those. Porting the code directly would make no sense. With something like DWT on the other hand, doing a direct port and thus minimizing the effort of porting changes to it later would make a lot more sense (particularly since Java is a lot closer to D than Haskell). But whether "writing it from scratch" or not is the best choice depends very much on the code, your situation, and your goals for the project. It's not a black and white choice.

- Jonathan M Davis