Partial classes

[Don Olmstead]

I've been spending some time with Web Components as of late and I'm enjoying them minus the generated code portion. So currently in the out directory you get something roughly like

library foo;

import 'dart:html' as autogenerated;

import 'dart:svg' as autogenerated_svg;

import 'package:web_ui/web_ui.dart' as autogenerated;

class FooComponent extends WebComponent { /** Generated content **/

....

/** Actual content **/

}

Then when you debug you have to use the copy in the out directory. This sucks workflow wise. I don't know how many times during the course of development I accidentaly modified the output file.

Having done work in WPF in C# it had a nice way of dealing with my code and the required under the hood code. This was thanks to partial classes, which allow you to have multiple compilation units for a single class. So if Dart did something similar there could be a file

foo_component.generated.dart which would contain all the generated code. Then I could work on foo_component.dart and use that for debugging and it would fit better with the workflow.

So what I'm wondering is if there are any technical issues preventing Dart from supporting partial classes.

[Kasper Lund]

Would mixins solve this nicely? Split the class in a mixin with the generated contents and a use of the mixin that adds the actual contents?

Cheers,
Kasper

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

[Dan Grove]

+web-ui

[Don Olmstead]

I honestly haven't tried any of the mixin support within Dart so I don't know if there are some limitations within the current implementation that would affect this. Is there something within the VM that would cause partial classes to be problematic? AKA couldn't Dart have support for both?

Just in my development I've had some pretty monster files that would benefit from partial classes in terms of organization. I don't really feel that mixins are necessarily the best answer for cases like that.

--
You received this message because you are subscribed to the Google Groups "Dart-Web-UI" group.
To post to this group, send email to web...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web-ui/?hl=en-US.
 
 

[Gilad Bracha]

I don't see a need for partial classes, given that we will have mixin support quite soon.  

On Mon, Jan 28, 2013 at 12:49 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

I honestly haven't tried any of the mixin support within Dart so I don't know if there are some limitations within the current implementation that would affect this.

Given that it's just being added now, it would be hard to have tried it yet :-)

 

Is there something within the VM that would cause partial classes to be problematic? AKA couldn't Dart have support for both?

Having both is not a good idea, because duplicate mechanisms burden everyone: the implementation grows, the learning curve for programmers grows, the design burden grows (which of several ways of doing things should one choose) and language features interact in unforeseeable ways. So keeping things small is a virtue. 

 

Just in my development I've had some pretty monster files that would benefit from partial classes in terms of organization.

You can break libraries into parts quite easily. If your individual classes are that big, I submit they should be split into smaller pieces.

--
Cheers, Gilad

[Don Olmstead]

Does a mixin have a way to access to the members of the class its being integrated with?

[Gilad Bracha]

On Mon, Jan 28, 2013 at 2:11 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

Does a mixin have a way to access to the members of the class its being integrated with?

Yes. 

Caveats:

a. Not static members.

b. The typechecker will warn about the instance members that are not defined in the mixin. You can add an implements clause for the class that is missing, which will eliminate the complaints from the call sites, but add complaints about unimplemented stuff.  This needs to be addressed as part of a more general problem of how to suppress type warnings (e.g., if you implement an interface using noSuchMethod).

--
Cheers, Gilad

[John Messerly]

On Mon, Jan 28, 2013 at 2:11 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

Does a mixin have a way to access to the members of the class its being integrated with?

I think so. If you declare something as abstract* on your mixin, it will be able to access the members of the class it is being mixed in to. It sounds a lot like the collections use cases.

(* you probably don't even need to declare it abstract, except to make static analysis happy. You should be able to call anything public on the class you were mixed in to.)

On Mon, Jan 28, 2013 at 1:13 PM, Gilad Bracha <gbr...@google.com> wrote:

I don't see a need for partial classes, given that we will have mixin support quite soon.  

Agreed. I think we can generate something much nicer once we have mixins. At least--I'd like to try it and see how it works out before asking for other features :)

On Mon, Jan 28, 2013 at 11:59 AM, Don Olmstead <don.j.o...@gmail.com> wrote:

Then when you debug you have to use the copy in the out directory. This sucks workflow wise. I don't know how many times during the course of development I accidentaly modified the output file.

We have a bug on web-ui/buildtool to make output files readonly. So accidental edits will be less of a problem.

Also, Siggi is working on source maps, so the debugger will be debugging the original source, not the generated source.

Cheers,

- John

[Gilad Bracha]

On Mon, Jan 28, 2013 at 2:28 PM, John Messerly <jmes...@google.com> wrote:

On Mon, Jan 28, 2013 at 2:11 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

Does a mixin have a way to access to the members of the class its being integrated with?

I think so. If you declare something as abstract* on your mixin, it will be able to access the members of the class it is being mixed in to. It sounds a lot like the collections use cases.

(* you probably don't even need to declare it abstract, except to make static analysis happy. You should be able to call anything public on the class you were mixed in to.)

Yes. I ignored that option in my response, because I assume that declaring those things again is tedious and to be avoided.

On Mon, Jan 28, 2013 at 1:13 PM, Gilad Bracha <gbr...@google.com> wrote:

I don't see a need for partial classes, given that we will have mixin support quite soon.  

Agreed. I think we can generate something much nicer once we have mixins. At least--I'd like to try it and see how it works out before asking for other features :)

On Mon, Jan 28, 2013 at 11:59 AM, Don Olmstead <don.j.o...@gmail.com> wrote:

Then when you debug you have to use the copy in the out directory. This sucks workflow wise. I don't know how many times during the course of development I accidentaly modified the output file.

We have a bug on web-ui/buildtool to make output files readonly. So accidental edits will be less of a problem.

Also, Siggi is working on source maps, so the debugger will be debugging the original source, not the generated source.

Cheers,

- John

--
Cheers, Gilad

[Don Olmstead]

Okay in that case it sounds like mixins could be used to emulate partial classes. I was under the assumption that a class being mixed in had no knowledge of what it was being combined with in. If that were the case then it couldn't be used. Is this functionality a day 1 thing with the mixin implementation or something further down the line Gilad? I vaguely recall the mixin implementation coming in phases from that proposal you did.

[Gilad Bracha]

On Mon, Jan 28, 2013 at 2:35 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

Okay in that case it sounds like mixins could be used to emulate partial classes. I was under the assumption that a class being mixed in had no knowledge of what it was being combined with in. If that were the case then it couldn't be used. Is this functionality a day 1 thing with the mixin implementation or something further down the line Gilad? I vaguely recall the mixin implementation coming in phases from that proposal you did.

The restrictions right now are:

mixed-in classes must inherit from Object directly.

They cannot contain super calls 

They cannot declare constructors of their own.

The latter two might still be an issue for you at the moment. I think this is all working in dart2js (but not yet in the VM).

--
Cheers, Gilad

[Don Olmstead]

From looking at the generated code from web-ui in my cases it doesn't look like those will be a problem, but John could probably give a better analysis there.

[Don Olmstead]

I take it back there is a super call in there.

[John Messerly]

Yeah, it's just a simple forwarding super call. I don't think we'll need it if we switch to mixins.

[John Messerly]

On Mon, Jan 28, 2013 at 2:46 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

From looking at the generated code from web-ui in my cases it doesn't look like those will be a problem, but John could probably give a better analysis there.

As soon as mixins are implement on both the VM and dart2js, Siggi or I will take a look. Promise :)

AFAIK, dart2js has mixins but VM does not have it yet.

[mythz]

Mixins aren't the same as C# partial classes since each class/file doesn't have to be coupled together, e.g:

    //File1.cs

    public partial class A { }

    //File2.cs

    public partial class A { }

They also have no restrictions, it's effectively a copy + paste of multiple file fragments together into 1 class definition then compiled as one. 

It's very little added complexity other than knowing what it does, i.e. copying + pasting is easy to explain :)

[John Messerly]

On Mon, Jan 28, 2013 at 3:01 PM, mythz <demis....@gmail.com> wrote:

Mixins aren't the same as C# partial classes since each class/file doesn't have to be coupled together, e.g:

    //File1.cs

    public partial class A { }

    //File2.cs

    public partial class A { }

They also have no restrictions, it's effectively a copy + paste of multiple file fragments together into 1 class definition then compiled as one. 

It's very little added complexity other than knowing what it does, i.e. copying + pasting is easy to explain :)

Right. But for web_ui mixins might work out just fine, or even better. We also have source maps in the works, which is an even more powerful (compared to partial classes) way of dealing with generated code and debugging.

- John

[Don Olmstead]

John if you have a Windows box lying around I'd take a look at how Visual Studio does WPF projects. Its integrated really nicely into everything despite having generated code going on under the hood. Might give some insight on how Dart Editor can present the whole Web Components thing. Overall I've been really happy with Web Components minus modifying the output one too many times ;)

--

[John Messerly]

On Mon, Jan 28, 2013 at 3:20 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

John if you have a Windows box lying around I'd take a look at how Visual Studio does WPF projects. Its integrated really nicely into everything despite having generated code going on under the hood. Might give some insight on how Dart Editor can present the whole Web Components thing. Overall I've been really happy with Web Components minus modifying the output one too many times ;)

Hehe. In a past life, I actually worked on Visual Studio (specifically the languages team). Needless to say, I'm familiar with how partial classes work :). They are indeed a nice solution to the generated code problem!

Personally, I'm really excited about mixins. It's a clear step beyond what C# offers. I think we'll be able to do some really cool things with them.

[Don Olmstead]

I usually assume that nobody uses Windows over at the Googleplex so my mistake there John.

Mixins sound like an interesting way to solve the problem so I'm looking forward to how they pan out. I still feel like partial classes solve a different problem than mixins, but I'm not in charge and my usual reaction with every addition to Dart is "make it like C#" ;)

[mezoni]

@Gilad Bracha

>> Having both is not a good idea, because duplicate mechanisms burden everyone:

This is not a duplicate mechanisms and having both is a good idea.

Mixins is as spices: salt, sugar.

More precisely it is the bricks. Building material.

Useful reusable blocks of code.

No more and no less.

Partial class are a whole as an single object.

One part may be auto generated.

Another part(s) may be handwritten.

But all parts are parts of the same class.

For the programmers all parts are one single class.

No restrictions.

>>the implementation grows,

Totally agree with you

>>the learning curve for programmers grows,

This is just an excuse to give up on the implementation.

Partial classes are easy to understand and good idea.