But if you could attach your own OnClick method to the button, only one method can be called when the user click on the button, which would be a huge problem for many gui objects.
Put the calls to the other ones in that method. Treat it as a stub method.
And I am not against a "listener registry" or whatever one wants to call it, it's just that a dev shouldn't have to deal directly with it for the vast majority of typical UI coding. Have a convenient front-door for the vast majority of "customers", and a back-door for specialized fiddling. You could stuff a hundred additional on-click events for that button into the listener registry if you wanted. A default on-click method doesn't prevent that. (Hopefully there is a priority code to control order of handling.)
Also, one could put a general event handler on the button's container, and do the other handlers that way, using reflection or environment info to know what widget and what action triggered it.
There are many options without having to deal with lambda's. Would you like to present a specific use-case to explore further?
(I've been trying to invent/define a table-oriented GUI engine that is mostly language-neutral. Most events can be handled using tablized attributes instead of imperatively coded behavior. Everyone's just used to hand-coded behavior out of industry habit. It's poor tool/labor factoring to re-invent a GUI engine for every different programming language. A good language-neutral GUI engine could be attached to any language.)
"If you tried [RoR], and cannot learn it, then programming just might not be for you"
I've seen too many similar statements from proponents of various frameworks/tools/languages/paradigms: "If you don't get X, you are stupid and should be flipping burgers."
After more than a decade of debating so called Golden Hammers and probing their justifications, I've concluded that people just vastly think differently and there are many ways to shave a cat (skinning them is too mean).
Some techniques just resonate with certain brains better. There is no reason to make it personal or mean.
I've met other Table Oriented Programming thinkers ("Tablizers"), and they love it also, but selling TOP to others has fallen flat.
They seem to prefer coding attributes (or what should be attributes) into what TO ME is verbose and hard-to-read code. But they LIKE reading that verbose code and even seem fast at it. Boggle. It's like Fred Flintstone preferring to stick with his feet-powered-car instead of getting a Honda. If Fred can get around well and quickly in his Footillac Deluxe, I guess I shouldn't care, as long as he doesn't force his car choice on me.
Hopefully each can find or make a shop where the other developers like and use your favorite tools also, and everybody is happy and productive with tools that fit their mind like a glove.
Spewing ions is a problem: they're reaction mass and they have to be carried.
But the "power" in ion drives comes from the fast speed of the particles (ions), far quicker than rocket exhaust and near the speed of light. The weight of the material that gets converted into ions is relatively small, no?
Are you saying if a star-ship was built using an ion drive, it would have to carry a large chunk of stuff (relative to the ship) to eventually be ionized on the journey?
If the ship is 10% stuff to be ionized, and the ions spew out at almost the speed of light, then ionizing that chunk should make the ship be going roughly 10% of c when it's done, it seems.
Maybe I'm not considering some relativistic effects and stuck in Newtonian thinking?
Only the syntax of the listener doodad is annoying, the design works well.
If you get used to it, a lot of things "works well". I found it fundamentally unnatural. The info for a given button should be together under a class-like grouping, something like the following pseudo-code:
If it's so wimpy, why not use ion drives? I thought it was roughly 100x more efficient than ion drives (in tests), and that's why space-travel enthusiasts were excited about it. Your statement seems to say otherwise.
A key difference between EM and ion drives is that ion drives spew radiation to produce thrust while the EM drive allegedly doesn't. While that may be interesting from a physics perspective, it's not a practical issue from a space travel perspective because spewing radiation (ions) is not a significant problem.
In other words, it's not the apparent "something from nothing" aspect that excites travel enthusiasts, but the allegedly efficiency, because moving fast in space requires a hell of a lot of energy.
EMD titillates (or teases) physicists because of the perpetual-motion-machine-like qualities, but it titillates wannabe space-travelers because it's allegedly far more efficient than anything we have, meaning we could approach the speed of light without mountain-sized fuel tanks/reactors.
Actually, ColdFusion is still being sold, and has 2 or 3 open-source alternatives.
Its early selling point was easier web-page coding, and compared to what was available at the time, it was.
Then it became more known for making things simpler for HTML designers to integrate their markup templates with database data. And, it was and still is pretty good at that because you usually don't have to escape in and out of markup versus imperative code. In addition to the built-in CF tags, you can make custom tags for them also.
My favorite Java 8 feature is that wonderful Ask Toolbar! You like type words into it and it finds stuff that actually has those words! It's like a personal librarian... well, with ads glued to her ass.
Run-on statements should generally be avoided. For example, what if you had 50 data fields and the error statement gave you little more info other than there's an error SOMEWHERE in that giant statement?
I'm more concerned about how others would use them when I have to read or maintain their code. I've seen some really ugly JavaScript because people misuse anonymous functions (in part because JS also has a poor OO model/syntax). Using methods instead keeps things a bit more disciplined in my opinion.
By the way, a correction:
Original: "Flexible methods can usually do that same thing."
Fixed: "Flexible methods can usually do the same thing as lambdas."
With better OOP Java wouldn't need stinkin' lambdas. Lambda's just give spaghetti coders more ways to write cryptic "cutesy" code. Flexible methods can usually do that same thing.
For example, if Java blurred the distinction between instances and classes, then one could attach an OnClick() method directly to a UI button object instead of pushing it to a listener doodad, which is silly and unnatural.
If the guts of a button object want to register the button's method(s) in a listener object via instantiantion forwarding (up the tree) or reflection; so be it, but the UI coder shouldn't have to care, that's usually internal UI engine guts that one should only have to study for debugging event handling.
Parent forwarding is when a parent method of the same name could specify BEFORE or AFTER to automatically run before or after the child method. (Without BEFORE or AFTER, the child method just overrides it so that it doesn't run.) Perhaps I'm using the wrong terms.
For small-ish (non-enterprise) apps, the real problem with VB Classic was not really the language or IDE, but the deployment and DLL-Hell, especially if it used 3rd-party components. The installation and help-desk staff hated that aspect.
The problem is that nobody can predict the future. Can you point to any currently popular language and say with reasonable certainty that it will be viable 15 years from now?
By the way, Java may now start dying due to Oracle's aggressive lawyers, and McAfee's by-default re-scanning the Java libraries every time you sneeze, and twice if don't.
It's long been true that maintenance is a bigger cost than original coding and that doesn't appear to be changing. It's counter-intuitive, but true.
I've been asked to fix or change Excel-based "applications" built by non-techies, and they were a maintenance nightmare.
If it's a short-term project, that's fine. But in the longer run, roll-your-own-pasta for anything lasting will actually require more developers. Pay the piper now or triple later.
It depends where you draw the line for "humanity". The first shaped stone tools are concentrated in Africa.
Later stone-tool-making hominids did spread out, and it is possible an isolated group became "humanized" at a faster pace and then spread back into Africa and elsewhere.
(I mention stone tools because chimps are known to sharpen wooden sticks with their teeth.)
We haven't yet found the remote control in the couch, but we did found 3 socks, a bag of unopened Doritos only 1 month past the expiration date, $3.27 in change, a Zune, and a blue skirt.
Slashdot Mirror
Put the calls to the other ones in that method. Treat it as a stub method.
And I am not against a "listener registry" or whatever one wants to call it, it's just that a dev shouldn't have to deal directly with it for the vast majority of typical UI coding. Have a convenient front-door for the vast majority of "customers", and a back-door for specialized fiddling. You could stuff a hundred additional on-click events for that button into the listener registry if you wanted. A default on-click method doesn't prevent that. (Hopefully there is a priority code to control order of handling.)
Also, one could put a general event handler on the button's container, and do the other handlers that way, using reflection or environment info to know what widget and what action triggered it.
There are many options without having to deal with lambda's. Would you like to present a specific use-case to explore further?
(I've been trying to invent/define a table-oriented GUI engine that is mostly language-neutral. Most events can be handled using tablized attributes instead of imperatively coded behavior. Everyone's just used to hand-coded behavior out of industry habit. It's poor tool/labor factoring to re-invent a GUI engine for every different programming language. A good language-neutral GUI engine could be attached to any language.)
I wonder what the usage of Lazarus is.
no longer a problem because slick drag-and-drop tools have made coders obsolete.
I've seen too many similar statements from proponents of various frameworks/tools/languages/paradigms: "If you don't get X, you are stupid and should be flipping burgers."
After more than a decade of debating so called Golden Hammers and probing their justifications, I've concluded that people just vastly think differently and there are many ways to shave a cat (skinning them is too mean).
Some techniques just resonate with certain brains better. There is no reason to make it personal or mean.
I've met other Table Oriented Programming thinkers ("Tablizers"), and they love it also, but selling TOP to others has fallen flat.
They seem to prefer coding attributes (or what should be attributes) into what TO ME is verbose and hard-to-read code. But they LIKE reading that verbose code and even seem fast at it. Boggle. It's like Fred Flintstone preferring to stick with his feet-powered-car instead of getting a Honda. If Fred can get around well and quickly in his Footillac Deluxe, I guess I shouldn't care, as long as he doesn't force his car choice on me.
Hopefully each can find or make a shop where the other developers like and use your favorite tools also, and everybody is happy and productive with tools that fit their mind like a glove.
Sunshine, Unicorns, Rainbows, and YourFavStack
Peace! -Tablizer
But the "power" in ion drives comes from the fast speed of the particles (ions), far quicker than rocket exhaust and near the speed of light. The weight of the material that gets converted into ions is relatively small, no?
Are you saying if a star-ship was built using an ion drive, it would have to carry a large chunk of stuff (relative to the ship) to eventually be ionized on the journey?
If the ship is 10% stuff to be ionized, and the ions spew out at almost the speed of light, then ionizing that chunk should make the ship be going roughly 10% of c when it's done, it seems.
Maybe I'm not considering some relativistic effects and stuck in Newtonian thinking?
How so?
If you get used to it, a lot of things "works well". I found it fundamentally unnatural. The info for a given button should be together under a class-like grouping, something like the following pseudo-code:
If it's so wimpy, why not use ion drives? I thought it was roughly 100x more efficient than ion drives (in tests), and that's why space-travel enthusiasts were excited about it. Your statement seems to say otherwise.
A key difference between EM and ion drives is that ion drives spew radiation to produce thrust while the EM drive allegedly doesn't. While that may be interesting from a physics perspective, it's not a practical issue from a space travel perspective because spewing radiation (ions) is not a significant problem.
In other words, it's not the apparent "something from nothing" aspect that excites travel enthusiasts, but the allegedly efficiency, because moving fast in space requires a hell of a lot of energy.
EMD titillates (or teases) physicists because of the perpetual-motion-machine-like qualities, but it titillates wannabe space-travelers because it's allegedly far more efficient than anything we have, meaning we could approach the speed of light without mountain-sized fuel tanks/reactors.
Actually, ColdFusion is still being sold, and has 2 or 3 open-source alternatives.
Its early selling point was easier web-page coding, and compared to what was available at the time, it was.
Then it became more known for making things simpler for HTML designers to integrate their markup templates with database data. And, it was and still is pretty good at that because you usually don't have to escape in and out of markup versus imperative code. In addition to the built-in CF tags, you can make custom tags for them also.
It's a tool that fits its niche pretty well.
My favorite Java 8 feature is that wonderful Ask Toolbar! You like type words into it and it finds stuff that actually has those words! It's like a personal librarian ... well, with ads glued to her ass.
Run-on statements should generally be avoided. For example, what if you had 50 data fields and the error statement gave you little more info other than there's an error SOMEWHERE in that giant statement?
I'm more concerned about how others would use them when I have to read or maintain their code. I've seen some really ugly JavaScript because people misuse anonymous functions (in part because JS also has a poor OO model/syntax). Using methods instead keeps things a bit more disciplined in my opinion.
By the way, a correction:
Original: "Flexible methods can usually do that same thing."
Fixed: "Flexible methods can usually do the same thing as lambdas."
With better OOP Java wouldn't need stinkin' lambdas. Lambda's just give spaghetti coders more ways to write cryptic "cutesy" code. Flexible methods can usually do that same thing.
For example, if Java blurred the distinction between instances and classes, then one could attach an OnClick() method directly to a UI button object instead of pushing it to a listener doodad, which is silly and unnatural.
If the guts of a button object want to register the button's method(s) in a listener object via instantiantion forwarding (up the tree) or reflection; so be it, but the UI coder shouldn't have to care, that's usually internal UI engine guts that one should only have to study for debugging event handling.
Parent forwarding is when a parent method of the same name could specify BEFORE or AFTER to automatically run before or after the child method. (Without BEFORE or AFTER, the child method just overrides it so that it doesn't run.) Perhaps I'm using the wrong terms.
It's not "funny", it's probably The Suits seeing Cast as (somehow) profitable, and dividers not.
For small-ish (non-enterprise) apps, the real problem with VB Classic was not really the language or IDE, but the deployment and DLL-Hell, especially if it used 3rd-party components. The installation and help-desk staff hated that aspect.
I did not found the re-edit button.
The problem is that nobody can predict the future. Can you point to any currently popular language and say with reasonable certainty that it will be viable 15 years from now?
By the way, Java may now start dying due to Oracle's aggressive lawyers, and McAfee's by-default re-scanning the Java libraries every time you sneeze, and twice if don't.
It's long been true that maintenance is a bigger cost than original coding and that doesn't appear to be changing. It's counter-intuitive, but true.
I've been asked to fix or change Excel-based "applications" built by non-techies, and they were a maintenance nightmare.
If it's a short-term project, that's fine. But in the longer run, roll-your-own-pasta for anything lasting will actually require more developers. Pay the piper now or triple later.
It depends where you draw the line for "humanity". The first shaped stone tools are concentrated in Africa.
Later stone-tool-making hominids did spread out, and it is possible an isolated group became "humanized" at a faster pace and then spread back into Africa and elsewhere.
(I mention stone tools because chimps are known to sharpen wooden sticks with their teeth.)
We haven't yet found the remote control in the couch, but we did found 3 socks, a bag of unopened Doritos only 1 month past the expiration date, $3.27 in change, a Zune, and a blue skirt.
Explains that odd new blimp
Trump: "I cannot exchange Quatloos. Damn you Hillary!"
Careful, you know when you send stuff off, it mutates and comes back with a vengeance.
"Luke, I am your [garbled]"
"It's not intelligent life, just the military."
Dude, them commie gubmint leopards can leap to 8.