Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
Just another Perl shrine
 
PerlMonks  

Re^4: The ability to delete

by kiat (Vicar)
on Oct 22, 2005 at 16:28 UTC ( #502222=note: print w/ replies, xml ) Need Help??


in reply to Re^3: The ability to delete
in thread The ability to delete

I think you might have misread my post above. I don't think I implied that "emptying a node is a responsible behaviour". What I said was, when you give the user the power to edit, you're potentially giving her the power to remove the entire content of the post - not deleting the post and making the node (id) disappear but emptying its content. So the question is, why empower the person to potentially remove a post's entire content and yet not allowing her to delete it?


Comment on Re^4: The ability to delete
Re^5: The ability to delete
by Joost (Canon) on Oct 22, 2005 at 16:47 UTC
    I know what you meant, but it's a question of perspective: if the ability to edit a node comes with the assumption you won't remove the content (because that's not responsible behaviour), why add the ability to remove the node?

    The only reason to use it would be an accidental double-posting. It's possible to prevent most of those programmatically and I think that would be more productive than adding a delete button that in effect should only be used for just that occasion.

      Just a small observation: I've noticed that many of the senior monks here must be mathematicians. In that many people point out that "the right way" is some solution X, which never gets implemented, while a lesser, but wildly more implementable, solution Y gets ignored in favour of X.

      Mathematicians seem to prefer proving that it can be done rather than doing it, too ;-)


      I can buy that "solution Y" is bad because of a, b, and c. But saying that there is a better solution (which isn't going to be implemented in anyone's spare time any time soon) is misleading. Thus, in our current thread, saying, "We're actually trying to close those loopholes, not open them up," is a completely valid, plausible, accurate, direct response. Saying, "A better solution is..." is just misleading. Misleading in that there's an implication that it's not only on the to-do list of the pmdev, but that someone may actually work on it some time in the near future (where "near" is relative, but likely within the next month or two). While you may not have meant that implication, I hope you can at least see how others may infer it (incorrectly), and that's how it becomes misleading.

      Even though I'm a firm absolutist, I can still see how perception colours reality - as someone who is still a relative newbie on PM, I can see how some may infer these things. So I'd encourage the more senior monks to be aware of the inferences others may draw, and try to help them not make those inferences.

        I might be considered a senior monk, but I'm not a pmdev and I don't follow the development track at all, so I did not mean to imply anything about future developments in the monastery.

        The reason I brought up the "better" solution was just that I though of it at the time. Since this is PerlMonks Discussion I think that it was appropriate, in case anyone in pmdev would feel like implementing it, even though I don't feel it's very important. The current system works well enough IMHO.

        ps: I'm not a mathematician :-)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://502222]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (12)
As of 2014-04-17 16:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (453 votes), past polls