[groovy-dev] Contributing a simple yet powerful symbol

[Czipperz]

I would like to contribute the '=>' symbol that sets the input value of a
method to a variable directly.

Bash(String => name) {

Into

Bash(String name) {\n this.name = name

Or it would allow a custom parameter name:

Bash(String n => name) {

Into

Bash(String n) {\n this.name = n

Is this possible and how would I start programming this? I use IntelliJ if
that matters




--
View this message in context: http://groovy.329449.n5.nabble.com/Contributing-a-simple-yet-powerful-symbol-tp5723371.html
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

since nobody else answered you yet.


When it comes to new language features I always look at the way we do
things atm and if the suggested syntax improves things noticable, given
a usage scenario for it. And if the syntax fits into the general style

Post by Czipperz
I would like to contribute the '=>' symbol that sets the input value of a
method to a variable directly.
Bash(String => name) {
Into
Bash(String name) {\n this.name = name

Normally current usage would be something like

class Bash {
String name
}
new Bash(name:"foo")

of course this uses a property and no field like your example, so the
two are not 100% equal. But I think for the usual cases they are equal
enough. Onyl if given those conditions I fail to see the big advantage
of this:

class Bash {
String name
Bash(String => name)
}
new Bash("foo")

Imho, in this case you don't save on loc, the "String => name" syntax is
alien to groovy (and frankly I don't like that style element in scala
either, only that there it is less alien

Post by Czipperz
Bash(String n => name) {
Into
Bash(String n) {\n this.name = n

the aliasing idea is interesting, but what would you do with the alias?
In the code you would have n to work with later on as well, but usually
you would have to do things before you assign the value to name.

To sum it up:

pro:
* could be used for aliasing (use case missing!)
* could be used in methods and constructors

cons:
* unusual syntax for Groovy
* in constructors not really much better than what we have for the
usual cases

Post by Czipperz
Is this possible and how would I start programming this? I use IntelliJ if
that matters

Possible are many things, the question is more if it makes sense. First
discussing such a suggestion and being able to defend it is important.
You have to make others be able to see the advantage of your suggestion,
even if that takes a bit time.

only after that you would start changing the groovy.g grammar file to
define new grammar rules for your suggestion, as well as maybe changes
to the ASt and different parts of the compiler. But that is all for
later. First the suggestion needs to be specified, must have use cases
and supporters. For what comes later we can help you by pointing you in
directions and where to look at.

bye blackdrag

[Czipperz]

For me, switching to Groovy was great because it auto generates the code that
isn't important: getters and setters. My code became more clean because they
don't have that extra code bogging them down. For me, it makes since to use
shortcuts as much as I can to cut down my programming.

If one of your main objections is that it looks too much like Scala (which I
didn't know had this type of syntax) then you probably shouldn't be
objecting. The characters `=>` are just as meeningfull as `:`. It could be
written as:

class Bash {
String name
Bash(String: name) {}
}
new Bash("foo")



Now onwards to my reasoning for this in the first place.

Post by Jochen Theodorou
Normally current usage would be something like
class Bash {
String name
}
new Bash(name:"foo")

As a person who writes lots of frameworks rather than end developer things,
it isn't super useful for me to have a blank constructor that the end user
can have inputs such as their name into. Many constructors I write look like
this
<https://github.com/czipperz/CLibrary/blob/master/src/io/czipperz/github/cLibrary/game/CView.groovy>
:

CView(CGameFrame displayOn, Rectangle bounds, int depth = 0) {
this.bounds = bounds
this.displayOn = displayOn
this.drawAllObjects = true
this.depth = depth
this.bufferDimension = new Dimension()
this.needDraw = true
}

If we had this framework (assuming the `:` symbol is used since that is what
normal Groovy uses for similar purposes):

CView(CGameFrame: displayOn, Rectangle: bounds, int: depth = 0) {
this.drawAllObjects = true
this.bufferDimension = new Dimension()
this.needDraw = true
}

This is much more useful to a developer that having the end user able to
specify variables and you are supposed to trust them to setup the class with
the right variables.



Here is the reasoning having any of this in the first place, taken from The
Biggest Problem in the Universe: Episode 21
<http://media.biggestproblemintheuniverse.com/wp-content/uploads/2014/10/Maddox_BPU_21.htm>

Post by Jochen Theodorou
every iPhone user is like, (silly voice) "Well, I wouldn't use it anyway.
I wouldn't use that feature anyway." And you know what? You don't have the
option to.
...
No one's saying you have to use it. But they're like "Well, I wouldn't use
it anyway." And they ALWAYS say that until they get the feature, and then
guess what? They're fucking using it.
...
And every single one of these idiots I argued with. I said "Hey man, you
can't install apps." And they were like (silly voice) "Well, we wouldn't
use that anyway! We would just use web apps!" And then of course, the next
model iPhone comes out and Apple's all about apps.

This is a bad analogy but the point is that you shouldn't reject features
that don't hurt anyone or conflict with anything before you use them. Try
writing two classes that are semi advanced with using this feature vs not
using this feature. If the developer can tell easily what this means, which
it should be, then it shouldn't be a problem for anyone to use.

The reason I was saying we could use the syntax:

void print(String textToBeInputtedToTheCBashThatWillBePrintedDirectly:
print) {}

So that when I'm in my IntelliJ and looking at how to invoke a method, I
don't have to stop in the middle of one of the popup windows that show up
with descriptions of the methods and figure out what the variable means,
what to input if I'm trying to make something up on the spot:

void print(String textToBePushedAsTheProperty: prop, String
textToBeInputtedBackIntoTestingCycle: line) {}

This may not be super useful but we might as well included for the same
reason that we might as well include removal batteries in phones. Why not
double the battery life for curtain consumers.



--
View this message in context: http://groovy.329449.n5.nabble.com/Contributing-a-simple-yet-powerful-symbol-tp5723371p5723381.html
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Milan Ardeshana]

Agree!

Post by Czipperz
For me, switching to Groovy was great because it auto generates the code that
isn't important: getters and setters. My code became more clean because they
don't have that extra code bogging them down. For me, it makes since to use
shortcuts as much as I can to cut down my programming.
If one of your main objections is that it looks too much like Scala (which I
didn't know had this type of syntax) then you probably shouldn't be
objecting. The characters `=>` are just as meeningfull as `:`. It could be
class Bash {
String name
Bash(String: name) {}
}
new Bash("foo")
Now onwards to my reasoning for this in the first place.

Post by Jochen Theodorou
Normally current usage would be something like
class Bash {
String name
}
new Bash(name:"foo")

As a person who writes lots of frameworks rather than end developer things,
it isn't super useful for me to have a blank constructor that the end user
can have inputs such as their name into. Many constructors I write look like
this
<
https://github.com/czipperz/CLibrary/blob/master/src/io/czipperz/github/cLibrary/game/CView.groovy
CView(CGameFrame displayOn, Rectangle bounds, int depth = 0) {
this.bounds = bounds
this.displayOn = displayOn
this.drawAllObjects = true
this.depth = depth
this.bufferDimension = new Dimension()
this.needDraw = true
}
If we had this framework (assuming the `:` symbol is used since that is what
CView(CGameFrame: displayOn, Rectangle: bounds, int: depth = 0) {
this.drawAllObjects = true
this.bufferDimension = new Dimension()
this.needDraw = true
}
This is much more useful to a developer that having the end user able to
specify variables and you are supposed to trust them to setup the class with
the right variables.
Here is the reasoning having any of this in the first place, taken from The
Biggest Problem in the Universe: Episode 21
<
http://media.biggestproblemintheuniverse.com/wp-content/uploads/2014/10/Maddox_BPU_21.htm

Post by Jochen Theodorou
every iPhone user is like, (silly voice) "Well, I wouldn't use it anyway.
I wouldn't use that feature anyway." And you know what? You don't have

the

Post by Jochen Theodorou
option to.
...
No one's saying you have to use it. But they're like "Well, I wouldn't

use

Post by Jochen Theodorou
it anyway." And they ALWAYS say that until they get the feature, and then
guess what? They're fucking using it.
...
And every single one of these idiots I argued with. I said "Hey man, you
can't install apps." And they were like (silly voice) "Well, we wouldn't
use that anyway! We would just use web apps!" And then of course, the

next

Post by Jochen Theodorou
model iPhone comes out and Apple's all about apps.

This is a bad analogy but the point is that you shouldn't reject features
that don't hurt anyone or conflict with anything before you use them. Try
writing two classes that are semi advanced with using this feature vs not
using this feature. If the developer can tell easily what this means, which
it should be, then it shouldn't be a problem for anyone to use.
print) {}
So that when I'm in my IntelliJ and looking at how to invoke a method, I
don't have to stop in the middle of one of the popup windows that show up
with descriptions of the methods and figure out what the variable means,
void print(String textToBePushedAsTheProperty: prop, String
textToBeInputtedBackIntoTestingCycle: line) {}
This may not be super useful but we might as well included for the same
reason that we might as well include removal batteries in phones. Why not
double the battery life for curtain consumers.
--
http://groovy.329449.n5.nabble.com/Contributing-a-simple-yet-powerful-symbol-tp5723371p5723381.html
Sent from the groovy - dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Am 17.04.2015 03:22, schrieb Czipperz:
[...]

Post by Jochen Theodorou
class Bash {
String name
Bash(String: name) {}
}
new Bash("foo")

and why do you want a type there?

Post by Jochen Theodorou
Many constructors I write look like
this
<https://github.com/czipperz/CLibrary/blob/master/src/io/czipperz/github/cLibrary/game/CView.groovy>
CView(CGameFrame displayOn, Rectangle bounds, int depth = 0) {
this.bounds = bounds
this.displayOn = displayOn
this.drawAllObjects = true
this.depth = depth
this.bufferDimension = new Dimension()
this.needDraw = true
}
If we had this framework (assuming the `:` symbol is used since that is what
CView(CGameFrame: displayOn, Rectangle: bounds, int: depth = 0) {
this.drawAllObjects = true
this.bufferDimension = new Dimension()
this.needDraw = true
}

I was first thinking about the tuple constructor annotation as
replacement for your idea, but I guess it does not really fit here.
Point taken. My mail before was not to reject the idea, it was to get
you telling me more use-cases ;)

[...]

Post by Jochen Theodorou
Here is the reasoning having any of this in the first place, taken from The
Biggest Problem in the Universe: Episode 21
<http://media.biggestproblemintheuniverse.com/wp-content/uploads/2014/10/Maddox_BPU_21.htm>

Post by Jochen Theodorou
every iPhone user is like, (silly voice) "Well, I wouldn't use it anyway.
I wouldn't use that feature anyway." And you know what? You don't have the
option to.
...
No one's saying you have to use it. But they're like "Well, I wouldn't use
it anyway." And they ALWAYS say that until they get the feature, and then
guess what? They're fucking using it.
...
And every single one of these idiots I argued with. I said "Hey man, you
can't install apps." And they were like (silly voice) "Well, we wouldn't
use that anyway! We would just use web apps!" And then of course, the next
model iPhone comes out and Apple's all about apps.

This is a bad analogy but the point is that you shouldn't reject features
that don't hurt anyone or conflict with anything before you use them. Try
writing two classes that are semi advanced with using this feature vs not
using this feature. If the developer can tell easily what this means, which
it should be, then it shouldn't be a problem for anyone to use.

The bad thing about having a device with a lot of features is not having
a lot of features. It is if daily stuff gets complicated, difficult to
understand and if the features don't integrate with each other. I am
talking about the usability. The device is usually something you alone
use, so it is your decision alone what features to use and what to
ignore, as long as the device can do what it was supposed to do.

A programming language differs, because you might not be the single
user. Somebody reading your code, should be able to understand it, even
if you use the rare features. That means we cannot make Groovy just a
mix of features. They have to fit together, maybe having logical bridges
in what the syntax means when it is similar to another syntax.

Anyway - I described how I decide for me, but I am not alone to decide.

Post by Jochen Theodorou
print) {}
So that when I'm in my IntelliJ and looking at how to invoke a method, I
don't have to stop in the middle of one of the popup windows that show up
with descriptions of the methods and figure out what the variable means,
void print(String textToBePushedAsTheProperty: prop, String
textToBeInputtedBackIntoTestingCycle: line) {}

well, I challenge you to use https://github.com/czipperz/CLibrary and
show me in which files there you would use that for methods and how. The
number of cases and a few examples would do. I looked through
https://github.com/czipperz/CLibrary/blob/master/src/io/czipperz/github/cLibrary/game/*
and did not find a single potential usage. I did see some parts with
room for improvement, like switch-case instead of if-else... but that is
of course not the point here.

Post by Jochen Theodorou
This may not be super useful but we might as well included for the same
reason that we might as well include removal batteries in phones. Why not
double the battery life for curtain consumers.

doubling battery life is super useful if your phone can work on battery
only for a few hours ;)

bye blackdrag