Rootin Tootin Code Choosin' Draww Switch (HELP ME)

[guyman]

this type of thing has kept me from delving deeper into coding and computer science. Everytime I go searching for a solution online or a "how to" when making my own thing, all I see is simulacra, cowardice, easybake ready made, meta gem just unzip solutions that never explain anything or enable anything cool, and instead further people into abstraction and ignorance, with these things often employing the things people tell us to stay away from. I understand the need for caution, and why people help others with the quick fix based on common needs, but damn if it isn't hard to get to brass tacks when you want to diy and leave the matrix...
Thank you ! feel free to drop more gems on me ! (not ruby gems)

[deraudrl]

after doing a bit of research on this subject online I don't really see what the fuss is about. wrong right good bad all subjective baseless things. I want to hear real consequences. All I can see now is this talk of how it can get messy in terms of organization {solved with careful planning and notation(we are "programmers" right?)}.. and maybe runaway memory issues if used incorrectly. if ruby dumps it's cache when doing this that solves problems of procs causing memory issues, but could throw a wrench in my own tactic if I am calling for arrays, but I can work around that. I like Trog's perspective of it being circumstantial, and I'd take it a step further and say it SHOULD be wielded where ever it can (that is if you are making something interesting enough to .call for such force.abilities)...

I freely admit that my experience with this sort of hack has been in traditional compiled languages. And perhaps "self-modifying" is a bit of a misnomer when applied to an interpreted OO language: it isn't "modifying" anything so much as it's creating a copy with altered behavior. I'm really unclear how you'd go about backtracing an error in that kind of environment, using the meager tools available in FS.

That said, there's nothing being done here that remotely qualifies as "mission-critical" (as opposed to most of my prior-life work product), so if you're comfortable with it, go for it. But don't be surprised if any anomalous behavior is (1) hard to diagnose and (2) nearly impossible to replicate reliably.

[guyman]

@deraudri duly noted - I appreciate your input.

[trogluddite]

one of my mentors said, "Just because something works doesn't mean it's a good idea."

Certainly, and "premature optimisation is the root of all evil", etc. too! Meta-programming is something which should be done with caution and with an eye to clarifying what shennanigans you're getting up to. But the sheer number of hooks for doing it in Ruby shows that it's an accepted part of Ruby coding, albeit a relatively advanced one with plenty of caveats. In fact, it's how Ruby implements the interpreter's equivalent of compiler directives (e.g. loading external libraries or tailoring code for hardware capabilities).

I freely admit that my experience with this sort of hack has been in traditional compiled languages. And perhaps "self-modifying" is a bit of a misnomer when applied to an interpreted OO language: it isn't "modifying" anything so much as it's creating a copy with altered behavior..

Yes, I think it's very much the case that the value of this kind of code depends upon the language. In Ruby, and most other OO languages these days, a code routine can be encapsulated as an "object" just like anything else (the 'Procs' in @guyman's code being one example). "Self-modifying code" might then be better described as "higher-order functions" - that is, functions with arguments or return values which are themselves functions (think C function pointers on steroids!). In fact, any Ruby method which takes a "code block" (a great many of them) is a higher-order function. My original coding background was pretty traditional too, and I'll admit, this stuff rubbed my fur the wrong way at first and took me plenty of getting used to!

I'm really unclear how you'd go about backtracing an error in that kind of environment, using the meager tools available in FS

FS does make it a little harder, as Ruby can be interacting with non-Ruby components; but Ruby is a very "reflective" language. There isn't a separate "debugger" tool such as a compiled language usually has, but there are runtime methods which expose almost everything that the Ruby interpreter "knows" about the current code, including diagnostics such as lists of accessible methods, objects representing the current method definitions, stack traces, unhandled exceptions, etc.

For example, when first testing @guyman's code, I wanted to check that "draw" was definitely being redefined, and that the new definitions were callable only from the RubyEdit being tested - so I just asked nicely in a couple of added code lines...

Code: Select all

# Is the current definition of 'draw' only available locally?
watch "local_method?", singleton_methods.include?(:draw)

# The method definition object's unique ID should change when redefined.
watch "method_ID", method(:draw).__id__


(obviously the code is gobbledegook if you don't know Ruby! - just an example of what kind of thing is possible in a couple of lines of totally bog-standard code).