private string someStringValue;
public string SomeString
{
get
{
return someStringValue;
}
set
{
someStringValue = value;
DoTextChangedCallback();
}
}
It's funny in another thread discussing an interview problem, I posted an efficient solution and the person thought I was posting pseudo-code! Such a clean and clear language.
I wish PHP had property getters and setters instead of the "magical do-it-all" __get() and __set(). You're stuck with a massive switch block pivoting on the passed-in property name. Not to mention validating the given property name exists. It's ridiculous.
The syntax isn't as clear but TextChanged is an event that's fired when the text is changed which you are subscribing to. You can hook anything into that. When it calls it it sends a sender (in this case the textBox that was updated) and whatever eventArguments are appropriate. The => is just the syntax indicating a lambda so it's an inline way of dynamically generating a nameless version of the method:
And now you just confirmed that you didn't even read through the linked post.
OP posts a link specific to a JS library workaround for managing client-side browser-quirk-related DOM interactions as part of facilitating data transport and you derail by posting server-side C# which makes the assumption that browser quirks are automagically already handled for you.
There are no "browser quirks" here. The jquery code is functioning as designed and intended.
What I was initially pointing out was just the god awful syntax of javascript which becomes rapidly self obfuscating on projects any reasonably degree of complexity. But we could go beyond that to hit on what you're saying. The interaction between javascript, HTML, and the user is plainly terrible, but there is literally 0 reason for this to be the case. Your comment regarding my code doesn't even make any sense. There is 0 relevance to the code I'm showing whether it's executed client, server, or some mixture in between, at least not in an app.
And this is comparing apples to apples. HTML and javascript were never designed for what they do today, but continue to exist largely because they've become so ingrained that moving on from them would be difficult. Imagine instead we used a standard basic (limited instruction set) byte code in a natively stateful system. You could improve security, performance, flexibility, developer productivity, and more overnight by orders of magnitudes. The tie-in attempts to do this such as java-apps have fared poorly not only since they were again hamstrung by being tie-ins instead of replacements, but also because they were unilateral efforts. That not only means relatively poor implementations as one company was left to release virtual machines for every single enduser platform, but also limited receptivity. Have Microsoft, Google, Firefox, and the other big players work to develop the standard and leave implementation to browsers and perhaps even more ideally - operating systems.
I mean doesn't it ever occur to anybody else that the current state of HTML+scripts is shockingly reminiscent of early programming languages like COBOL? It was designed by people who tried to solve a lot of problems but could never have imagined what the future would hold. And at first the solution was to keep trying to tack more things onto it, but in the end a complete reboot often comes with a short term productivity loss but a longterm exponential gains, and I think our web interface is long due a reboot.
14 comments
3 u/rwbj 18 Jun 2016 19:52
Javascript makes me shudder.. Compare that to:
It's funny in another thread discussing an interview problem, I posted an efficient solution and the person thought I was posting pseudo-code! Such a clean and clear language.
1 u/new_name 18 Jun 2016 21:41
If that's valid code, I want to know what language it is.
0 u/something_went_wrong 19 Jun 2016 04:10
I wish PHP had property getters and setters instead of the "magical do-it-all" __get() and __set(). You're stuck with a massive switch block pivoting on the passed-in property name. Not to mention validating the given property name exists. It's ridiculous.
0 u/GainsGoblinGoebbels 19 Jun 2016 12:46
Yes but you're de-scoping the DOM interaction aspect from the original problem
0 u/rwbj 19 Jun 2016 13:45
I actually offered a more general solution. If you just want to call the callback when the object changes then you can do it in one line!
The syntax isn't as clear but TextChanged is an event that's fired when the text is changed which you are subscribing to. You can hook anything into that. When it calls it it sends a sender (in this case the textBox that was updated) and whatever eventArguments are appropriate. The => is just the syntax indicating a lambda so it's an inline way of dynamically generating a nameless version of the method:
And that method is now called each time the text changes. So we've now achieved an object specific callback in one line of code!
0 u/GainsGoblinGoebbels 20 Jun 2016 04:58
And now you just confirmed that you didn't even read through the linked post.
OP posts a link specific to a JS library workaround for managing client-side browser-quirk-related DOM interactions as part of facilitating data transport and you derail by posting server-side C# which makes the assumption that browser quirks are automagically already handled for you.
Bravo.
0 u/rwbj 20 Jun 2016 07:37
There are no "browser quirks" here. The jquery code is functioning as designed and intended.
What I was initially pointing out was just the god awful syntax of javascript which becomes rapidly self obfuscating on projects any reasonably degree of complexity. But we could go beyond that to hit on what you're saying. The interaction between javascript, HTML, and the user is plainly terrible, but there is literally 0 reason for this to be the case. Your comment regarding my code doesn't even make any sense. There is 0 relevance to the code I'm showing whether it's executed client, server, or some mixture in between, at least not in an app.
And this is comparing apples to apples. HTML and javascript were never designed for what they do today, but continue to exist largely because they've become so ingrained that moving on from them would be difficult. Imagine instead we used a standard basic (limited instruction set) byte code in a natively stateful system. You could improve security, performance, flexibility, developer productivity, and more overnight by orders of magnitudes. The tie-in attempts to do this such as java-apps have fared poorly not only since they were again hamstrung by being tie-ins instead of replacements, but also because they were unilateral efforts. That not only means relatively poor implementations as one company was left to release virtual machines for every single enduser platform, but also limited receptivity. Have Microsoft, Google, Firefox, and the other big players work to develop the standard and leave implementation to browsers and perhaps even more ideally - operating systems.
I mean doesn't it ever occur to anybody else that the current state of HTML+scripts is shockingly reminiscent of early programming languages like COBOL? It was designed by people who tried to solve a lot of problems but could never have imagined what the future would hold. And at first the solution was to keep trying to tack more things onto it, but in the end a complete reboot often comes with a short term productivity loss but a longterm exponential gains, and I think our web interface is long due a reboot.
0 u/AmaleksHairyAss 19 Jun 2016 04:29
Javascript may be shit but jquery is one of the most beautiful pieces of code I've ever seen.