Simple way to get automatical getters/setters

[Alan Mimms]

I was reading the GridBagPanel code to see how Swing constraints can be built, when I realized that a significant amount of code clutter is created in such classes because even experienced Scala coders have to manually create getters and setters for fields. I know you can get this sort of thing "for free" for constructor parameters, but there are many fields that aren't constructor parameters in such classes, and the code to do this is time consuming and constitutes clutter.

https://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_1_final/src//swing/scala/swing/GridBagPanel.scala#L1

See those getters and setters in class Constraints?

Why couldn't the language include a mechanism to declare a var that does this automagically like class constructor parameters do? Something like "case def foo: Double" would be easy to write.

Or am I missing some feature that defines such things for me (and, apparently, so was the author of GridBagPanel.scala)?

Or am I missing some vital concern that this would not address?

Thanks for Scala! It is hugely better than anything else out there for my particular applications.

[Eugen Labun]

Hi Alan,

do you mean something like:

var weighty = forward to peer

instead of:

def weighty: Double = peer.weighty
def weighty_=(y: Double) { peer.weighty = y }

?

--
Eugen

[Alan Mimms]

I was just looking over GridBagPanel.scala again and I realized that it was actually forwarding to peer rather than directly accessing the var.

I can only say that 7:30am is not a great time to be posting questions...

Never mind.

Although maybe some sort of easy forwarding accessor mechanism would be a useful thing.

Sheepishly,

a

[Kevin Wright]

something like this? https://github.com/kevinwright/Autoproxy-Lite

[Eugen Labun]

On 2012-03-05 17:19, Alan Mimms wrote:
> I was just looking over GridBagPanel.scala again and I realized that it was actually forwarding to
> peer rather than directly accessing the var.
>
> I can only say that 7:30am is not a great time to be posting questions...
>
> Never mind.

No problem!

> /Although/ maybe some sort of easy forwarding accessor mechanism would be a useful thing.

I'm with you. But how to implement this?
Another view on the problem: var weighty can be seen as an alias for peer.weighty.

We are able to declare an alias for a type. Then why not to introduce an aliasing mechanism for
variables?

[Alan Mimms]

Yes, Kevin, that's a bit like what I'm talking about. This is wizardry beyond my existing skills; I'm going to study what you have done here soon. It looks useful in more ways than just this particular one.

Thanks!

a

On Monday, March 5, 2012 8:38:30 AM UTC-8, Kevin Wright wrote:

something like this? https://github.com/kevinwright/Autoproxy-Lite

[Tony Morris]

You want to look into regular asymmetric lenses. The variable in your use-case throws a furfy though.

I heard that lenses reinvented javabeans or something like that.

[Alan Mimms]

Thanks that looks like a lot to digest.

On Monday, March 5, 2012 2:10:38 PM UTC-8, Tony Morris wrote:

You want to look into regular asymmetric lenses. The variable in your use-case throws a furfy though.

I heard that lenses reinvented javabeans or something like that.

[Eric Kolotyluk]

This is slightly off topic - but

Don't ever use GridBagLayout in Swing - unless you have a high tolerance to pain, or you like writing abstruse code.

Use MigLayout instead, and avoid the pain, as well as the need for getters and setters.

Cheers, Eric

[Chris Marshall]

GridBagLayout is just fine and far less complicated than most people claim it is.

---

Date: Tue, 6 Mar 2012 20:57:53 -0800
From: eric.ko...@gmail.com
To: scala...@googlegroups.com
Subject: Re: [scala-user] Simple way to get automatical getters/setters

This is slightly off topic - but

Don't ever use GridBagLayout in Swing - unless you have a high tolerance to pain, or you like writing abstruse code.

Use MigLayout instead, and avoid the pain, as well as the need for getters and setters.

Cheers, Eric

.

[√iktor Ҡlang]

On Fri, Mar 16, 2012 at 3:33 PM, Chris Marshall <oxbow...@hotmail.com> wrote:

GridBagLayout is just fine and far less complicated than most people claim it is.

There's a rumor that the working name for GridBagLayout was DoucheBagLayout

 

---

Date: Tue, 6 Mar 2012 20:57:53 -0800
From: eric.ko...@gmail.com
To: scala...@googlegroups.com
Subject: Re: [scala-user] Simple way to get automatical getters/setters

This is slightly off topic - but

Don't ever use GridBagLayout in Swing - unless you have a high tolerance to pain, or you like writing abstruse code.

Use MigLayout instead, and avoid the pain, as well as the need for getters and setters.

Cheers, Eric

.

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Eric Kolotyluk]

<SoapBox>

I have spent endless hours trying to reverse engineer some abysmal GriefBagLayout people have twisted and tied into some wretched UI implementation and gone crazy trying to figure out what was wrong, only to end up having to re-implement the UI, usually in MigLayout.

I have spent endless hours trying to convince GriefBagLayout to perform what I thought were simple layouts, only to end up feeling stupid and inadequate. Since I have sworn off GriefBagLayout forever and switched to MigLayout my mental and emotional health have improved. For the most part MigLayout can replace most or all of the standard Java layout managers, and the resulting code is cleaner, more concise and more readable. Using GriefBagLayout is like coding in assembly language, while using MigLayout is like coding in Scala.

Sorry Chris, maybe you are a genius with GriefBagLayout, but I am not, and I have met dozens of other developers who hate GriefBagLayout as passionately as I do.

</SoapBox>

Cheers, Eric

[Chris Marshall]

I suspect there is someone out there right now on the Clojure mailing list or wherever saying the following:

"I have spent endless hours trying to reverse engineer some abysmal MigLayout people have twisted and tied into some wretched UI implementation and gone crazy trying to figure out what was wrong, only to end up having to re-implement the UI, usually in GridBagLayout "

I am not a "GridBagLayout genius". GridBagLayouts are easy to use. I strongly suspect that the programmers who ruined your days would have done so whatever layout mechanism they would have (presumably mis-) used. You get MigLayout and like it: great! Do I get MigLayout? Not really - why would I want layout information in a String? 

Chris

---

Date: Fri, 16 Mar 2012 08:03:11 -0700
From: eric.ko...@gmail.com
To: oxbow...@hotmail.com
CC: scala...@googlegroups.com
Subject: [scala-user] GriefBagLayout vs. MigLayout

[Erik Post]

Hi,

I can't watch this discussion unfold without mentioning the following godsend, which I discovered along with Scala, back in the day. It's called DesignGridLayout [1] by Jean-Francois Poilpret, and it's based on 'canonical grids'. Works especially great with a dash of Scala sprinkled on top. I personally don't like the unsafe string gobbledygook required for MigLayout.

Cheers,

Erik

[1] http://designgridlayout.java.net/grids.html

[Eric Kolotyluk]

This discussion should probably be in scala-debate :-)

On 2012-03-16 8:50 AM, Chris Marshall wrote:

I suspect there is someone out there right now on the Clojure mailing list or wherever saying the following:

"I have spent endless hours trying to reverse engineer some abysmal MigLayout people have twisted and tied into some wretched UI implementation and gone crazy trying to figure out what was wrong, only to end up having to re-implement the UI, usually in GridBagLayout "

In my experience it can be just as hard to figure out how to create layouts in MigLayout as GriefBagLayout when you are not familiar with MigLayout, but when you are finished with a MigLayout implementation it is rarely as twisted as the GriefBadLayout code I have seen and written myself.

I am not a "GridBagLayout genius". GridBagLayouts are easy to use. I strongly suspect that the programmers who ruined your days would have done so whatever layout mechanism they would have (presumably mis-) used. You get MigLayout and like it: great! Do I get MigLayout? Not really - why would I want layout information in a String?

To be sure I did not get MigLayout at first either. I tried to learn it several times and was not successful - possibly where you are now Chris. After seeing Mikael Grev give a presentation at JavaOne I was inspired to try again, and the presentation helped a lot. When I dug in and started using MigLayout at work I was surprised how much more productive I became at GUI design & implementation. It was not hard for me to convince my colleges at work either, especially since I could give them direct help with it. Overall I would say the productivity increase we have seen more than paid for that entire trip to JavaOne for me.

To be sure MigLayout does not conform to most of our notions about how layout should work (we generally have not been taught to think that way), but I have come to believe Mikael's insights and innovations are extremely effective. When I first learned to program with recursion I did not like it, I did not get it, but once I did get it I could not live without it because it is so much more powerful than only having iteration.

Recently I was writing some more GUI code, which I have not done in a while, and struggled again with MigLayout a little and was forced to go back to the reference materials and serendipitously discovered another MigLayout feature I had missed for years, but it simplified my code enormously. When I was finished I had about 6 lines of Java code that would have required easily 20 lines of GriefBagLayout, and the MigLayout code is trivial to read and understand (now that I discovered such an important and effective little feature).

In a larger sense I struggle with Scala the same way. I rebel at having to learn new concepts in Scala that I do not have to learn in Java, but after learning them I am rewarded with the satisfaction of knowing how to write more elegant code in Scala than I ever could in Java.

Cheers, Eric