Talk:Break OO privacy

From Rosetta Code
Revision as of 07:02, 25 October 2011 by rosettacode>EMBee (context?)

Should this task remain?

Is this a correct subject for RC? Will it reflect badly on RC? Will it attract the wrong kind of audience to RC? --Paddy3118 03:42, 6 August 2011 (UTC)

I think that if it is something that some languages can achieve then the task should remain. Not every idea is necessarily good practice in all languages, but if it is achievable, then it can still be demonstrated for comparative purposes. Markhobley 08:23, 7 August 2011 (UTC)

Context?

What is the context for this task?

In other words, are we talking about using a debugger? or are we talking about implementing an inheritance hierarchy? Or are we talking about code analysis? Or.... ? --Rdm 17:49, 6 August 2011 (UTC)

I put an example of one possible interpretation of the task requirements out there. Is that what this task is about? --Rdm 00:41, 7 August 2011 (UTC)

When I saw the task title before reading the details, I assumed it was about accessing “private” fields of an object other than by the explicit code of the object (i.e. the Tcl example is appropriate, the C# and Java ones are not). —Kevin Reid 00:54, 9 August 2011 (UTC)

I agree. The Java one is now restructured to only present the backdoor approach. I lack the expertise to do this with the C# code, but there must be something possible. I guess this means we're getting closer to being able to write the task description more exactly… –Donal Fellows 10:32, 9 August 2011 (UTC)
I have marked the current task description as incorrect. Both the prior Java implementation and the current C# implementation satisfied the task description. So if they are wrong then the task description is also wrong. --Rdm 12:43, 9 August 2011 (UTC)
I modified the task description to reflect what I think was the intent of the task. (Mwn3dPaddy, are my modifications congruent with what you had in mind?) --Michael Mol 13:31, 9 August 2011 (UTC)
Sorry, I've been away. Back now!
The intent was to show ways to circumvent such protection when, for example, you are given a compiled class and wish to force access to a protected member. The reason for the task is that Python - a language that has intentionally weak protection - relying instead on a "we're all consenting adults" approach, mentions that where other languages have a culture of using protected members, that there usually exists methods to get around this. I did want to get them in one place; but I also realise that it might undermine those languages that rely more on the obscurity of their protection hacking methods so I remain quite willing to junk the whole page if the community thinks it wise. --Paddy3118 19:05, 9 August 2011 (UTC)
I'd vote that the task stay. Of course it should have warnings about the practice being frowned upon, running with scissors, playing with live ammunition, that sort of thing. The task need not even have a specific context. I would like to see some elaboration in the task description about possible uses of value. As I could see some languages may have different reasons for this kind of thing, it would also be appropriate to ask each language for some description of why this might be needed. --Dgamey 02:20, 12 August 2011 (UTC)
i'd actually like to use this task to demonstrate that in languages that claim to have protection this protection can be circumvented. of course even nicer would be if we could get proofs for languages where it can't be circumvented. but i guess that may be hard.--eMBee 07:02, 25 October 2011 (UTC)