Proposal for Property Accessors

[Noctarius]

Am 06.01.2013 11:35, schrieb BGB:
> On 1/6/2013 3:19 AM, Noctarius wrote:
>> Am 06.01.2013 00:44, schrieb John Rose:
>>> On Jan 5, 2013, at 12:03 PM, Remi Forax wrote:
>>> 
>>>> I think I prefer a more general mechanism that ask javac
>>>> to replace all access to fields (or methods) for a given
>>>> class, insert an invokedynamic instead and let you
>>>> specifies the bootstrap method in Java code.
>>>> 
>>>> With that, you have properties, proxy, interceptor, AOP,
>>>> and with a little effort method_not_found.
>>> I have a pet name for that, Ninja = "Ninja Is Not Java 
>>> Anymore".
>>> 
>>> The Scala people have a similar project to virtualize the 
>>> language, and it is likely IMO to be a useful exercise, at 
>>> least in their world.  By virtualizing most or all
>>> language constructs, you can experiment with DSLs at very
>>> low cost.
>>> 
>> I don't want to go that far but it seems that there are
>> different opinions around that :-)
> 
> DSLs can be useful and fun though, like although a DSL probably
> isn't going to take over the world, or even all that often
> develop much of a user-base, it can at least give a space for
> experimentation and trying out ideas, without necessarily
> burdening (or being burdened by) all that is involved in
> serious larger-scale language development.
> 
> for example, in an a larger-scale language, changes have to be
> weighted carefully. like, what impacts might there be? does
> this risk breaking existing code? how will the community react?
> ... a person may well end up essentially being stuck with any
> early design-flaws as well, since they can't change them
> without potentially breaking something (and things become a big
> issue, like whether or not a language can safely add a new 
> keyword without breaking some code, somewhere, which uses it as
> an identifier, ...).
> 
> whereas, for a smaller scale DSL, code breaking is "no big
> deal", just a "cost of doing business".
> 
> not that it really does much good to try to be weird for sake
> of being weird, or break things for the hell of it. it may be a
> matter of "how much niche is in good taste" as well.
> 
> 
> granted, many language designers often seem to approach things
> with a kind of a "I am going to design this language or VM and
> take over the world with it", or "do it right where everyone
> else has done it wrong", or whatever...
> 
> while I believe in trying to have a fairly solid design (and
> trying to distill out the good parts of what all exists, ...),
> "taking over the world" or "trying to make everything right"
> don't really seem like big priorities.
> 
> so, there is some merit to existing in the land of small-scale
> DSLs...
> 
> 
> granted, a person can debate things, like what counts as "small
> scale", ... but alas...
> 
> like, there this funny area, where a language is bigger than a
> "toy language", and maybe has a slightly bulky implementation,
> but one can observe that it is still fairly small and
> insignificant if compared with common "industrial strength"
> languages.
> 
> a person may also deal with some amount of other people hating
> on whatever they are working on (one person objecting to "blub
> curly brace language", another objecting to "weird
> insignificant niche language"), others being condescending, and
> most everyone else doesn't give a crap.
> 
> easier just to be like "I am doing my own thing, how it makes
> sense to me and for what I am doing" and "who knows what the
> future holds? this is what I have right now". everyone else can
> take it or leave it.
> 
> like, a person can just do whatever, and even if it all turns
> out to be pointless, so be it...
> 
> and, OTOH, for a specialized DSL, why should it even really
> matter?...
> 
> 
> such is life in a way though...
> 

Yeah I think you're right and I made up lot's of DSLs the last
years all for their special purposes like automate generation of
value objects and serialization code and I totally agree with
"large-scale language changes must be considered".

I know most people think that the development of the Java language
is clumsy and slow but I like the sophisticated development.
Scala, for a long time, changed things from version to version
that needed to change a lot of the existing code which is not good
for enterprise systems (at least it is better now but still happens).

Also I see your point in not introducing a new keyword and I
forgot about the problems with introducing the keyword "enum" so
maybe we could extend the field syntax which would give us the
chance to make property accessors not only public but protected
like the following example:

public int foo {
  () -> { ... }
}
protected float bar {
  (value) -> { ... }
}

Chris

> 
>>> — John
>>> 
>>> 
>>> _______________________________________________ mlvm-dev 
>>> mailing list mlvm-dev at openjdk.java.net 
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> 
>> _______________________________________________ mlvm-dev
>> mailing list mlvm-dev at openjdk.java.net 
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________ mlvm-dev
> mailing list mlvm-dev at openjdk.java.net 
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>