I hope you never find yourself in a situation where you need medical care and can't pay for it. Because the rest of us, who are in possession of at least a few scraps of human decency, would have to shell out to save your ungrateful ass.
A human life is worth more than its economic output.
But when the model is accessed from four different controllers representing different privilege levels (e.g. public profile page, user settings page, internal admin page) and user experiences, is it really still the model's job to figure out which incoming updates are allowed to update which fields?
This is "thin controllers" gone too far -- the model shouldn't have to figure out where it's being updated from and what to allow.
It's naive and it's not exactly an ACL or anything but it's a way to indicate the context at a basic level.
Sadly, people seem to be running around like headless chickens trying to scotch tape trash bags over a broken window instead of learning how to replace the glass.
1) The model could be used everywhere so it may be best to negate the issue by locking down the attributes at one source.
2) As you pointed out, the model is in different contexts depending on the privilege of the current user session. It's almost as if I want a thin layer between my model and controller that takes into account session info and informs the model about what can and can't be done.
Another option is to have the model take more a DDD approach. Part of the input params could be a user object. That same user object would know its current privileges and that could be done within the large model that is actually trying to do something.
What I don't know is if RoR allows for this sort of modeling. I have no experience with the framework. It might want something that is similar to getters/setters in Java. If this is the case, such a modeling is problem not going to work since the multiple params will break the spec.
As an integral convention of Rails, it does not (to my best knowledge). As something you could add yourself or package up into a plugin, sure. It just wouldn't be the conventional approach (which, as we're discovering, is stupidly insecure and patching things over while targeting the wrong problem).
Precisely because there can be so many places (controllers) that can access the model, usually you use declarative access control rules on the model to control access in one place. It can be done with role. Then whoever user having the role can access the model.
Very commonly, a person's jaw/mouth is too small for the wistom teeth to fit. Case in point, I (25-year old guy) had a wisdom tooth which grew sideways (into the next tooth) and _would_ have destroyed the next tooth and caused an infection like the one linked in the article. I have a second one which might do the same.
These things are not preventable, you were just born lucky. Remember, humans didn't usually live to become 50 years old.
> Very commonly, a person's jaw/mouth is too small for the wistom teeth to fit.
Exactly this. I had something similar (identical?): A horizontal impaction of my bottom right molar. Had I left it longer, it would've destroyed the roots to the molar in front of it, and I would've lost that tooth, too.
I suspect it's largely genetic. My mum has all her wisdom teeth, and she's never had an issue; my father had all of his removed because they didn't come in straight. My situation played out identically to his. Hence, I don't believe that simply taking pristine care of the teeth will magically help--if they don't erupt from the gums properly or come in crooked, there isn't much else that can be done save an extraction if they're problematic. In many cases, you're better off having them removed to prevent issues precisely like this one.
I'm missing two upper teeth [0], which resulted in my having enough room in my mouth for my upper wisdom teeth to fit comfortably. It's evidently of genetic origin in my case, as I have relatives who are missing the same teeth, which I think from that source are called the upper lateral incisors. Were I not missing those teeth I expect I'd have needed the upper wisdom teeth removed to make room.
(On a tangent, there's a great article [1] about how bulldogs have been bread to have massive jaws and a very short face and that results in all kinds of breathing difficulties.)
Interesting. I know of at least two other people with that condition who were missing a number of adult teeth that never came in. Though, I think their example is somewhat more extreme (and according to Wikipedia, I guess it would be classified as oligodontia), because at least one of them required extensive dental surgery for implants since they quite literally lacked 6+ (maybe more?) teeth.
> (On a tangent, there's a great article [1] about how bulldogs have been bread to have massive jaws and a very short face and that results in all kinds of breathing difficulties.)
I bet that applies to persian cats, too, since they're bred with extensively concave faces (something that seems cruel, IMO).
Very interesting reply--thanks for sharing that, because I had completely forgotten that one of my friends has a similar condition. Can't believe I completely forgot he had implantation done, too...
"Remember, humans didn't usually live to become 50 years old."
This. Also, humans used to lose a lot of teeth. Modern dental hygiene is a very recent development within the ~200,000 year span of H. sapiens sapiens. Throughout most of human history, wisdom teeth served as reserves, of a sort, to fill in what were likely to have been more than a few gaps.
These days, proper dental hygiene means you've more likely than not been able to keep all of your adult teeth, ergo, it's highly likely than your wisdom teeth will become impacted. The assertion that proper dental care will prevent wisdom tooth impaction is ludicrous.
It is true, however, that extraction of wisdom teeth can be managed to an extent. Almost everyone gets them at some point, and impaction is very common, and all of this is well known. So a proper dental regimen should include x-rays to search for wisdom teeth well before they become problematic. If this is what the OP intended to say, then fine. But his phrasing makes it sound as if he implied that proper brushing and flossing will obviate the need for wisdom tooth removal. Last I checked, brushing and flossing do not alter the shape of one's jaw.
To defend myself here (a day later), I was not assigning the causality in that direction. The "Because I took care of them" clause goes with the "I get to keep them", as in "I made sure to clean them and not let them get cavities, so there aren't any problems with them staying around". I thought the English was clear enough as I wrote it, but I guess parse errors are more common than I thought.
The key here is that you aren't sampling the same uniform distribution each time. You shrink the sample space by one each time you remove a card and append it to the end.
If multimethods were a subset of static typing, then regular methods would be too. Methods are dynamic by definition: the type of the method's target is inspected at runtime and used to dispatch to the correct function entry. In Python, it's explicitly stated because the first argument of all object methods is "self". Multimethods extend this to do dynamic dispatch on all argument types, not just the target object.
Most Python object methods are declared at compile time; this doesn't make method declaration a "subset of static typing". You can add new methods to classes and objects at runtime using Python's reflection and introspection; you can just as easily add new multimethods at runtime using this framework.
Finally, the @decorator(...) syntax at compile time is just syntactic sugar for something like the following:
def _foo(self, arg):
...
foo = decorator()(_foo)
So you can use decorators at runtime whenever you want too.
Begin blocks execute during compilation, immediately after they've been parsed. They're compiled themselves, and execute within the Perl interpreter before it finishes compiling the rest of the containing module. So they don't really execute prior to all compilation, but they execute prior to the compilation of anything sequentially after them in the source.
I don't consider this to be 'true' non-terminating compilation then. Interesting cases to me would be ones where the syntax itself throws the compiler into an infinite loop, not one where you explicitly tell the compiler to execute an infinite loop.
"the syntax" and "where you explicitly tell the compiler" are the exact same thing. Syntax is, fundamentally, instructions to the compiler.
Some languages don't contain instructions that can instruct the compiler to loop or recurse (C, assembly, brainfuck). Some languages contain a sub-language or meta-language which can instruct the compiler to recurse (java, C++). Some languages use their native syntax to instruct the compiler, making looping or recursion trivial (Perl, Lisp).
It's non-terminating execution during compilation, similar to the example elsewhere in the comments using nonterminating macro definitions in Common Lisp.
A compilation process that involves executing and waiting for the termination of a program that doesn't terminate can't itself terminate.
I remember being shown call/cc briefly in CS 61A at Berkeley and then forgetting about it until recently when I saw an article on it while I was in the middle of writing an event-driven web application using Perl and Plack. I immediately saw how useful it would be and wished I had it available to use there.
COME FROM is the reason INTERCAL is among my favorite esoteric programming languages. That and the fact that its name is for "Compiler Language With No Pronounceable Acronym".
From Wikipedia: An actual example in INTERCAL would be too difficult to read
A human life is worth more than its economic output.