@henke37 said:
Someone get this guy a vb script to automatically merge the entries back again.
Now you have tw... er, fuck. I can't count that high
@henke37 said:
Someone get this guy a vb script to automatically merge the entries back again.
Now you have tw... er, fuck. I can't count that high
This is a pedantic linguistic issue... but then, of course it is. This is TDWTF.
Perl got it right at least conceptually: the state of the variable is being blessed (or not); how you bless it is up to you.
Paramaterized queries does not change the input data, it deals with it in a safe way.
I can sanitize many biological specimens with bleach (or a bullet), but dealing with them live, and protected somehow, is, depending on how you want to poke at them, a different thing.
He knows what paramaterized queries are, he (and I) just doesn't consider that to be "sanitization".
@RaceProUK said:
Subscription payments.
Yes, I know about Direct Debit. No, not everyone uses them.
Design flaw.
Vendors should be certified to do recurring or stored payments, and then on initial request, be assigned a new, unique and entirely private token for that customer. If a vendors database is ever compromised, it doesn't matter, the CC clearinghouses would simply void the tokens, which don't affect the end CC at all.
I dunno what you mean. And I'm not using "script-able" in the sense of "written in a scripting language", but "presents an API to external users to automate". Like, shudder, VBA.
Oh, maybe I do see what you mean. Infinite loop. Not the GUI toolkits problem. It is always possible to construct an infinite call loop that might be triggered. What about onChange()? Constructing an onChange() battle royal is just as easy to do.
@blakeyrat said:
Then the application's broken. Not all input devices have a concept of "focus", so if the application is doing something that relies on it, it's broken.I'm not saying it's uncommon for apps to rely on focus; I'm just saying that in that case the problem is the app, and not the scripting interface.
Can't disagree, however if it is a feature of the GUI toolkit to register events against onFocus()/onBlur(), and the GUI toolkit provides a scripting API, then you must be able to script that for it to be considered complete.
@blakeyrat said:
@Planar said:If you make it scriptable, you must make ALL OPERATIONS scriptable, otherwise your scripting API is just a piece of shit."focus" is a concept used by humans, not by computers. I don't see any purpose to making it scriptable. But in any case:
1) fair enough, my point still applies (this is a shitty way of making the computer scriptable)
2) I doubt that's why that menu exists anyway, I'm sure some Linux dinosaur put in a feature request for it and since all Linux developers have a hard-on for complexity and "choice", they put it in no questions asked
You allow focus to be scriptable because very often the application has triggers on onFocus() and onBlur() (or whatever).
@Salamander said:
Are you suggesting that a read lock shouldn't prevent another program from changing a file while it's being read?
No, I'm suggesting that something that has the very minor permission to read a file should not be allowed to lock it. Perhaps their should be an additional lock permission or something. Or if you build an OS that providing the functionality of an OS enforced lock, then also build the required related functionality of telling things that someone else really, really, wants to update the file. Or define an API and/or convention to break those locks, short of rebooting. You know, finish the job.
I think that it can, but wrapping things up, whereas the convention with UNIX is that SIGHUP means "reload datafiles", there is no such convention in Windows. Because Windows promises that files will never change after you write-lock them. I guess you could try and "restart" processes that have write-locked files, even just killing them, but again, that isn't a standard/conventional flow. I mean, how can the OS be expected to figure out the inter-relationships between a bunch of processes, together providing some functionality? You can't just start killing off processes and expect that they will gracefully restart their IPC, or are atomic, or whatever. Reboot at least is a case that all applications should handle.
Absence of write-locks it is an actual problem. UNIX just ignores it. Windows prevents it. UNIX applications (and maybe even UNIX defined convention, e.g. SIGHUP) deal with it gracefully. The Windows solutions opens up an entirely new set of problems, especially compounded by the (now largely historical) problem of just about every application installer installing files everywhere and unpredictably.