Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: May Thy Closures Be Blessed

by diotalevi (Canon)
on Apr 26, 2004 at 15:20 UTC ( #348203=note: print w/replies, xml ) Need Help??


in reply to May Thy Closures Be Blessed

Why did you make 'class' a member variable in $fields{'class'}? You already had access to it in $class and I think that since it is not member data that it shouldn't be treated that way.

Please also note that I wrote Stealing lexicals - best practice suggestions with the idea of violating the sort of encapsulation you just proposed here. Nothing is absolute. The code I've seen that really, truely encapsulates is Protect your subs... from *EVIL*.. This assumes the idea of "encapsulation" means "Prevent a determined programmer who is willing to write unmaintainable code from gaining access to private variables" and not "Prevent a normal programmer from gaining access accidentally or otherwise."

Replies are listed 'Best First'.
Re: Re: May Thy Closures Be Blessed
by hardburn (Abbot) on Apr 26, 2004 at 15:30 UTC

    Why did you make 'class' a member variable in $fields{'class'}?

    I belive my orginal reasoning had to do with an earlier version of the code that couldn't get access to $class. So my only excuse is hysterical reasons that I should have removed in the final post.

    . . . violating the sort of encapsulation you just proposed here. Nothing is absolute.

    I know it's possible to dig into someone else's lexical scope, but it's far more difficult than doing $obj->{foo}. Ultimately, I can't do anything to stop someone from tralling through /dev/mem or the equivilent on another system.

    ----
    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      I know it's possible to dig into someone else's lexical scope, but it's far more difficult than doing $obj->{foo}. Ultimately, I can't do anything to stop someone from tralling through /dev/mem or the equivilent on another system.
      It may be useful to point this out to Java users sometimes. Java's privacy rules have been successfully violated in the past using that loophole - everything is public at some point.

        You can't use /dev/mem if you're not root; but fortunately there's a simpler interface to read the memory of process: ptrace.

        For those who don't already know. Ptrace is the system call on linux and many other unixes that debuggers such as gdb and strace use. With ptrace any process can inspect any other process that is running under the same uid (provided that the other process is not setuid or setgid; root can ptrace any process but init). You can trace system calls and signals, read or write the virtual address space and registers of the traced process. You can single-step a process by setting the single-step flag of the processor, and catching the generated SIGTRAP signals with ptrace.

      I know it's possible to dig into someone else's lexical scope, but it's far more difficult than doing $obj->{foo}. Ultimately, I can't do anything to stop someone from tralling through /dev/mem or the equivilent on another system.

      You don't have to go as far as that in this particular instance. All you need do is fake being in the appropriate package, which isn't hard ;-)

      As you point out, this isn't really the issue - the issue is accidental interference rather than deliberate trespass.

        As you point out, this isn't really the issue - the issue is accidental interference rather than deliberate trespass.
        Deliberate trespass in your own codebase isn't something you fix in software, it's something you fix by going over to someone's cube and removing their mouse balls until they get the point. Anyhow, if you can't trust your fellow coders to not play symbol table / reflection / etc type games, you have problems! So folks think they have encapsulation, but they don't, and they think they have loose coupling, but they don't.

        Encapsulation is mainly in existance to enforce clean boundaries between objects, and ideally these boundaries should be limited to a very small list of methods and few variables, such that changes in the objects don't break programs.

        Furthermore, encapsulation can be broken with no access to variables, by virtue of having trivial getter/setter methods encapsulation IS broken, because the parameters of your object can be tweaked without asking the object nicely. Most folks already know this, but at least in the java world, many don't!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://348203]
help
Chatterbox?
and the monks are mute...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (3)
As of 2017-12-16 23:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (459 votes). Check out past polls.

    Notices?