Proposal for Property Accessors

[BGB]

On 1/6/2013 6:52 AM, Noctarius wrote:
> 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".

yep.
admittedly, in the past, I had more DSLs, but my main script language 
ended up eating up a lot of their roles.

it is like, the value of having a scripting language specifically for 
being a graphing calculator.
later on, my main scripting language largely took over the calculator 
role, despite not getting around to the "graphing calculator" part.

other notations are more specialized, but it is debatable to call them 
languages.
one example works more like a timer-and-event driven batch script, but 
with the ability to include bits of script code for more complex tasks.
thus far, its role has mostly been for doing simple procedural animations.


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

yep.

I think it is tradeoffs...

for example, admittedly, I write actually the bulk of my code in C, but 
don't actually see C as the "one true language that solves everyone's 
problems", and there are many reasons for it not to be such a language, 
but OTOH, sometimes it isn't worth the level of criticisms and general 
condemnation people often give it either.

although, the form I often use it in is a tool augmented amalgam almost 
bordering on Objective-C levels (just with less blatant nasty-looking 
syntax extensions), but either way...


decided to leave out a big long section of relative tradeoffs between C 
/ Java / C++ / C#.

but, yeah, it being tradeoffs is the main thing. no clear winner, no 
clear loser.
if a person uses all 4, then it seems a lot less like a "one language to 
rule them all" situation.


can't really comment much on Scala, as personally I find it a little 
strange looking and otherwise have no real experience with it.


> 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) -> { ... }
> }

could work, though personally I personally still find it slightly 
questionable.
the issue in this case is more that the syntax is "potentially 
misleading", depending on how the properties are implemented.

basically, it is sort of a "things should look like what they do" 
assertion, or at least "not look like what they don't do".

granted, yes, in this case, it is a minor issue, and could probably be 
ignored (since there is no other reasonable way to interpret it).


granted, many of the languages which use the get/set keywords, treat 
them as "contextual keywords", which basically means that they are only 
really recognized in certain situations (such as in property 
declarations). in many cases, contextual keywords can avoid the same 
sorts of damage to existing code as global keywords.


for example, a person can write:
public int get() { ... }

without the parser interpreting it as anything special (because 
contextual keywords may still be used as identifiers).


whereas:
public int color {
     get { ... }
}

can be handled, because the body of a property declaration is the 
context in which the 'get' keyword has special meaning.

likewise, for the other examples where get/set were used, it was because 
these were cases where the construction would not have otherwise been valid:
public int get color() { ... }

one can raise the question:
is there any way to parse this apart from being a property method?...



granted, some other languages, like C, have spent the last several 
language generations adding new keywords in the form of "_Whatever", 
under the general premise that "__whatever" and "_Whatever" are 
basically reserved for subsequent extension (and "__whatever" is more 
typically used for compiler-specific extensions, mostly leaving 
"_Whatever" for core language extensions).

like:
y = _Generic(x, int: foo_int(x), float: foo_float(x), double: 
foo_double(x));

as well as:
_Thread_local int x;
_Atomic int y;
...

with some macros like:
#define complex _Complex

to allow things like:
complex double d;


as well as there being things like:
__try {
...
}__catch(...)
{
...
}


and, as well, a specific compiler implementation could very well do 
something like this:
#include <classoop.h>

public dynamic class Bar extends Foo
{
     ...
};

where classoop.h might be something like:
#define public __public
#define class __class
...
#define new __new


so, it isn't necessarily like "no new keywords" needs to be some sort of 
impassable roadblock either.

just, a person may then be left making tradeoffs about how portable 
their code is going to be.


or such...