Proposal for Property Accessors

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


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